Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2083

PNG (Portable Network Graphics) Specification Version 1.0

Pages: 102
Informational
Part 1 of 4 – Pages 1 to 15
None   None   Next

Top   ToC   RFC2083 - Page 1
Network Working Group                                T. Boutell, et. al.
Request for Comments: 2083                             Boutell.Com, Inc.
Category: Informational                                       March 1997


             PNG (Portable Network Graphics) Specification
                              Version 1.0

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

IESG Note:

   The IESG takes no position on the validity of any Intellectual
   Property Rights statements contained in this document.

Abstract

   This document describes PNG (Portable Network Graphics), an
   extensible file format for the lossless, portable, well-compressed
   storage of raster images.  PNG provides a patent-free replacement for
   GIF and can also replace many common uses of TIFF.  Indexed-color,
   grayscale, and truecolor images are supported, plus an optional alpha
   channel.  Sample depths range from 1 to 16 bits.

   PNG is designed to work well in online viewing applications, such as
   the World Wide Web, so it is fully streamable with a progressive
   display option.  PNG is robust, providing both full file integrity
   checking and simple detection of common transmission errors.  Also,
   PNG can store gamma and chromaticity data for improved color matching
   on heterogeneous platforms.

   This specification defines the Internet Media Type image/png.

Table of Contents

   1. Introduction ..................................................  4
   2. Data Representation ...........................................  5
      2.1. Integers and byte order ..................................  5
      2.2. Color values .............................................  6
      2.3. Image layout .............................................  6
      2.4. Alpha channel ............................................  7
      2.5. Filtering ................................................  8
      2.6. Interlaced data order ....................................  8
      2.7. Gamma correction ......................................... 10
Top   ToC   RFC2083 - Page 2
      2.8. Text strings ............................................. 10
   3. File Structure ................................................ 11
      3.1. PNG file signature ....................................... 11
      3.2. Chunk layout ............................................. 11
      3.3. Chunk naming conventions ................................. 12
      3.4. CRC algorithm ............................................ 15
   4. Chunk Specifications .......................................... 15
      4.1. Critical chunks .......................................... 15
          4.1.1. IHDR Image header .................................. 15
          4.1.2. PLTE Palette ....................................... 17
          4.1.3. IDAT Image data .................................... 18
          4.1.4. IEND Image trailer ................................. 19
      4.2. Ancillary chunks ......................................... 19
          4.2.1. bKGD Background color .............................. 19
          4.2.2. cHRM Primary chromaticities and white point ........ 20
          4.2.3. gAMA Image gamma ................................... 21
          4.2.4. hIST Image histogram ............................... 21
          4.2.5. pHYs Physical pixel dimensions ..................... 22
          4.2.6. sBIT Significant bits .............................. 22
          4.2.7. tEXt Textual data .................................. 24
          4.2.8. tIME Image last-modification time .................. 25
          4.2.9. tRNS Transparency .................................. 26
          4.2.10. zTXt Compressed textual data ...................... 27
      4.3. Summary of standard chunks ............................... 28
      4.4. Additional chunk types ................................... 29
   5. Deflate/Inflate Compression ................................... 29
   6. Filter Algorithms ............................................. 31
      6.1. Filter types ............................................. 31
      6.2. Filter type 0: None ...................................... 32
      6.3. Filter type 1: Sub ....................................... 33
      6.4. Filter type 2: Up ........................................ 33
      6.5. Filter type 3: Average ................................... 34
      6.6. Filter type 4: Paeth...................................... 35
   7. Chunk Ordering Rules .......................................... 36
      7.1. Behavior of PNG editors .................................. 37
      7.2. Ordering of ancillary chunks ............................. 38
      7.3. Ordering of critical chunks .............................. 38
   8. Miscellaneous Topics .......................................... 39
      8.1. File name extension ...................................... 39
      8.2. Internet media type ...................................... 39
      8.3. Macintosh file layout .................................... 39
      8.4. Multiple-image extension ................................. 39
      8.5. Security considerations .................................. 40
   9. Recommendations for Encoders .................................. 41
      9.1. Sample depth scaling ..................................... 41
      9.2. Encoder gamma handling ................................... 42
      9.3. Encoder color handling ................................... 45
      9.4. Alpha channel creation ................................... 47
Top   ToC   RFC2083 - Page 3
      9.5. Suggested palettes ....................................... 48
      9.6. Filter selection ......................................... 49
      9.7. Text chunk processing .................................... 49
      9.8. Use of private chunks .................................... 50
      9.9. Private type and method codes ............................ 51
   10. Recommendations for Decoders ................................. 51
      10.1. Error checking .......................................... 52
      10.2. Pixel dimensions ........................................ 52
      10.3. Truecolor image handling ................................ 52
      10.4. Sample depth rescaling .................................. 53
      10.5. Decoder gamma handling .................................. 54
      10.6. Decoder color handling .................................. 56
      10.7. Background color ........................................ 57
      10.8. Alpha channel processing ................................ 58
      10.9. Progressive display ..................................... 62
      10.10. Suggested-palette and histogram usage .................. 63
      10.11. Text chunk processing .................................. 64
   11. Glossary ..................................................... 65
   12. Appendix: Rationale .......................................... 69
      12.1. Why a new file format? .................................. 69
      12.2. Why these features? ..................................... 70
      12.3. Why not these features? ................................. 70
      12.4. Why not use format X? ................................... 72
      12.5. Byte order .............................................. 73
      12.6. Interlacing ............................................. 73
      12.7. Why gamma? .............................................. 73
      12.8. Non-premultiplied alpha ................................. 75
      12.9. Filtering ............................................... 75
      12.10. Text strings ........................................... 76
      12.11. PNG file signature ..................................... 77
      12.12. Chunk layout ........................................... 77
      12.13. Chunk naming conventions ............................... 78
      12.14. Palette histograms ..................................... 80
   13. Appendix: Gamma Tutorial ..................................... 81
   14. Appendix: Color Tutorial ..................................... 89
   15. Appendix: Sample CRC Code .................................... 94
   16. Appendix: Online Resources ................................... 96
   17. Appendix: Revision History ................................... 96
   18. References ................................................... 97
   19. Credits ......................................................100
Top   ToC   RFC2083 - Page 4
1. Introduction

   The PNG format provides a portable, legally unencumbered, well-
   compressed, well-specified standard for lossless bitmapped image
   files.

   Although the initial motivation for developing PNG was to replace
   GIF, the design provides some useful new features not available in
   GIF, with minimal cost to developers.

   GIF features retained in PNG include:

       * Indexed-color images of up to 256 colors.
       * Streamability: files can be read and written serially, thus
         allowing the file format to be used as a communications
         protocol for on-the-fly generation and display of images.
       * Progressive display: a suitably prepared image file can be
         displayed as it is received over a communications link,
         yielding a low-resolution image very quickly followed by
         gradual improvement of detail.
       * Transparency: portions of the image can be marked as
         transparent, creating the effect of a non-rectangular image.
       * Ancillary information: textual comments and other data can be
         stored within the image file.
       * Complete hardware and platform independence.
       * Effective, 100% lossless compression.

   Important new features of PNG, not available in GIF, include:

       * Truecolor images of up to 48 bits per pixel.
       * Grayscale images of up to 16 bits per pixel.
       * Full alpha channel (general transparency masks).
       * Image gamma information, which supports automatic display of
         images with correct brightness/contrast regardless of the
         machines used to originate and display the image.
       * Reliable, straightforward detection of file corruption.
       * Faster initial presentation in progressive display mode.

   PNG is designed to be:

       * Simple and portable: developers should be able to implement PNG
         easily.
       * Legally unencumbered: to the best knowledge of the PNG authors,
         no algorithms under legal challenge are used.  (Some
         considerable effort has been spent to verify this.)
       * Well compressed: both indexed-color and truecolor images are
         compressed as effectively as in any other widely used lossless
         format, and in most cases more effectively.
Top   ToC   RFC2083 - Page 5
       * Interchangeable: any standard-conforming PNG decoder must read
         all conforming PNG files.
       * Flexible: the format allows for future extensions and private
         add-ons, without compromising interchangeability of basic PNG.
       * Robust: the design supports full file integrity checking as
         well as simple, quick detection of common transmission errors.

   The main part of this specification gives the definition of the file
   format and recommendations for encoder and decoder behavior.  An
   appendix gives the rationale for many design decisions.  Although the
   rationale is not part of the formal specification, reading it can
   help implementors understand the design.  Cross-references in the
   main text point to relevant parts of the rationale.  Additional
   appendixes, also not part of the formal specification, provide
   tutorials on gamma and color theory as well as other supporting
   material.

   In this specification, the word "must" indicates a mandatory
   requirement, while "should" indicates recommended behavior.

   See Rationale: Why a new file format? (Section 12.1), Why these
   features? (Section 12.2), Why not these features? (Section 12.3), Why
   not use format X? (Section 12.4).

   Pronunciation

      PNG is pronounced "ping".

2. Data Representation

   This chapter discusses basic data representations used in PNG files,
   as well as the expected representation of the image data.

   2.1. Integers and byte order

      All integers that require more than one byte must be in network
      byte order: the most significant byte comes first, then the less
      significant bytes in descending order of significance (MSB LSB for
      two-byte integers, B3 B2 B1 B0 for four-byte integers).  The
      highest bit (value 128) of a byte is numbered bit 7; the lowest
      bit (value 1) is numbered bit 0. Values are unsigned unless
      otherwise noted. Values explicitly noted as signed are represented
      in two's complement notation.

      See Rationale: Byte order (Section 12.5).
Top   ToC   RFC2083 - Page 6
   2.2. Color values

      Colors can be represented by either grayscale or RGB (red, green,
      blue) sample data.  Grayscale data represents luminance; RGB data
      represents calibrated color information (if the cHRM chunk is
      present) or uncalibrated device-dependent color (if cHRM is
      absent).  All color values range from zero (representing black) to
      most intense at the maximum value for the sample depth.  Note that
      the maximum value at a given sample depth is (2^sampledepth)-1,
      not 2^sampledepth.

      Sample values are not necessarily linear; the gAMA chunk specifies
      the gamma characteristic of the source device, and viewers are
      strongly encouraged to compensate properly.  See Gamma correction
      (Section 2.7).

      Source data with a precision not directly supported in PNG (for
      example, 5 bit/sample truecolor) must be scaled up to the next
      higher supported bit depth.  This scaling is reversible with no
      loss of data, and it reduces the number of cases that decoders
      have to cope with.  See Recommendations for Encoders: Sample depth
      scaling (Section 9.1) and Recommendations for Decoders: Sample
      depth rescaling (Section 10.4).

   2.3. Image layout

      Conceptually, a PNG image is a rectangular pixel array, with
      pixels appearing left-to-right within each scanline, and scanlines
      appearing top-to-bottom.  (For progressive display purposes, the
      data may actually be transmitted in a different order; see
      Interlaced data order, Section 2.6.) The size of each pixel is
      determined by the bit depth, which is the number of bits per
      sample in the image data.

      Three types of pixel are supported:

          * An indexed-color pixel is represented by a single sample
            that is an index into a supplied palette.  The image bit
            depth determines the maximum number of palette entries, but
            not the color precision within the palette.
          * A grayscale pixel is represented by a single sample that is
            a grayscale level, where zero is black and the largest value
            for the bit depth is white.
          * A truecolor pixel is represented by three samples: red (zero
            = black, max = red) appears first, then green (zero = black,
            max = green), then blue (zero = black, max = blue).  The bit
            depth specifies the size of each sample, not the total pixel
            size.
Top   ToC   RFC2083 - Page 7
      Optionally, grayscale and truecolor pixels can also include an
      alpha sample, as described in the next section.

      Pixels are always packed into scanlines with no wasted bits
      between pixels.  Pixels smaller than a byte never cross byte
      boundaries; they are packed into bytes with the leftmost pixel in
      the high-order bits of a byte, the rightmost in the low-order
      bits.  Permitted bit depths and pixel types are restricted so that
      in all cases the packing is simple and efficient.

      PNG permits multi-sample pixels only with 8- and 16-bit samples,
      so multiple samples of a single pixel are never packed into one
      byte.  16-bit samples are stored in network byte order (MSB
      first).

      Scanlines always begin on byte boundaries.  When pixels have fewer
      than 8 bits and the scanline width is not evenly divisible by the
      number of pixels per byte, the low-order bits in the last byte of
      each scanline are wasted.  The contents of these wasted bits are
      unspecified.

      An additional "filter type" byte is added to the beginning of
      every scanline (see Filtering, Section 2.5).  The filter type byte
      is not considered part of the image data, but it is included in
      the datastream sent to the compression step.

   2.4. Alpha channel

      An alpha channel, representing transparency information on a per-
      pixel basis, can be included in grayscale and truecolor PNG
      images.

      An alpha value of zero represents full transparency, and a value
      of (2^bitdepth)-1 represents a fully opaque pixel.  Intermediate
      values indicate partially transparent pixels that can be combined
      with a background image to yield a composite image.  (Thus, alpha
      is really the degree of opacity of the pixel.  But most people
      refer to alpha as providing transparency information, not opacity
      information, and we continue that custom here.)

      Alpha channels can be included with images that have either 8 or
      16 bits per sample, but not with images that have fewer than 8
      bits per sample.  Alpha samples are represented with the same bit
      depth used for the image samples.  The alpha sample for each pixel
      is stored immediately following the grayscale or RGB samples of
      the pixel.
Top   ToC   RFC2083 - Page 8
      The color values stored for a pixel are not affected by the alpha
      value assigned to the pixel.  This rule is sometimes called
      "unassociated" or "non-premultiplied" alpha.  (Another common
      technique is to store sample values premultiplied by the alpha
      fraction; in effect, such an image is already composited against a
      black background.  PNG does not use premultiplied alpha.)

      Transparency control is also possible without the storage cost of
      a full alpha channel.  In an indexed-color image, an alpha value
      can be defined for each palette entry.  In grayscale and truecolor
      images, a single pixel value can be identified as being
      "transparent".  These techniques are controlled by the tRNS
      ancillary chunk type.

      If no alpha channel nor tRNS chunk is present, all pixels in the
      image are to be treated as fully opaque.

      Viewers can support transparency control partially, or not at all.

      See Rationale: Non-premultiplied alpha (Section 12.8),
      Recommendations for Encoders: Alpha channel creation (Section
      9.4), and Recommendations for Decoders: Alpha channel processing
      (Section 10.8).

   2.5. Filtering

      PNG allows the image data to be filtered before it is compressed.
      Filtering can improve the compressibility of the data.  The filter
      step itself does not reduce the size of the data.  All PNG filters
      are strictly lossless.

      PNG defines several different filter algorithms, including "None"
      which indicates no filtering.  The filter algorithm is specified
      for each scanline by a filter type byte that precedes the filtered
      scanline in the precompression datastream.  An intelligent encoder
      can switch filters from one scanline to the next.  The method for
      choosing which filter to employ is up to the encoder.

      See Filter Algorithms (Chapter 6) and Rationale: Filtering
      (Section 12.9).

   2.6. Interlaced data order

      A PNG image can be stored in interlaced order to allow progressive
      display.  The purpose of this feature is to allow images to "fade
      in" when they are being displayed on-the-fly.  Interlacing
      slightly expands the file size on average, but it gives the user a
      meaningful display much more rapidly.  Note that decoders are
Top   ToC   RFC2083 - Page 9
      required to be able to read interlaced images, whether or not they
      actually perform progressive display.

      With interlace method 0, pixels are stored sequentially from left
      to right, and scanlines sequentially from top to bottom (no
      interlacing).

      Interlace method 1, known as Adam7 after its author, Adam M.
      Costello, consists of seven distinct passes over the image.  Each
      pass transmits a subset of the pixels in the image.  The pass in
      which each pixel is transmitted is defined by replicating the
      following 8-by-8 pattern over the entire image, starting at the
      upper left corner:

         1 6 4 6 2 6 4 6
         7 7 7 7 7 7 7 7
         5 6 5 6 5 6 5 6
         7 7 7 7 7 7 7 7
         3 6 4 6 3 6 4 6
         7 7 7 7 7 7 7 7
         5 6 5 6 5 6 5 6
         7 7 7 7 7 7 7 7

      Within each pass, the selected pixels are transmitted left to
      right within a scanline, and selected scanlines sequentially from
      top to bottom.  For example, pass 2 contains pixels 4, 12, 20,
      etc. of scanlines 0, 8, 16, etc. (numbering from 0,0 at the upper
      left corner).  The last pass contains the entirety of scanlines 1,
      3, 5, etc.

      The data within each pass is laid out as though it were a complete
      image of the appropriate dimensions.  For example, if the complete
      image is 16 by 16 pixels, then pass 3 will contain two scanlines,
      each containing four pixels.  When pixels have fewer than 8 bits,
      each such scanline is padded as needed to fill an integral number
      of bytes (see Image layout, Section 2.3).  Filtering is done on
      this reduced image in the usual way, and a filter type byte is
      transmitted before each of its scanlines (see Filter Algorithms,
      Chapter 6).  Notice that the transmission order is defined so that
      all the scanlines transmitted in a pass will have the same number
      of pixels; this is necessary for proper application of some of the
      filters.

      Caution: If the image contains fewer than five columns or fewer
      than five rows, some passes will be entirely empty.  Encoders and
      decoders must handle this case correctly.  In particular, filter
      type bytes are only associated with nonempty scanlines; no filter
      type bytes are present in an empty pass.
Top   ToC   RFC2083 - Page 10
      See Rationale: Interlacing (Section 12.6) and Recommendations for
      Decoders: Progressive display (Section 10.9).

   2.7. Gamma correction

      PNG images can specify, via the gAMA chunk, the gamma
      characteristic of the image with respect to the original scene.
      Display programs are strongly encouraged to use this information,
      plus information about the display device they are using and room
      lighting, to present the image to the viewer in a way that
      reproduces what the image's original author saw as closely as
      possible.  See Gamma Tutorial (Chapter 13) if you aren't already
      familiar with gamma issues.

      Gamma correction is not applied to the alpha channel, if any.
      Alpha samples always represent a linear fraction of full opacity.

      For high-precision applications, the exact chromaticity of the RGB
      data in a PNG image can be specified via the cHRM chunk, allowing
      more accurate color matching than gamma correction alone will
      provide.  See Color Tutorial (Chapter 14) if you aren't already
      familiar with color representation issues.

      See Rationale: Why gamma? (Section 12.7), Recommendations for
      Encoders: Encoder gamma handling (Section 9.2), and
      Recommendations for Decoders: Decoder gamma handling (Section
      10.5).

   2.8. Text strings

      A PNG file can store text associated with the image, such as an
      image description or copyright notice.  Keywords are used to
      indicate what each text string represents.

      ISO 8859-1 (Latin-1) is the character set recommended for use in
      text strings [ISO-8859].  This character set is a superset of 7-
      bit ASCII.

      Character codes not defined in Latin-1 should not be used, because
      they have no platform-independent meaning.  If a non-Latin-1 code
      does appear in a PNG text string, its interpretation will vary
      across platforms and decoders.  Some systems might not even be
      able to display all the characters in Latin-1, but most modern
      systems can.

      Provision is also made for the storage of compressed text.

      See Rationale: Text strings (Section 12.10).
Top   ToC   RFC2083 - Page 11
3. File Structure

   A PNG file consists of a PNG signature followed by a series of
   chunks.  This chapter defines the signature and the basic properties
   of chunks.  Individual chunk types are discussed in the next chapter.

   3.1. PNG file signature

      The first eight bytes of a PNG file always contain the following
      (decimal) values:

         137 80 78 71 13 10 26 10

      This signature indicates that the remainder of the file contains a
      single PNG image, consisting of a series of chunks beginning with
      an IHDR chunk and ending with an IEND chunk.

      See Rationale: PNG file signature (Section 12.11).

   3.2. Chunk layout

      Each chunk consists of four parts:

      Length
         A 4-byte unsigned integer giving the number of bytes in the
         chunk's data field. The length counts only the data field, not
         itself, the chunk type code, or the CRC.  Zero is a valid
         length.  Although encoders and decoders should treat the length
         as unsigned, its value must not exceed (2^31)-1 bytes.

      Chunk Type
         A 4-byte chunk type code.  For convenience in description and
         in examining PNG files, type codes are restricted to consist of
         uppercase and lowercase ASCII letters (A-Z and a-z, or 65-90
         and 97-122 decimal).  However, encoders and decoders must treat
         the codes as fixed binary values, not character strings.  For
         example, it would not be correct to represent the type code
         IDAT by the EBCDIC equivalents of those letters.  Additional
         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.
Top   ToC   RFC2083 - Page 12
      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.
Top   ToC   RFC2083 - Page 13
      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.)
Top   ToC   RFC2083 - Page 14
      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.
Top   ToC   RFC2083 - Page 15
      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).



(page 15 continued on part 2)

Next Section