rfc2083.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

         naming conventions for chunk types are discussed in the next
         section.

      Chunk Data
         The data bytes appropriate to the chunk type, if any.  This
         field can be of zero length.







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


      CRC
         A 4-byte CRC (Cyclic Redundancy Check) calculated on the
         preceding bytes in the chunk, including the chunk type code and
         chunk data fields, but not including the length field. The CRC
         is always present, even for chunks containing no data.  See CRC
         algorithm (Section 3.4).

      The chunk data length can be any number of bytes up to the
      maximum; therefore, implementors cannot assume that chunks are
      aligned on any boundaries larger than bytes.

      Chunks can appear in any order, subject to the restrictions placed
      on each chunk type.  (One notable restriction is that IHDR must
      appear first and IEND must appear last; thus the IEND chunk serves
      as an end-of-file marker.)  Multiple chunks of the same type can
      appear, but only if specifically permitted for that type.

      See Rationale: Chunk layout (Section 12.12).

   3.3. Chunk naming conventions

      Chunk type codes are assigned so that a decoder can determine some
      properties of a chunk even when it does not recognize the type
      code.  These rules are intended to allow safe, flexible extension
      of the PNG format, by allowing a decoder to decide what to do when
      it encounters an unknown chunk.  The naming rules are not normally
      of interest when the decoder does recognize the chunk's type.

      Four bits of the type code, namely bit 5 (value 32) of each byte,
      are used to convey chunk properties.  This choice means that a
      human can read off the assigned properties according to whether
      each letter of the type code is uppercase (bit 5 is 0) or
      lowercase (bit 5 is 1).  However, decoders should test the
      properties of an unknown chunk by numerically testing the
      specified bits; testing whether a character is uppercase or
      lowercase is inefficient, and even incorrect if a locale-specific
      case definition is used.

      It is worth noting that the property bits are an inherent part of
      the chunk name, and hence are fixed for any chunk type.  Thus,
      TEXT and Text would be unrelated chunk type codes, not the same
      chunk with different properties.  Decoders must recognize type
      codes by a simple four-byte literal comparison; it is incorrect to
      perform case conversion on type codes.







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


      The semantics of the property bits are:

      Ancillary bit: bit 5 of first byte
         0 (uppercase) = critical, 1 (lowercase) = ancillary.

         Chunks that are not strictly necessary in order to meaningfully
         display the contents of the file are known as "ancillary"
         chunks.  A decoder encountering an unknown chunk in which the
         ancillary bit is 1 can safely ignore the chunk and proceed to
         display the image. The time chunk (tIME) is an example of an
         ancillary chunk.

         Chunks that are necessary for successful display of the file's
         contents are called "critical" chunks. A decoder encountering
         an unknown chunk in which the ancillary bit is 0 must indicate
         to the user that the image contains information it cannot
         safely interpret.  The image header chunk (IHDR) is an example
         of a critical chunk.

      Private bit: bit 5 of second byte
         0 (uppercase) = public, 1 (lowercase) = private.

         A public chunk is one that is part of the PNG specification or
         is registered in the list of PNG special-purpose public chunk
         types.  Applications can also define private (unregistered)
         chunks for their own purposes.  The names of private chunks
         must have a lowercase second letter, while public chunks will
         always be assigned names with uppercase second letters.  Note
         that decoders do not need to test the private-chunk property
         bit, since it has no functional significance; it is simply an
         administrative convenience to ensure that public and private
         chunk names will not conflict.  See Additional chunk types
         (Section 4.4) and Recommendations for Encoders: Use of private
         chunks (Section 9.8).

      Reserved bit: bit 5 of third byte
         Must be 0 (uppercase) in files conforming to this version of
         PNG.

         The significance of the case of the third letter of the chunk
         name is reserved for possible future expansion.  At the present
         time all chunk names must have uppercase third letters.
         (Decoders should not complain about a lowercase third letter,
         however, as some future version of the PNG specification could
         define a meaning for this bit.  It is sufficient to treat a
         chunk with a lowercase third letter in the same way as any
         other unknown chunk type.)




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


      Safe-to-copy bit: bit 5 of fourth byte
         0 (uppercase) = unsafe to copy, 1 (lowercase) = safe to copy.

         This property bit is not of interest to pure decoders, but it
         is needed by PNG editors (programs that modify PNG files).
         This bit defines the proper handling of unrecognized chunks in
         a file that is being modified.

         If a chunk's safe-to-copy bit is 1, the chunk may be copied to
         a modified PNG file whether or not the software recognizes the
         chunk type, and regardless of the extent of the file
         modifications.

         If a chunk's safe-to-copy bit is 0, it indicates that the chunk
         depends on the image data.  If the program has made any changes
         to critical chunks, including addition, modification, deletion,
         or reordering of critical chunks, then unrecognized unsafe
         chunks must not be copied to the output PNG file.  (Of course,
         if the program does recognize the chunk, it can choose to
         output an appropriately modified version.)

         A PNG editor is always allowed to copy all unrecognized chunks
         if it has only added, deleted, modified, or reordered ancillary
         chunks.  This implies that it is not permissible for ancillary
         chunks to depend on other ancillary chunks.

         PNG editors that do not recognize a critical chunk must report
         an error and refuse to process that PNG file at all. The
         safe/unsafe mechanism is intended for use with ancillary
         chunks.  The safe-to-copy bit will always be 0 for critical
         chunks.

         Rules for PNG editors are discussed further in Chunk Ordering
         Rules (Chapter 7).

      For example, the hypothetical chunk type name "bLOb" has the
      property bits:

         bLOb  <-- 32 bit chunk type code represented in text form
         ||||
         |||+- Safe-to-copy bit is 1 (lower case letter; bit 5 is 1)
         ||+-- Reserved bit is 0     (upper case letter; bit 5 is 0)
         |+--- Private bit is 0      (upper case letter; bit 5 is 0)
         +---- Ancillary bit is 1    (lower case letter; bit 5 is 1)

      Therefore, this name represents an ancillary, public, safe-to-copy
      chunk.




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


      See Rationale: Chunk naming conventions (Section 12.13).

   3.4. CRC algorithm

      Chunk CRCs are calculated using standard CRC methods with pre and
      post conditioning, as defined by ISO 3309 [ISO-3309] or ITU-T V.42
      [ITU-V42].  The CRC polynomial employed is

         x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1

      The 32-bit CRC register is initialized to all 1's, and then the
      data from each byte is processed from the least significant bit
      (1) to the most significant bit (128).  After all the data bytes
      are processed, the CRC register is inverted (its ones complement
      is taken).  This value is transmitted (stored in the file) MSB
      first.  For the purpose of separating into bytes and ordering, the
      least significant bit of the 32-bit CRC is defined to be the
      coefficient of the x^31 term.

      Practical calculation of the CRC always employs a precalculated
      table to greatly accelerate the computation. See Sample CRC Code
      (Chapter 15).

4. Chunk Specifications

   This chapter defines the standard types of PNG chunks.

   4.1. Critical chunks

      All implementations must understand and successfully render the
      standard critical chunks.  A valid PNG image must contain an IHDR
      chunk, one or more IDAT chunks, and an IEND chunk.

      4.1.1. IHDR Image header

         The IHDR chunk must appear FIRST.  It contains:

            Width:              4 bytes
            Height:             4 bytes
            Bit depth:          1 byte
            Color type:         1 byte
            Compression method: 1 byte
            Filter method:      1 byte
            Interlace method:   1 byte







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


         Width and height give the image dimensions in pixels.  They are
         4-byte integers. Zero is an invalid value. The maximum for each
         is (2^31)-1 in order to accommodate languages that have
         difficulty with unsigned 4-byte values.

         Bit depth is a single-byte integer giving the number of bits
         per sample or per palette index (not per pixel).  Valid values
         are 1, 2, 4, 8, and 16, although not all values are allowed for
         all color types.

         Color type is a single-byte integer that describes the
         interpretation of the image data.  Color type codes represent
         sums of the following values: 1 (palette used), 2 (color used),
         and 4 (alpha channel used). Valid values are 0, 2, 3, 4, and 6.

         Bit depth restrictions for each color type are imposed to
         simplify implementations and to prohibit combinations that do
         not compress well.  Decoders must support all legal
         combinations of bit depth and color type.  The allowed
         combinations are:

            Color    Allowed    Interpretation
            Type    Bit Depths

            0       1,2,4,8,16  Each pixel is a grayscale sample.

            2       8,16        Each pixel is an R,G,B triple.

            3       1,2,4,8     Each pixel is a palette index;
                                a PLTE chunk must appear.

            4       8,16        Each pixel is a grayscale sample,
                                followed by an alpha sample.

            6       8,16        Each pixel is an R,G,B triple,
                                followed by an alpha sample.

         The sample depth is the same as the bit depth except in the
         case of color type 3, in which the sample depth is always 8
         bits.

         Compression method is a single-byte integer that indicates the
         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