⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2879.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 5 页
字号:
   number of distinct colors available.

        NOTE:  No ability to indicate any specific or named color
        is implied by this option.  Some devices might use
        different intensity levels rather than different hues for
        distinction.

   In the context of Internet fax, 'limited' is interpreted as one-bit-
   per-color-sample (RGB, CMY or CMYK), depending on the color space
   used.

   'Mapped' indicates that pixel color values are mapped in some
   specifiable way to a multi-component color space.  The 'color-levels'
   tag may be used to indicate the number of distinct colors available;
   in its absence, sufficient levels to display a photographic image
   should be assumed.

   'Grey' indicates a continuous tone grey-scale capability.

   'Full' indicates full continuous tone color capability.





Klyne & McIntyre            Standards Track                     [Page 7]

RFC 2879      Content Feature Schema for Internet Fax (V2)   August 2000


   For 'Mapped', 'Grey' and 'Full' color, additional feature tags
   (section 3.6) may be used to further qualify the color reproduction.

3.6 Color model

   Feature tag name    Legal values
   ----------------    ------------
   color-levels        <integer>   (>2)
   color-space         Device-RGB  (device RGB)
                       Device-CMY  (device CMY)
                       Device-CMYK (device CMYK)
                       CIELAB      (LAB per T.42 [9])
                       (may be extended by further registrations)
   color-illuminant    <token>     (per ITU T.4 [13], E.6.7)
                       D50
                       D65
                       D75
                       SA
                       SC
                       F2
                       F7
                       F11
                       CTnnnn      (see below)
   CIELAB-L-depth      <integer>   (>0)
   CIELAB-a-depth         "
   CIELAB-b-depth         "
   CIELAB-L-min        <integer>
   CIELAB-L-max           "
   CIELAB-a-min           "
   CIELAB-a-max           "
   CIELAB-b-min           "
   CIELAB-b-max           "

   Reference: this document, appendix A.

   The general model for image handling (both color and non-color) is
   described here from a receiver's perspective;  a similar model
   operates in the reverse direction for a scan/send perspective:

        raw bit        pixel         color         physical
        stream  -(A)-> values -(B)-> values -(C)-> rendition

    -   "raw bit stream" is a stream of coded bits

   (A)  indicates image coding/decoding (MH,MR,MMR,JPEG,JBIG,etc.)

    -   "pixel values" are a single numeric value per picture element
        that designates the color of that element.



Klyne & McIntyre            Standards Track                     [Page 8]

RFC 2879      Content Feature Schema for Internet Fax (V2)   August 2000


   (B)  indicates pixel-to-color value mapping

    -   "color values" have a separate numeric value for each color
        component (i.e. L*, a*, b* in the case of CIELAB indicated
        above.)

   (C)  indicates how the color values are related to a physical
        color.  This involves interpretation of the color value with
        respect to a color model (e.g. RGB, L*a*b*, CMY, CMYK) and a
        color space (which is typically recipient-dependent).

    -   "physical rendition" is a color value physically realized on a
        display, printer or other device.

   There are many variables that can be applied at each stage of the
   processing of a color image, and any may be critical to meaningful
   handling of that image in some circumstances.  In other circumstances
   many of the variables may be implied (to some level of approximation)
   in the application that uses them (e.g. color images published on a
   Web page).

   The color feature framework described here is intended to allow
   capability description at a range of granularity:  feature tags which
   correspond to implied (or "don't care" or "unknown") feature values
   may simply be omitted from a capability description.

   Grey scale and bi-level images are handled within this framework as a
   special case, having a 1-component color model.  The following
   features are used for describing color capabilities:

   'color-levels' indicates the number of distinct values for each
   picture element, and applies to all but bi-level images.  For bi-
   level images, a value of 2 is implied.

   'color-space' is used mainly with 'Mapped' and 'Full', but could be
   used with other modes if the exact color or color model used is
   significant.  Two kinds of color space can be distinguished:
   device-dependent and calibrated.  Device dependent spaces are named
   here as 'Device-xxx', and are used to indicate a color space that is
   defined by the receiving device.  Calibrated color spaces presume the
   existence of a rendering system that is calibrated with respect to an
   indicated definition, and is capable of processing the device-
   independent color information accordingly.








Klyne & McIntyre            Standards Track                     [Page 9]

RFC 2879      Content Feature Schema for Internet Fax (V2)   August 2000


   A color-handling receiver should indicate any appropriate device
   color space capability in addition to any calibrated color spaces
   that it may support.  A calibrated color space should be used when
   precise color matching is required in the absence of specific
   knowledge of the receiving system.

     NOTE:  In practice, although they appear to be separate
     concepts, the color model and color space cannot be
     separated.  In the final analysis, a color model (RGB,
     CMY, etc.) must be defined with respect to some color
     space.

   'color-illuminant' indicates a CIE illuminant, using the same general
   form that is used for this purpose by Group 3 fax (as defined in ITU
   T.4 [13], section E.6.7).  When the illuminant is specified by its
   color temperature, the token string 'CTnnnn' is used, where 'nnnn' is
   a decimal number that is the color temperature in Kelvins; e.g.
   CT7500 indicates an illuminant color temperature of 7500K.

     NOTE: ITU T.4 indicates a binary representation for color
     temperature values.

     In practice, much of the illuminant detail given here
     will probably be unused by Internet fax.  The only value
     likely to be specified is 'D50', which is the default
     color illuminant for Group 3 fax.

   'CIELAB-L-depth', 'CIELAB-a-depth' and 'CIELAB-b-depth' indicate the
   number of different values that are possible for the L*, a* and b*
   color components respectively, and are significant only when colors
   are represented in a CIELAB color space.  These features would be
   used with palletized color, or with full color where each color
   component has a different number of possible values.

   Color depth values relate to the representation of colour values
   rather than the resolution of a scanning or rendering device.  Thus,
   if 256 different L-component values can be represented then the
   assertion (CIELAB-L-depth<=256) is used, even if a receiving device
   can render only 100 distinct luminance values.  (Color rendering
   resolution is not covered by this memo.)

   The 'CIELAB-x-min' and 'CIELAB-x-max' values indicate a color gamut
   (i.e. a range of color values that are used or may be rendered).  A
   gamut may be indicated in terms of the CIELAB color space even when
   colors are represented in some other space.






Klyne & McIntyre            Standards Track                    [Page 10]

RFC 2879      Content Feature Schema for Internet Fax (V2)   August 2000


3.7 Image coding

   Feature tag name    Legal values
   ----------------    ------------
   image-file-         TIFF
   structure           TIFF-limited
                       TIFF-minimal
                       TIFF-MRC
                       TIFF-MRC-limited
                       (may be extended by further registrations)
   image-coding        MH
                       MR
                       MMR
                       JBIG
                       JPEG
                       (may be extended by further registrations)
   image-coding-       JBIG-T85    (bi-level, per ITU T.85)
   constraint          JBIG-T43    (multi-level, per ITU T.43)
                       JPEG-T4E    (per ITU T.4, Annex E)
                       (may be extended by further registrations)
   JBIG-stripe-size    <Integer>
   image-interleave    Stripe
                       Plane
   color-subsampling   "1:1:1"     (no color subsampling)
                       "4:1:1"     (4:1:1 color subsampling)

   Reference: this document, appendix A.

   'image-file-structure' defines how the coded image data is wrapped
   and formatted.  The following options are defined here:

   o  'TIFF' indicates image data enclosed and tagged using TIFF
      structures described in Adobe's definition of TIFF [20].

   o  'TIFF-limited' indicates image data structured using TIFF, but
      with the limitations on the placement of Image File Descriptors
      (IFDs) indicated in section 4.4.6 of RFC 2301 [7].

   o  'TIFF-minimal' indicates a TIFF image format that meets the IFD
      placement, byte ordering and bit ordering requirements of the
      "minimal black and white mode" described in section 3.5 of RFC
      2301 [7], also known as TIFF-S.

   o  'TIFF-MRC' uses a TIFF image structure [20] augmented with a sub-
      IFD structure, described for the "Mixed Raster Content mode" in
      section 8.1.2 of RFC 2301 [7], also known as TIFF-M.  This
      provides a file structure to contain composite images constructed
      using the MRC model described in T.44 [15] (see tag 'MRC-mode').



Klyne & McIntyre            Standards Track                    [Page 11]

RFC 2879      Content Feature Schema for Internet Fax (V2)   August 2000


   o  'TIFF-MRC-limited' is the same as 'TIFF-MRC', except that the
      primary IFD (i.e. top-level IFDs, as opposed to sub-IFDs)
      placement is constrained in the same way as 'TIFF-limited'.

   'image-coding' describes how raw image data is compressed and coded
   as a sequence of bits.  These are generic tags that may apply to a
   range of file formats and usage environments.

   'image-coding-constraint' describes how the raw image data coding
   method is constrained to meet a particular operating environment.
   Options defined here are JBIG and JPEG coding constraints that apply
   in typical Group 3 fax environments.

   The 'JBIG-stripe-size' feature may be used with JBIG image coding,
   and indicates the number of scan lines in each stripe except the last
   in an image.  The legal constraints are:

      (JBIG-stripe-size=128)
      (JBIG-stripe-size>=0)

   The latter being equivalent to no restriction.

     NOTE: there are several image coding options here, and
     not all are required in all circumstances.

     Specification of the image-file-structure tag value alone
     is not normally sufficient to describe the capabilities
     of a recipient.  A general rule is that sufficient detail
     should be provided to exclude any unsupported features.

     For extended Internet fax, image-file-structure and
     image-coding should always be specified, together with
     additional values described above as needed to clearly
     indicate which feature tag values are supported and which
     are not.  (See also the examples in section 4.)

3.8 MRC mode

   Feature tag name    Legal values
   ----------------    ------------
   MRC-mode            <Integer> (0..7)   (per ITU T.44 [15])
   MRC-max-stripe-size <Integer>

   Reference: this document, appendix A.







Klyne & McIntyre            Standards Track                    [Page 12]

RFC 2879      Content Feature Schema for Internet Fax (V2)   August 2000


   The 'MRC-mode' feature is used to indicate the availability of MRC
   (mixed raster content) image format capability.  A zero value
   indicates MRC is not available, a non-zero value indicates the
   maximum available MRC mode number.

   An MRC formatted document is actually a collection of several images,
   each of which is described by a separate feature collection.  An
   MRC-capable receiver is presumed to be capable of accepting any
   combination of contained images that conform to both the MRC
   construction rules and the image-coding capabilities declared
   elsewhere.

   Within an MRC-formatted document, multi-level coders are used for
   foreground and background images (i.e. odd-numbered layers: 1, 3, 5,
   etc.) and bi-level coders are used for mask layers (i.e. even
   numbered layers 2, 4, 6, etc.).  MRC format also imposes constraints
   on the resolutions that can be used.

   The 'MRC-max-stripe-size' feature may be used with MRC coding, and
   indicates the maximum number of scan lines in each MRC stripe.  The
   legal constraints are:

      (MRC-max-stripe-size<=256)
      (MRC-max-stripe-size>=0)

   These values indicate upper bounds on the stripe size.  The actual
   value may vary between stripes, and the actual size for each stripe
   is indicated in the image data.

4. Examples

   The level of detail captured here reflects that used for capability
   identification in Group 3 facsimile.

4.1 Simple mode Internet fax system

   This example describes the capabilities of a typical simple mode
   Internet fax system.  Note that TIFF profile S is required to be
   supported by such a system.

      (& (image-file-structure=TIFF-minimal)
         (MRC-mode=0)
         (color=Binary)
         (image-coding=MH) (MRC-mode=0)
         (| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) )
            (& (dpi=200) (dpi-xyratio=[200/100,1]) ) )
         (size-x<=2150/254)
         (paper-size=A4)



Klyne & McIntyre            Standards Track                    [Page 13]

RFC 2879      Content Feature Schema for Internet Fax (V2)   August 2000


         (ua-media=stationery) )

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -