rfc2083.txt

RFC 的详细文档！

         method used to compress the image data.  At present, only
         compression method 0 (deflate/inflate compression with a 32K
         sliding window) is defined.  All standard PNG images must be
         compressed with this scheme.  The compression method field is
         provided for possible future expansion or proprietary variants.
         Decoders must check this byte and report an error if it holds



Boutell, et. al.             Informational                     [Page 16]

RFC 2083            PNG: Portable Network Graphics            March 1997


         an unrecognized code.  See Deflate/Inflate Compression (Chapter
         5) for details.

         Filter method is a single-byte integer that indicates the
         preprocessing method applied to the image data before
         compression.  At present, only filter method 0 (adaptive
         filtering with five basic filter types) is defined.  As with
         the compression method field, decoders must check this byte and
         report an error if it holds an unrecognized code.  See Filter
         Algorithms (Chapter 6) for details.

         Interlace method is a single-byte integer that indicates the
         transmission order of the image data.  Two values are currently
         defined: 0 (no interlace) or 1 (Adam7 interlace).  See
         Interlaced data order (Section 2.6) for details.

      4.1.2. PLTE Palette

         The PLTE chunk contains from 1 to 256 palette entries, each a
         three-byte series of the form:

            Red:   1 byte (0 = black, 255 = red)
            Green: 1 byte (0 = black, 255 = green)
            Blue:  1 byte (0 = black, 255 = blue)

         The number of entries is determined from the chunk length.  A
         chunk length not divisible by 3 is an error.

         This chunk must appear for color type 3, and can appear for
         color types 2 and 6; it must not appear for color types 0 and
         4. If this chunk does appear, it must precede the first IDAT
         chunk.  There must not be more than one PLTE chunk.

         For color type 3 (indexed color), the PLTE chunk is required.
         The first entry in PLTE is referenced by pixel value 0, the
         second by pixel value 1, etc.  The number of palette entries
         must not exceed the range that can be represented in the image
         bit depth (for example, 2^4 = 16 for a bit depth of 4).  It is
         permissible to have fewer entries than the bit depth would
         allow.  In that case, any out-of-range pixel value found in the
         image data is an error.

         For color types 2 and 6 (truecolor and truecolor with alpha),
         the PLTE chunk is optional.  If present, it provides a
         suggested set of from 1 to 256 colors to which the truecolor
         image can be quantized if the viewer cannot display truecolor
         directly.  If PLTE is not present, such a viewer will need to
         select colors on its own, but it is often preferable for this



Boutell, et. al.             Informational                     [Page 17]

RFC 2083            PNG: Portable Network Graphics            March 1997


         to be done once by the encoder.  (See Recommendations for
         Encoders: Suggested palettes, Section 9.5.)

         Note that the palette uses 8 bits (1 byte) per sample
         regardless of the image bit depth specification.  In
         particular, the palette is 8 bits deep even when it is a
         suggested quantization of a 16-bit truecolor image.

         There is no requirement that the palette entries all be used by
         the image, nor that they all be different.

      4.1.3. IDAT Image data

         The IDAT chunk contains the actual image data.  To create this
         data:

             * Begin with image scanlines represented as described in
               Image layout (Section 2.3); the layout and total size of
               this raw data are determined by the fields of IHDR.
             * Filter the image data according to the filtering method
               specified by the IHDR chunk.  (Note that with filter
               method 0, the only one currently defined, this implies
               prepending a filter type byte to each scanline.)
             * Compress the filtered data using the compression method
               specified by the IHDR chunk.

         The IDAT chunk contains the output datastream of the
         compression algorithm.

         To read the image data, reverse this process.

         There can be multiple IDAT chunks; if so, they must appear
         consecutively with no other intervening chunks.  The compressed
         datastream is then the concatenation of the contents of all the
         IDAT chunks.  The encoder can divide the compressed datastream
         into IDAT chunks however it wishes.  (Multiple IDAT chunks are
         allowed so that encoders can work in a fixed amount of memory;
         typically the chunk size will correspond to the encoder's
         buffer size.) It is important to emphasize that IDAT chunk
         boundaries have no semantic significance and can occur at any
         point in the compressed datastream.  A PNG file in which each
         IDAT chunk contains only one data byte is legal, though
         remarkably wasteful of space.  (For that matter, zero-length
         IDAT chunks are legal, though even more wasteful.)

         See Filter Algorithms (Chapter 6) and Deflate/Inflate
         Compression (Chapter 5) for details.




Boutell, et. al.             Informational                     [Page 18]

RFC 2083            PNG: Portable Network Graphics            March 1997


      4.1.4. IEND Image trailer

         The IEND chunk must appear LAST.  It marks the end of the PNG
         datastream.  The chunk's data field is empty.

   4.2. Ancillary chunks

      All ancillary chunks are optional, in the sense that encoders need
      not write them and decoders can ignore them.  However, encoders
      are encouraged to write the standard ancillary chunks when the
      information is available, and decoders are encouraged to interpret
      these chunks when appropriate and feasible.

      The standard ancillary chunks are listed in alphabetical order.
      This is not necessarily the order in which they would appear in a
      file.

      4.2.1. bKGD Background color

         The bKGD chunk specifies a default background color to present
         the image against.  Note that viewers are not bound to honor
         this chunk; a viewer can choose to use a different background.

         For color type 3 (indexed color), the bKGD chunk contains:

            Palette index:  1 byte

         The value is the palette index of the color to be used as
         background.

         For color types 0 and 4 (grayscale, with or without alpha),
         bKGD contains:

            Gray:  2 bytes, range 0 .. (2^bitdepth)-1

         (For consistency, 2 bytes are used regardless of the image bit
         depth.)  The value is the gray level to be used as background.

         For color types 2 and 6 (truecolor, with or without alpha),
         bKGD contains:

            Red:   2 bytes, range 0 .. (2^bitdepth)-1
            Green: 2 bytes, range 0 .. (2^bitdepth)-1
            Blue:  2 bytes, range 0 .. (2^bitdepth)-1

         (For consistency, 2 bytes per sample are used regardless of the
         image bit depth.)  This is the RGB color to be used as
         background.



Boutell, et. al.             Informational                     [Page 19]

RFC 2083            PNG: Portable Network Graphics            March 1997


         When present, the bKGD chunk must precede the first IDAT chunk,
         and must follow the PLTE chunk, if any.

         See Recommendations for Decoders: Background color (Section
         10.7).

      4.2.2. cHRM Primary chromaticities and white point

         Applications that need device-independent specification of
         colors in a PNG file can use the cHRM chunk to specify the 1931
         CIE x,y chromaticities of the red, green, and blue primaries
         used in the image, and the referenced white point. See Color
         Tutorial (Chapter 14) for more information.

         The cHRM chunk contains:

            White Point x: 4 bytes
            White Point y: 4 bytes
            Red x:         4 bytes
            Red y:         4 bytes
            Green x:       4 bytes
            Green y:       4 bytes
            Blue x:        4 bytes
            Blue y:        4 bytes

         Each value is encoded as a 4-byte unsigned integer,
         representing the x or y value times 100000.  For example, a
         value of 0.3127 would be stored as the integer 31270.

         cHRM is allowed in all PNG files, although it is of little
         value for grayscale images.

         If the encoder does not know the chromaticity values, it should
         not write a cHRM chunk; the absence of a cHRM chunk indicates
         that the image's primary colors are device-dependent.

         If the cHRM chunk appears, it must precede the first IDAT
         chunk, and it must also precede the PLTE chunk if present.

         See Recommendations for Encoders: Encoder color handling
         (Section 9.3), and Recommendations for Decoders: Decoder color
         handling (Section 10.6).









Boutell, et. al.             Informational                     [Page 20]

RFC 2083            PNG: Portable Network Graphics            March 1997


      4.2.3. gAMA Image gamma

         The gAMA chunk specifies the gamma of the camera (or simulated
         camera) that produced the image, and thus the gamma of the
         image with respect to the original scene.  More precisely, the
         gAMA chunk encodes the file_gamma value, as defined in Gamma
         Tutorial (Chapter 13).

         The gAMA chunk contains:

            Image gamma: 4 bytes

         The value is encoded as a 4-byte unsigned integer, representing
         gamma times 100000.  For example, a gamma of 0.45 would be
         stored as the integer 45000.

         If the encoder does not know the image's gamma value, it should
         not write a gAMA chunk; the absence of a gAMA chunk indicates
         that the gamma is unknown.

         If the gAMA chunk appears, it must precede the first IDAT
         chunk, and it must also precede the PLTE chunk if present.

         See Gamma correction (Section 2.7), Recommendations for
         Encoders: Encoder gamma handling (Section 9.2), and
         Recommendations for Decoders: Decoder gamma handling (Section
         10.5).

      4.2.4. hIST Image histogram

         The hIST chunk gives the approximate usage frequency of each
         color in the color palette.  A histogram chunk can appear only
         when a palette chunk appears.  If a viewer is unable to provide
         all the colors listed in the palette, the histogram may help it
         decide how to choose a subset of the colors for display.

         The hIST chunk contains a series of 2-byte (16 bit) unsigned
         integers.  There must be exactly one entry for each entry in
         the PLTE chunk.  Each entry is proportional to the fraction of
         pixels in the image that have that palette index; the exact
         scale factor is chosen by the encoder.

         Histogram entries are approximate, with the exception that a
         zero entry specifies that the corresponding palette entry is
         not used at all in the image.  It is required that a histogram
         entry be nonzero if there are any pixels of that color.





Boutell, et. al.             Informational                     [Page 21]

RFC 2083            PNG: Portable Network Graphics            March 1997


         When the palette is a suggested quantization of a truecolor
         image, the histogram is necessarily approximate, since a