GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2083

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

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

    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

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

    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

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

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.

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

  • 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).

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

 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.

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

    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.

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

    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

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

    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.

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

    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).

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

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.

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
       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
       decoder may map pixels to palette entries differently than the
       encoder did.  In this situation, zero entries should not
       appear.
       The hIST chunk, if it appears, must follow the PLTE chunk, and
       must precede the first IDAT chunk.
       See Rationale: Palette histograms (Section 12.14), and
       Recommendations for Decoders: Suggested-palette and histogram
       usage (Section 10.10).
    4.2.5. pHYs Physical pixel dimensions
       The pHYs chunk specifies the intended pixel size or aspect
       ratio for display of the image.  It contains:
          Pixels per unit, X axis: 4 bytes (unsigned integer)
          Pixels per unit, Y axis: 4 bytes (unsigned integer)
          Unit specifier:          1 byte
       The following values are legal for the unit specifier:
          0: unit is unknown
          1: unit is the meter
       When the unit specifier is 0, the pHYs chunk defines pixel
       aspect ratio only; the actual size of the pixels remains
       unspecified.
       Conversion note: one inch is equal to exactly 0.0254 meters.
       If this ancillary chunk is not present, pixels are assumed to
       be square, and the physical size of each pixel is unknown.
       If present, this chunk must precede the first IDAT chunk.
       See Recommendations for Decoders: Pixel dimensions (Section
       10.2).
    4.2.6. sBIT Significant bits
       To simplify decoders, PNG specifies that only certain sample
       depths can be used, and further specifies that sample values
       should be scaled to the full range of possible values at the
       sample depth.  However, the sBIT chunk is provided in order to
       store the original number of significant bits.  This allows

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

       decoders to recover the original data losslessly even if the
       data had a sample depth not directly supported by PNG.  We
       recommend that an encoder emit an sBIT chunk if it has
       converted the data from a lower sample depth.
       For color type 0 (grayscale), the sBIT chunk contains a single
       byte, indicating the number of bits that were significant in
       the source data.
       For color type 2 (truecolor), the sBIT chunk contains three
       bytes, indicating the number of bits that were significant in
       the source data for the red, green, and blue channels,
       respectively.
       For color type 3 (indexed color), the sBIT chunk contains three
       bytes, indicating the number of bits that were significant in
       the source data for the red, green, and blue components of the
       palette entries, respectively.
       For color type 4 (grayscale with alpha channel), the sBIT chunk
       contains two bytes, indicating the number of bits that were
       significant in the source grayscale data and the source alpha
       data, respectively.
       For color type 6 (truecolor with alpha channel), the sBIT chunk
       contains four bytes, indicating the number of bits that were
       significant in the source data for the red, green, blue and
       alpha channels, respectively.
       Each depth specified in sBIT must be greater than zero and less
       than or equal to the sample depth (which is 8 for indexed-color
       images, and the bit depth given in IHDR for other color types).
       A decoder need not pay attention to sBIT: the stored image is a
       valid PNG file of the sample depth indicated by IHDR.  However,
       if the decoder wishes to recover the original data at its
       original precision, this can be done by right-shifting the
       stored samples (the stored palette entries, for an indexed-
       color image).  The encoder must scale the data in such a way
       that the high-order bits match the original data.
       If the sBIT chunk appears, it must precede the first IDAT
       chunk, and it must also precede the PLTE chunk if present.
       See Recommendations for Encoders: Sample depth scaling (Section
       9.1) and Recommendations for Decoders: Sample depth rescaling
       (Section 10.4).

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

    4.2.7. tEXt Textual data
       Textual information that the encoder wishes to record with the
       image can be stored in tEXt chunks.  Each tEXt chunk contains a
       keyword and a text string, in the format:
          Keyword:        1-79 bytes (character string)
          Null separator: 1 byte
          Text:           n bytes (character string)
       The keyword and text string are separated by a zero byte (null
       character).  Neither the keyword nor the text string can
       contain a null character.  Note that the text string is not
       null-terminated (the length of the chunk is sufficient
       information to locate the ending).  The keyword must be at
       least one character and less than 80 characters long.  The text
       string can be of any length from zero bytes up to the maximum
       permissible chunk size less the length of the keyword and
       separator.
       Any number of tEXt chunks can appear, and more than one with
       the same keyword is permissible.
       The keyword indicates the type of information represented by
       the text string.  The following keywords are predefined and
       should be used where appropriate:
          Title            Short (one line) title or caption for image
          Author           Name of image's creator
          Description      Description of image (possibly long)
          Copyright        Copyright notice
          Creation Time    Time of original image creation
          Software         Software used to create the image
          Disclaimer       Legal disclaimer
          Warning          Warning of nature of content
          Source           Device used to create the image
          Comment          Miscellaneous comment; conversion from
                           GIF comment
       For the Creation Time keyword, the date format defined in
       section 5.2.14 of RFC 1123 is suggested, but not required
       [RFC-1123].  Decoders should allow for free-format text
       associated with this or any other keyword.
       Other keywords may be invented for other purposes.  Keywords of
       general interest can be registered with the maintainers of the
       PNG specification.  However, it is also permitted to use
       private unregistered keywords.  (Private keywords should be

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

       reasonably self-explanatory, in order to minimize the chance
       that the same keyword will be used for incompatible purposes by
       different people.)
       Both keyword and text are interpreted according to the ISO
       8859-1 (Latin-1) character set [ISO-8859].  The text string can
       contain any Latin-1 character.  Newlines in the text string
       should be represented by a single linefeed character (decimal
       10); use of other control characters in the text is
       discouraged.
       Keywords must contain only printable Latin-1 characters and
       spaces; that is, only character codes 32-126 and 161-255
       decimal are allowed.  To reduce the chances for human
       misreading of a keyword, leading and trailing spaces are
       forbidden, as are consecutive spaces.  Note also that the non-
       breaking space (code 160) is not permitted in keywords, since
       it is visually indistinguishable from an ordinary space.
       Keywords must be spelled exactly as registered, so that
       decoders can use simple literal comparisons when looking for
       particular keywords.  In particular, keywords are considered
       case-sensitive.
       See Recommendations for Encoders: Text chunk processing
       (Section 9.7) and Recommendations for Decoders: Text chunk
       processing (Section 10.11).
    4.2.8. tIME Image last-modification time
       The tIME chunk gives the time of the last image modification
       (not the time of initial image creation).  It contains:
          Year:   2 bytes (complete; for example, 1995, not 95)
          Month:  1 byte (1-12)
          Day:    1 byte (1-31)
          Hour:   1 byte (0-23)
          Minute: 1 byte (0-59)
          Second: 1 byte (0-60)    (yes, 60, for leap seconds; not 61,
                                    a common error)
       Universal Time (UTC, also called GMT) should be specified
       rather than local time.

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

       The tIME chunk is intended for use as an automatically-applied
       time stamp that is updated whenever the image data is changed.
       It is recommended that tIME not be changed by PNG editors that
       do not change the image data.  See also the Creation Time tEXt
       keyword, which can be used for a user-supplied time.
    4.2.9. tRNS Transparency
       The tRNS chunk specifies that the image uses simple
       transparency: either alpha values associated with palette
       entries (for indexed-color images) or a single transparent
       color (for grayscale and truecolor images).  Although simple
       transparency is not as elegant as the full alpha channel, it
       requires less storage space and is sufficient for many common
       cases.
       For color type 3 (indexed color), the tRNS chunk contains a
       series of one-byte alpha values, corresponding to entries in
       the PLTE chunk:
          Alpha for palette index 0:  1 byte
          Alpha for palette index 1:  1 byte
          ... etc ...
       Each entry indicates that pixels of the corresponding palette
       index must be treated as having the specified alpha value.
       Alpha values have the same interpretation as in an 8-bit full
       alpha channel: 0 is fully transparent, 255 is fully opaque,
       regardless of image bit depth. The tRNS chunk must not contain
       more alpha values than there are palette entries, but tRNS can
       contain fewer values than there are palette entries.  In this
       case, the alpha value for all remaining palette entries is
       assumed to be 255.  In the common case in which only palette
       index 0 need be made transparent, only a one-byte tRNS chunk is
       needed.
       For color type 0 (grayscale), the tRNS chunk contains a single
       gray level value, stored in the format:
          Gray:  2 bytes, range 0 .. (2^bitdepth)-1
       (For consistency, 2 bytes are used regardless of the image bit
       depth.) Pixels of the specified gray level are to be treated as
       transparent (equivalent to alpha value 0); all other pixels are
       to be treated as fully opaque (alpha value (2^bitdepth)-1).

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

       For color type 2 (truecolor), the tRNS chunk contains a single
       RGB color value, stored in the format:
          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.) Pixels of the specified color value are to be
       treated as transparent (equivalent to alpha value 0); all other
       pixels are to be treated as fully opaque (alpha value
       (2^bitdepth)-1).
       tRNS is prohibited for color types 4 and 6, since a full alpha
       channel is already present in those cases.
       Note: when dealing with 16-bit grayscale or truecolor data, it
       is important to compare both bytes of the sample values to
       determine whether a pixel is transparent.  Although decoders
       may drop the low-order byte of the samples for display, this
       must not occur until after the data has been tested for
       transparency.  For example, if the grayscale level 0x0001 is
       specified to be transparent, it would be incorrect to compare
       only the high-order byte and decide that 0x0002 is also
       transparent.
       When present, the tRNS chunk must precede the first IDAT chunk,
       and must follow the PLTE chunk, if any.
    4.2.10. zTXt Compressed textual data
       The zTXt chunk contains textual data, just as tEXt does;
       however, zTXt takes advantage of compression.  zTXt and tEXt
       chunks are semantically equivalent, but zTXt is recommended for
       storing large blocks of text.
       A zTXt chunk contains:
          Keyword:            1-79 bytes (character string)
          Null separator:     1 byte
          Compression method: 1 byte
          Compressed text:    n bytes
       The keyword and null separator are exactly the same as in the
       tEXt chunk.  Note that the keyword is not compressed.  The
       compression method byte identifies the compression method used
       in this zTXt chunk.  The only value presently defined for it is
       0 (deflate/inflate compression). The compression method byte is

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

       followed by a compressed datastream that makes up the remainder
       of the chunk.  For compression method 0, this datastream
       adheres to the zlib datastream format (see Deflate/Inflate
       Compression, Chapter 5).  Decompression of this datastream
       yields Latin-1 text that is identical to the text that would be
       stored in an equivalent tEXt chunk.
       Any number of zTXt and tEXt chunks can appear in the same file.
       See the preceding definition of the tEXt chunk for the
       predefined keywords and the recommended format of the text.
       See Recommendations for Encoders: Text chunk processing
       (Section 9.7), and Recommendations for Decoders: Text chunk
       processing (Section 10.11).
 4.3. Summary of standard chunks
    This table summarizes some properties of the standard chunk types.
       Critical chunks (must appear in this order, except PLTE
                        is optional):
               Name  Multiple  Ordering constraints
                       OK?
               IHDR    No      Must be first
               PLTE    No      Before IDAT
               IDAT    Yes     Multiple IDATs must be consecutive
               IEND    No      Must be last
       Ancillary chunks (need not appear in this order):
               Name  Multiple  Ordering constraints
                       OK?
               cHRM    No      Before PLTE and IDAT
               gAMA    No      Before PLTE and IDAT
               sBIT    No      Before PLTE and IDAT
               bKGD    No      After PLTE; before IDAT
               hIST    No      After PLTE; before IDAT
               tRNS    No      After PLTE; before IDAT
               pHYs    No      Before IDAT
               tIME    No      None
               tEXt    Yes     None
               zTXt    Yes     None

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

    Standard keywords for tEXt and zTXt chunks:
       Title            Short (one line) title or caption for image
       Author           Name of image's creator
       Description      Description of image (possibly long)
       Copyright        Copyright notice
       Creation Time    Time of original image creation
       Software         Software used to create the image
       Disclaimer       Legal disclaimer
       Warning          Warning of nature of content
       Source           Device used to create the image
       Comment          Miscellaneous comment; conversion from
                        GIF comment
 4.4. Additional chunk types
    Additional public PNG chunk types are defined in the document "PNG
    Special-Purpose Public Chunks" [PNG-EXTENSIONS].  Chunks described
    there are expected to be less widely supported than those defined
    in this specification.  However, application authors are
    encouraged to use those chunk types whenever appropriate for their
    applications.  Additional chunk types can be proposed for
    inclusion in that list by contacting the PNG specification
    maintainers at png-info@uunet.uu.net or at png-group@w3.org.
    New public chunks will only be registered if they are of use to
    others and do not violate the design philosophy of PNG. Chunk
    registration is not automatic, although it is the intent of the
    authors that it be straightforward when a new chunk of potentially
    wide application is needed.  Note that the creation of new
    critical chunk types is discouraged unless absolutely necessary.
    Applications can also use private chunk types to carry data that
    is not of interest to other applications.  See Recommendations for
    Encoders: Use of private chunks (Section 9.8).
    Decoders must be prepared to encounter unrecognized public or
    private chunk type codes.  Unrecognized chunk types must be
    handled as described in Chunk naming conventions (Section 3.3).

5. Deflate/Inflate Compression

 PNG compression method 0 (the only compression method presently
 defined for PNG) specifies deflate/inflate compression with a 32K
 sliding window.  Deflate compression is an LZ77 derivative used in
 zip, gzip, pkzip and related programs.  Extensive research has been
 done supporting its patent-free status.  Portable C implementations
 are freely available.

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

 Deflate-compressed datastreams within PNG are stored in the "zlib"
 format, which has the structure:
    Compression method/flags code: 1 byte
    Additional flags/check bits:   1 byte
    Compressed data blocks:        n bytes
    Check value:                   4 bytes
 Further details on this format are given in the zlib specification
 [RFC-1950].
 For PNG compression method 0, the zlib compression method/flags code
 must specify method code 8 ("deflate" compression) and an LZ77 window
 size of not more than 32K.  Note that the zlib compression method
 number is not the same as the PNG compression method number.  The
 additional flags must not specify a preset dictionary.
 The compressed data within the zlib datastream is stored as a series
 of blocks, each of which can represent raw (uncompressed) data,
 LZ77-compressed data encoded with fixed Huffman codes, or LZ77-
 compressed data encoded with custom Huffman codes.  A marker bit in
 the final block identifies it as the last block, allowing the decoder
 to recognize the end of the compressed datastream.  Further details
 on the compression algorithm and the encoding are given in the
 deflate specification [RFC-1951].
 The check value stored at the end of the zlib datastream is
 calculated on the uncompressed data represented by the datastream.
 Note that the algorithm used is not the same as the CRC calculation
 used for PNG chunk check values.  The zlib check value is useful
 mainly as a cross-check that the deflate and inflate algorithms are
 implemented correctly.  Verifying the chunk CRCs provides adequate
 confidence that the PNG file has been transmitted undamaged.
 In a PNG file, the concatenation of the contents of all the IDAT
 chunks makes up a zlib datastream as specified above.  This
 datastream decompresses to filtered image data as described elsewhere
 in this document.
 It is important to emphasize that the boundaries between IDAT chunks
 are arbitrary and can fall anywhere in the zlib datastream.  There is
 not necessarily any correlation between IDAT chunk boundaries and
 deflate block boundaries or any other feature of the zlib data.  For
 example, it is entirely possible for the terminating zlib check value
 to be split across IDAT chunks.

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

 In the same vein, there is no required correlation between the
 structure of the image data (i.e., scanline boundaries) and deflate
 block boundaries or IDAT chunk boundaries.  The complete image data
 is represented by a single zlib datastream that is stored in some
 number of IDAT chunks; a decoder that assumes any more than this is
 incorrect.  (Of course, some encoder implementations may emit files
 in which some of these structures are indeed related.  But decoders
 cannot rely on this.)
 PNG also uses zlib datastreams in zTXt chunks.  In a zTXt chunk, the
 remainder of the chunk following the compression method byte is a
 zlib datastream as specified above.  This datastream decompresses to
 the user-readable text described by the chunk's keyword.  Unlike the
 image data, such datastreams are not split across chunks; each zTXt
 chunk contains an independent zlib datastream.
 Additional documentation and portable C code for deflate and inflate
 are available from the Info-ZIP archives at
 <URL:ftp://ftp.uu.net/pub/archiving/zip/>.

6. Filter Algorithms

 This chapter describes the filter algorithms that can be applied
 before compression.  The purpose of these filters is to prepare the
 image data for optimum compression.
 6.1. Filter types
    PNG filter method 0 defines five basic filter types:
       Type    Name
       0       None
       1       Sub
       2       Up
       3       Average
       4       Paeth
    (Note that filter method 0 in IHDR specifies exactly this set of
    five filter types.  If the set of filter types is ever extended, a
    different filter method number will be assigned to the extended
    set, so that decoders need not decompress the data to discover
    that it contains unsupported filter types.)
    The encoder can choose which of these filter algorithms to apply
    on a scanline-by-scanline basis.  In the image data sent to the
    compression step, each scanline is preceded by a filter type byte
    that specifies the filter algorithm used for that scanline.

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

    Filtering algorithms are applied to bytes, not to pixels,
    regardless of the bit depth or color type of the image.  The
    filtering algorithms work on the byte sequence formed by a
    scanline that has been represented as described in Image layout
    (Section 2.3).  If the image includes an alpha channel, the alpha
    data is filtered in the same way as the image data.
    When the image is interlaced, each pass of the interlace pattern
    is treated as an independent image for filtering purposes.  The
    filters work on the byte sequences formed by the pixels actually
    transmitted during a pass, and the "previous scanline" is the one
    previously transmitted in the same pass, not the one adjacent in
    the complete image.  Note that the subimage transmitted in any one
    pass is always rectangular, but is of smaller width and/or height
    than the complete image.  Filtering is not applied when this
    subimage is empty.
    For all filters, the bytes "to the left of" the first pixel in a
    scanline must be treated as being zero.  For filters that refer to
    the prior scanline, the entire prior scanline must be treated as
    being zeroes for the first scanline of an image (or of a pass of
    an interlaced image).
    To reverse the effect of a filter, the decoder must use the
    decoded values of the prior pixel on the same line, the pixel
    immediately above the current pixel on the prior line, and the
    pixel just to the left of the pixel above.  This implies that at
    least one scanline's worth of image data will have to be stored by
    the decoder at all times.  Even though some filter types do not
    refer to the prior scanline, the decoder will always need to store
    each scanline as it is decoded, since the next scanline might use
    a filter that refers to it.
    PNG imposes no restriction on which filter types can be applied to
    an image.  However, the filters are not equally effective on all
    types of data.  See Recommendations for Encoders: Filter selection
    (Section 9.6).
    See also Rationale: Filtering (Section 12.9).
 6.2. Filter type 0: None
    With the None filter, the scanline is transmitted unmodified; it
    is only necessary to insert a filter type byte before the data.

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

 6.3. Filter type 1: Sub
    The Sub filter transmits the difference between each byte and the
    value of the corresponding byte of the prior pixel.
    To compute the Sub filter, apply the following formula to each
    byte of the scanline:
       Sub(x) = Raw(x) - Raw(x-bpp)
    where x ranges from zero to the number of bytes representing the
    scanline minus one, Raw(x) refers to the raw data byte at that
    byte position in the scanline, and bpp is defined as the number of
    bytes per complete pixel, rounding up to one. For example, for
    color type 2 with a bit depth of 16, bpp is equal to 6 (three
    samples, two bytes per sample); for color type 0 with a bit depth
    of 2, bpp is equal to 1 (rounding up); for color type 4 with a bit
    depth of 16, bpp is equal to 4 (two-byte grayscale sample, plus
    two-byte alpha sample).
    Note this computation is done for each byte, regardless of bit
    depth.  In a 16-bit image, each MSB is predicted from the
    preceding MSB and each LSB from the preceding LSB, because of the
    way that bpp is defined.
    Unsigned arithmetic modulo 256 is used, so that both the inputs
    and outputs fit into bytes.  The sequence of Sub values is
    transmitted as the filtered scanline.
    For all x < 0, assume Raw(x) = 0.
    To reverse the effect of the Sub filter after decompression,
    output the following value:
       Sub(x) + Raw(x-bpp)
    (computed mod 256), where Raw refers to the bytes already decoded.
 6.4. Filter type 2: Up
    The Up filter is just like the Sub filter except that the pixel
    immediately above the current pixel, rather than just to its left,
    is used as the predictor.
    To compute the Up filter, apply the following formula to each byte
    of the scanline:
       Up(x) = Raw(x) - Prior(x)

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

    where x ranges from zero to the number of bytes representing the
    scanline minus one, Raw(x) refers to the raw data byte at that
    byte position in the scanline, and Prior(x) refers to the
    unfiltered bytes of the prior scanline.
    Note this is done for each byte, regardless of bit depth.
    Unsigned arithmetic modulo 256 is used, so that both the inputs
    and outputs fit into bytes.  The sequence of Up values is
    transmitted as the filtered scanline.
    On the first scanline of an image (or of a pass of an interlaced
    image), assume Prior(x) = 0 for all x.
    To reverse the effect of the Up filter after decompression, output
    the following value:
       Up(x) + Prior(x)
    (computed mod 256), where Prior refers to the decoded bytes of the
    prior scanline.
 6.5. Filter type 3: Average
    The Average filter uses the average of the two neighboring pixels
    (left and above) to predict the value of a pixel.
    To compute the Average filter, apply the following formula to each
    byte of the scanline:
       Average(x) = Raw(x) - floor((Raw(x-bpp)+Prior(x))/2)
    where x ranges from zero to the number of bytes representing the
    scanline minus one, Raw(x) refers to the raw data byte at that
    byte position in the scanline, Prior(x) refers to the unfiltered
    bytes of the prior scanline, and bpp is defined as for the Sub
    filter.
    Note this is done for each byte, regardless of bit depth.  The
    sequence of Average values is transmitted as the filtered
    scanline.
    The subtraction of the predicted value from the raw byte must be
    done modulo 256, so that both the inputs and outputs fit into
    bytes.  However, the sum Raw(x-bpp)+Prior(x) must be formed
    without overflow (using at least nine-bit arithmetic).  floor()
    indicates that the result of the division is rounded to the next
    lower integer if fractional; in other words, it is an integer
    division or right shift operation.

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

    For all x < 0, assume Raw(x) = 0.  On the first scanline of an
    image (or of a pass of an interlaced image), assume Prior(x) = 0
    for all x.
    To reverse the effect of the Average filter after decompression,
    output the following value:
       Average(x) + floor((Raw(x-bpp)+Prior(x))/2)
    where the result is computed mod 256, but the prediction is
    calculated in the same way as for encoding.  Raw refers to the
    bytes already decoded, and Prior refers to the decoded bytes of
    the prior scanline.
 6.6. Filter type 4: Paeth
    The Paeth filter computes a simple linear function of the three
    neighboring pixels (left, above, upper left), then chooses as
    predictor the neighboring pixel closest to the computed value.
    This technique is due to Alan W. Paeth [PAETH].
    To compute the Paeth filter, apply the following formula to each
    byte of the scanline:
       Paeth(x) = Raw(x) - PaethPredictor(Raw(x-bpp), Prior(x),
                                          Prior(x-bpp))
    where x ranges from zero to the number of bytes representing the
    scanline minus one, Raw(x) refers to the raw data byte at that
    byte position in the scanline, Prior(x) refers to the unfiltered
    bytes of the prior scanline, and bpp is defined as for the Sub
    filter.
    Note this is done for each byte, regardless of bit depth.
    Unsigned arithmetic modulo 256 is used, so that both the inputs
    and outputs fit into bytes.  The sequence of Paeth values is
    transmitted as the filtered scanline.

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

    The PaethPredictor function is defined by the following
    pseudocode:
       function PaethPredictor (a, b, c)
       begin
            ; a = left, b = above, c = upper left
            p := a + b - c        ; initial estimate
            pa := abs(p - a)      ; distances to a, b, c
            pb := abs(p - b)
            pc := abs(p - c)
            ; return nearest of a,b,c,
            ; breaking ties in order a,b,c.
            if pa <= pb AND pa <= pc then return a
            else if pb <= pc then return b
            else return c
       end
    The calculations within the PaethPredictor function must be
    performed exactly, without overflow.  Arithmetic modulo 256 is to
    be used only for the final step of subtracting the function result
    from the target byte value.
    Note that the order in which ties are broken is critical and must
    not be altered.  The tie break order is: pixel to the left, pixel
    above, pixel to the upper left.  (This order differs from that
    given in Paeth's article.)
    For all x < 0, assume Raw(x) = 0 and Prior(x) = 0.  On the first
    scanline of an image (or of a pass of an interlaced image), assume
    Prior(x) = 0 for all x.
    To reverse the effect of the Paeth filter after decompression,
    output the following value:
       Paeth(x) + PaethPredictor(Raw(x-bpp), Prior(x), Prior(x-bpp))
    (computed mod 256), where Raw and Prior refer to bytes already
    decoded.  Exactly the same PaethPredictor function is used by both
    encoder and decoder.

7. Chunk Ordering Rules

 To allow new chunk types to be added to PNG, it is necessary to
 establish rules about the ordering requirements for all chunk types.
 Otherwise a PNG editing program cannot know what to do when it
 encounters an unknown chunk.

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

 We define a "PNG editor" as a program that modifies a PNG file and
 wishes to preserve as much as possible of the ancillary information
 in the file.  Two examples of PNG editors are a program that adds or
 modifies text chunks, and a program that adds a suggested palette to
 a truecolor PNG file.  Ordinary image editors are not PNG editors in
 this sense, because they usually discard all unrecognized information
 while reading in an image.  (Note: we strongly encourage programs
 handling PNG files to preserve ancillary information whenever
 possible.)
 As an example of possible problems, consider a hypothetical new
 ancillary chunk type that is safe-to-copy and is required to appear
 after PLTE if PLTE is present.  If our program to add a suggested
 PLTE does not recognize this new chunk, it may insert PLTE in the
 wrong place, namely after the new chunk.  We could prevent such
 problems by requiring PNG editors to discard all unknown chunks, but
 that is a very unattractive solution.  Instead, PNG requires
 ancillary chunks not to have ordering restrictions like this.
 To prevent this type of problem while allowing for future extension,
 we put some constraints on both the behavior of PNG editors and the
 allowed ordering requirements for chunks.
 7.1. Behavior of PNG editors
    The rules for PNG editors are:
  • When copying an unknown unsafe-to-copy ancillary chunk, a

PNG editor must not move the chunk relative to any critical

          chunk.  It can relocate the chunk freely relative to other
          ancillary chunks that occur between the same pair of
          critical chunks.  (This is well defined since the editor
          must not add, delete, modify, or reorder critical chunks if
          it is preserving unknown unsafe-to-copy chunks.)
        * When copying an unknown safe-to-copy ancillary chunk, a PNG
          editor must not move the chunk from before IDAT to after
          IDAT or vice versa.  (This is well defined because IDAT is
          always present.)  Any other reordering is permitted.
        * When copying a known ancillary chunk type, an editor need
          only honor the specific chunk ordering rules that exist for
          that chunk type.  However, it can always choose to apply the
          above general rules instead.
        * PNG editors must give up on encountering an unknown critical
          chunk type, because there is no way to be certain that a
          valid file will result from modifying a file containing such
          a chunk.  (Note that simply discarding the chunk is not good
          enough, because it might have unknown implications for the
          interpretation of other chunks.)

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

    These rules are expressed in terms of copying chunks from an input
    file to an output file, but they apply in the obvious way if a PNG
    file is modified in place.
    See also Chunk naming conventions (Section 3.3).
 7.2. Ordering of ancillary chunks
    The ordering rules for an ancillary chunk type cannot be any
    stricter than this:
  • Unsafe-to-copy chunks can have ordering requirements

relative to critical chunks.

  • Safe-to-copy chunks can have ordering requirements relative

to IDAT.

    The actual ordering rules for any particular ancillary chunk type
    may be weaker.  See for example the ordering rules for the
    standard ancillary chunk types (Summary of standard chunks,
    Section 4.3).
    Decoders must not assume more about the positioning of any
    ancillary chunk than is specified by the chunk ordering rules.  In
    particular, it is never valid to assume that a specific ancillary
    chunk type occurs with any particular positioning relative to
    other ancillary chunks.  (For example, it is unsafe to assume that
    your private ancillary chunk occurs immediately before IEND.  Even
    if your application always writes it there, a PNG editor might
    have inserted some other ancillary chunk after it.  But you can
    safely assume that your chunk will remain somewhere between IDAT
    and IEND.)
 7.3. Ordering of critical chunks
    Critical chunks can have arbitrary ordering requirements, because
    PNG editors are required to give up if they encounter unknown
    critical chunks.  For example, IHDR has the special ordering rule
    that it must always appear first.  A PNG editor, or indeed any
    PNG-writing program, must know and follow the ordering rules for
    any critical chunk type that it can emit.

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

8. Miscellaneous Topics

 8.1. File name extension
    On systems where file names customarily include an extension
    signifying file type, the extension ".png" is recommended for PNG
    files.  Lower case ".png" is preferred if file names are case-
    sensitive.
 8.2. Internet media type
    The Internet Assigned Numbers Authority (IANA) has registered
    "image/png" as the Internet Media Type for PNG [RFC-2045, RFC-
    2048].  For robustness, decoders may choose to also support the
    interim media type "image/x-png" which was in use before
    registration was complete.
 8.3. Macintosh file layout
    In the Apple Macintosh system, the following conventions are
    recommended:
  • The four-byte file type code for PNG files is "PNGf". (This

code has been registered with Apple for PNG files.) The

          creator code will vary depending on the creating
          application.
        * The contents of the data fork must be a PNG file exactly as
          described in the rest of this specification.
        * The contents of the resource fork are unspecified.  It may
          be empty or may contain application-dependent resources.
        * When transferring a Macintosh PNG file to a non-Macintosh
          system, only the data fork should be transferred.
 8.4. Multiple-image extension
    PNG itself is strictly a single-image format.  However, it may be
    necessary to store multiple images within one file; for example,
    this is needed to convert some GIF files.  In the future, a
    multiple-image format based on PNG may be defined.  Such a format
    will be considered a separate file format and will have a
    different signature.  PNG-supporting applications may or may not
    choose to support the multiple-image format.
    See Rationale: Why not these features? (Section 12.3).

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

 8.5. Security considerations
    A PNG file or datastream is composed of a collection of explicitly
    typed "chunks".  Chunks whose contents are defined by the
    specification could actually contain anything, including malicious
    code.  But there is no known risk that such malicious code could
    be executed on the recipient's computer as a result of decoding
    the PNG image.
    The possible security risks associated with future chunk types
    cannot be specified at this time.  Security issues will be
    considered when evaluating chunks proposed for registration as
    public chunks.  There is no additional security risk associated
    with unknown or unimplemented chunk types, because such chunks
    will be ignored, or at most be copied into another PNG file.
    The tEXt and zTXt chunks contain data that is meant to be
    displayed as plain text.  It is possible that if the decoder
    displays such text without filtering out control characters,
    especially the ESC (escape) character, certain systems or
    terminals could behave in undesirable and insecure ways.  We
    recommend that decoders filter out control characters to avoid
    this risk; see Recommendations for Decoders: Text chunk processing
    (Section 10.11).
    Because every chunk's length is available at its beginning, and
    because every chunk has a CRC trailer, there is a very robust
    defense against corrupted data and against fraudulent chunks that
    attempt to overflow the decoder's buffers.  Also, the PNG
    signature bytes provide early detection of common file
    transmission errors.
    A decoder that fails to check CRCs could be subject to data
    corruption.  The only likely consequence of such corruption is
    incorrectly displayed pixels within the image.  Worse things might
    happen if the CRC of the IHDR chunk is not checked and the width
    or height fields are corrupted.  See Recommendations for Decoders:
    Error checking (Section 10.1).
    A poorly written decoder might be subject to buffer overflow,
    because chunks can be extremely large, up to (2^31)-1 bytes long.
    But properly written decoders will handle large chunks without
    difficulty.

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

9. Recommendations for Encoders

 This chapter gives some recommendations for encoder behavior.  The
 only absolute requirement on a PNG encoder is that it produce files
 that conform to the format specified in the preceding chapters.
 However, best results will usually be achieved by following these
 recommendations.
 9.1. Sample depth scaling
    When encoding input samples that have a sample depth that cannot
    be directly represented in PNG, the encoder must scale the samples
    up to a sample depth that is allowed by PNG.  The most accurate
    scaling method is the linear equation
       output = ROUND(input * MAXOUTSAMPLE / MAXINSAMPLE)
    where the input samples range from 0 to MAXINSAMPLE and the
    outputs range from 0 to MAXOUTSAMPLE (which is (2^sampledepth)-1).
    A close approximation to the linear scaling method can be achieved
    by "left bit replication", which is shifting the valid bits to
    begin in the most significant bit and repeating the most
    significant bits into the open bits.  This method is often faster
    to compute than linear scaling.  As an example, assume that 5-bit
    samples are being scaled up to 8 bits.  If the source sample value
    is 27 (in the range from 0-31), then the original bits are:
       4 3 2 1 0
       ---------
       1 1 0 1 1
    Left bit replication gives a value of 222:
       7 6 5 4 3  2 1 0
       ----------------
       1 1 0 1 1  1 1 0
       |=======|  |===|
           |      Leftmost Bits Repeated to Fill Open Bits
           |
       Original Bits
    which matches the value computed by the linear equation.  Left bit
    replication usually gives the same value as linear scaling, and is
    never off by more than one.

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

    A distinctly less accurate approximation is obtained by simply
    left-shifting the input value and filling the low order bits with
    zeroes.  This scheme cannot reproduce white exactly, since it does
    not generate an all-ones maximum value; the net effect is to
    darken the image slightly.  This method is not recommended in
    general, but it does have the effect of improving compression,
    particularly when dealing with greater-than-eight-bit sample
    depths.  Since the relative error introduced by zero-fill scaling
    is small at high sample depths, some encoders may choose to use
    it.  Zero-fill must not be used for alpha channel data, however,
    since many decoders will special-case alpha values of all zeroes
    and all ones.  It is important to represent both those values
    exactly in the scaled data.
    When the encoder writes an sBIT chunk, it is required to do the
    scaling in such a way that the high-order bits of the stored
    samples match the original data.  That is, if the sBIT chunk
    specifies a sample depth of S, the high-order S bits of the stored
    data must agree with the original S-bit data values.  This allows
    decoders to recover the original data by shifting right.  The
    added low-order bits are not constrained.  Note that all the above
    scaling methods meet this restriction.
    When scaling up source data, it is recommended that the low-order
    bits be filled consistently for all samples; that is, the same
    source value should generate the same sample value at any pixel
    position.  This improves compression by reducing the number of
    distinct sample values.  However, this is not a requirement, and
    some encoders may choose not to follow it.  For example, an
    encoder might instead dither the low-order bits, improving
    displayed image quality at the price of increasing file size.
    In some applications the original source data may have a range
    that is not a power of 2.  The linear scaling equation still works
    for this case, although the shifting methods do not.  It is
    recommended that an sBIT chunk not be written for such images,
    since sBIT suggests that the original data range was exactly
    0..2^S-1.
 9.2. Encoder gamma handling
    See Gamma Tutorial (Chapter 13) if you aren't already familiar
    with gamma issues.
    Proper handling of gamma encoding and the gAMA chunk in an encoder
    depends on the prior history of the sample values and on whether
    these values have already been quantized to integers.

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

    If the encoder has access to sample intensity values in floating-
    point or high-precision integer form (perhaps from a computer
    image renderer), then it is recommended that the encoder perform
    its own gamma encoding before quantizing the data to integer
    values for storage in the file.  Applying gamma encoding at this
    stage results in images with fewer banding artifacts at a given
    sample depth, or allows smaller samples while retaining the same
    visual quality.
    A linear intensity level, expressed as a floating-point value in
    the range 0 to 1, can be converted to a gamma-encoded sample value
    by
       sample = ROUND((intensity ^ encoder_gamma) * MAXSAMPLE)
    The file_gamma value to be written in the PNG gAMA chunk is the
    same as encoder_gamma in this equation, since we are assuming the
    initial intensity value is linear (in effect, camera_gamma is
    1.0).
    If the image is being written to a file only, the encoder_gamma
    value can be selected somewhat arbitrarily.  Values of 0.45 or 0.5
    are generally good choices because they are common in video
    systems, and so most PNG decoders should do a good job displaying
    such images.
    Some image renderers may simultaneously write the image to a PNG
    file and display it on-screen.  The displayed pixels should be
    gamma corrected for the display system and viewing conditions in
    use, so that the user sees a proper representation of the intended
    scene.  An appropriate gamma correction value is
       screen_gc = viewing_gamma / display_gamma
    If the renderer wants to write the same gamma-corrected sample
    values to the PNG file, avoiding a separate gamma-encoding step
    for file output, then this screen_gc value should be written in
    the gAMA chunk.  This will allow a PNG decoder to reproduce what
    the file's originator saw on screen during rendering (provided the
    decoder properly supports arbitrary values in a gAMA chunk).
    However, it is equally reasonable for a renderer to apply gamma
    correction for screen display using a gamma appropriate to the
    viewing conditions, and to separately gamma-encode the sample
    values for file storage using a standard value of gamma such as
    0.5.  In fact, this is preferable, since some PNG decoders may not
    accurately display images with unusual gAMA values.

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

    Computer graphics renderers often do not perform gamma encoding,
    instead making sample values directly proportional to scene light
    intensity.  If the PNG encoder receives sample values that have
    already been quantized into linear-light integer values, there is
    no point in doing gamma encoding on them; that would just result
    in further loss of information.  The encoder should just write the
    sample values to the PNG file.  This "linear" sample encoding is
    equivalent to gamma encoding with a gamma of 1.0, so graphics
    programs that produce linear samples should always emit a gAMA
    chunk specifying a gamma of 1.0.
    When the sample values come directly from a piece of hardware, the
    correct gAMA value is determined by the gamma characteristic of
    the hardware.  In the case of video digitizers ("frame grabbers"),
    gAMA should be 0.45 or 0.5 for NTSC (possibly less for PAL or
    SECAM) since video camera transfer functions are standardized.
    Image scanners are less predictable.  Their output samples may be
    linear (gamma 1.0) since CCD sensors themselves are linear, or the
    scanner hardware may have already applied gamma correction
    designed to compensate for dot gain in subsequent printing (gamma
    of about 0.57), or the scanner may have corrected the samples for
    display on a CRT (gamma of 0.4-0.5).  You will need to refer to
    the scanner's manual, or even scan a calibrated gray wedge, to
    determine what a particular scanner does.
    File format converters generally should not attempt to convert
    supplied images to a different gamma.  Store the data in the PNG
    file without conversion, and record the source gamma if it is
    known.  Gamma alteration at file conversion time causes re-
    quantization of the set of intensity levels that are represented,
    introducing further roundoff error with little benefit.  It's
    almost always better to just copy the sample values intact from
    the input to the output file.
    In some cases, the supplied image may be in an image format (e.g.,
    TIFF) that can describe the gamma characteristic of the image.  In
    such cases, a file format converter is strongly encouraged to
    write a PNG gAMA chunk that corresponds to the known gamma of the
    source image.  Note that some file formats specify the gamma of
    the display system, not the camera.  If the input file's gamma
    value is greater than 1.0, it is almost certainly a display system
    gamma, and you should use its reciprocal for the PNG gAMA.

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

    If the encoder or file format converter does not know how an image
    was originally created, but does know that the image has been
    displayed satisfactorily on a display with gamma display_gamma
    under lighting conditions where a particular viewing_gamma is
    appropriate, then the image can be marked as having the
    file_gamma:
       file_gamma = viewing_gamma / display_gamma
    This will allow viewers of the PNG file to see the same image that
    the person running the file format converter saw.  Although this
    may not be precisely the correct value of the image gamma, it's
    better to write a gAMA chunk with an approximately right value
    than to omit the chunk and force PNG decoders to guess at an
    appropriate gamma.
    On the other hand, if the image file is being converted as part of
    a "bulk" conversion, with no one looking at each image, then it is
    better to omit the gAMA chunk entirely.  If the image gamma has to
    be guessed at, leave it to the decoder to do the guessing.
    Gamma does not apply to alpha samples; alpha is always represented
    linearly.
    See also Recommendations for Decoders: Decoder gamma handling
    (Section 10.5).
 9.3. Encoder color handling
    See Color Tutorial (Chapter 14) if you aren't already familiar
    with color issues.
    If it is possible for the encoder to determine the chromaticities
    of the source display primaries, or to make a strong guess based
    on the origin of the image or the hardware running it, then the
    encoder is strongly encouraged to output the cHRM chunk.  If it
    does so, the gAMA chunk should also be written; decoders can do
    little with cHRM if gAMA is missing.

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

    Video created with recent video equipment probably uses the CCIR
    709 primaries and D65 white point [ITU-BT709], which are:
                R           G           B         White
       x      0.640       0.300       0.150       0.3127
       y      0.330       0.600       0.060       0.3290
    An older but still very popular video standard is SMPTE-C [SMPTE-
    170M]:
                R           G           B         White
       x      0.630       0.310       0.155       0.3127
       y      0.340       0.595       0.070       0.3290
    The original NTSC color primaries have not been used in decades.
    Although you may still find the NTSC numbers listed in standards
    documents, you won't find any images that actually use them.
    Scanners that produce PNG files as output should insert the filter
    chromaticities into a cHRM chunk and the camera_gamma into a gAMA
    chunk.
    In the case of hand-drawn or digitally edited images, you have to
    determine what monitor they were viewed on when being produced.
    Many image editing programs allow you to specify what type of
    monitor you are using.  This is often because they are working in
    some device-independent space internally.  Such programs have
    enough information to write valid cHRM and gAMA chunks, and should
    do so automatically.
    If the encoder is compiled as a portion of a computer image
    renderer that performs full-spectral rendering, the monitor values
    that were used to convert from the internal device-independent
    color space to RGB should be written into the cHRM chunk. Any
    colors that are outside the gamut of the chosen RGB device should
    be clipped or otherwise constrained to be within the gamut; PNG
    does not store out of gamut colors.
    If the computer image renderer performs calculations directly in
    device-dependent RGB space, a cHRM chunk should not be written
    unless the scene description and rendering parameters have been
    adjusted to look good on a particular monitor.  In that case, the
    data for that monitor (if known) should be used to construct a
    cHRM chunk.

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

    There are often cases where an image's exact origins are unknown,
    particularly if it began life in some other format.  A few image
    formats store calibration information, which can be used to fill
    in the cHRM chunk.  For example, all PhotoCD images use the CCIR
    709 primaries and D65 whitepoint, so these values can be written
    into the cHRM chunk when converting a PhotoCD file.  PhotoCD also
    uses the SMPTE-170M transfer function, which is closely
    approximated by a gAMA of 0.5.  (PhotoCD can store colors outside
    the RGB gamut, so the image data will require gamut mapping before
    writing to PNG format.)  TIFF 6.0 files can optionally store
    calibration information, which if present should be used to
    construct the cHRM chunk.  GIF and most other formats do not store
    any calibration information.
    It is not recommended that file format converters attempt to
    convert supplied images to a different RGB color space.  Store the
    data in the PNG file without conversion, and record the source
    primary chromaticities if they are known.  Color space
    transformation at file conversion time is a bad idea because of
    gamut mismatches and rounding errors.  As with gamma conversions,
    it's better to store the data losslessly and incur at most one
    conversion when the image is finally displayed.
    See also Recommendations for Decoders: Decoder color handling
    (Section 10.6).
 9.4. Alpha channel creation
    The alpha channel can be regarded either as a mask that
    temporarily hides transparent parts of the image, or as a means
    for constructing a non-rectangular image.  In the first case, the
    color values of fully transparent pixels should be preserved for
    future use.  In the second case, the transparent pixels carry no
    useful data and are simply there to fill out the rectangular image
    area required by PNG.  In this case, fully transparent pixels
    should all be assigned the same color value for best compression.
    Image authors should keep in mind the possibility that a decoder
    will ignore transparency control.  Hence, the colors assigned to
    transparent pixels should be reasonable background colors whenever
    feasible.
    For applications that do not require a full alpha channel, or
    cannot afford the price in compression efficiency, the tRNS
    transparency chunk is also available.

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

    If the image has a known background color, this color should be
    written in the bKGD chunk.  Even decoders that ignore transparency
    may use the bKGD color to fill unused screen area.
    If the original image has premultiplied (also called "associated")
    alpha data, convert it to PNG's non-premultiplied format by
    dividing each sample value by the corresponding alpha value, then
    multiplying by the maximum value for the image bit depth, and
    rounding to the nearest integer.  In valid premultiplied data, the
    sample values never exceed their corresponding alpha values, so
    the result of the division should always be in the range 0 to 1.
    If the alpha value is zero, output black (zeroes).
 9.5. Suggested palettes
    A PLTE chunk can appear in truecolor PNG files.  In such files,
    the chunk is not an essential part of the image data, but simply
    represents a suggested palette that viewers may use to present the
    image on indexed-color display hardware.  A suggested palette is
    of no interest to viewers running on truecolor hardware.
    If an encoder chooses to provide a suggested palette, it is
    recommended that a hIST chunk also be written to indicate the
    relative importance of the palette entries.  The histogram values
    are most easily computed as "nearest neighbor" counts, that is,
    the approximate usage of each palette entry if no dithering is
    applied.  (These counts will often be available for free as a
    consequence of developing the suggested palette.)
    For images of color type 2 (truecolor without alpha channel), it
    is recommended that the palette and histogram be computed with
    reference to the RGB data only, ignoring any transparent-color
    specification.  If the file uses transparency (has a tRNS chunk),
    viewers can easily adapt the resulting palette for use with their
    intended background color.  They need only replace the palette
    entry closest to the tRNS color with their background color (which
    may or may not match the file's bKGD color, if any).
    For images of color type 6 (truecolor with alpha channel), it is
    recommended that a bKGD chunk appear and that the palette and
    histogram be computed with reference to the image as it would
    appear after compositing against the specified background color.
    This definition is necessary to ensure that useful palette entries
    are generated for pixels having fractional alpha values.  The
    resulting palette will probably only be useful to viewers that
    present the image against the same background color.  It is
    recommended that PNG editors delete or recompute the palette if
    they alter or remove the bKGD chunk in an image of color type 6.

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

    If PLTE appears without bKGD in an image of color type 6, the
    circumstances under which the palette was computed are
    unspecified.
 9.6. Filter selection
    For images of color type 3 (indexed color), filter type 0 (None)
    is usually the most effective.  Note that color images with 256 or
    fewer colors should almost always be stored in indexed color
    format; truecolor format is likely to be much larger.
    Filter type 0 is also recommended for images of bit depths less
    than 8.  For low-bit-depth grayscale images, it may be a net win
    to expand the image to 8-bit representation and apply filtering,
    but this is rare.
    For truecolor and grayscale images, any of the five filters may
    prove the most effective.  If an encoder uses a fixed filter, the
    Paeth filter is most likely to be the best.
    For best compression of truecolor and grayscale images, we
    recommend an adaptive filtering approach in which a filter is
    chosen for each scanline.  The following simple heuristic has
    performed well in early tests: compute the output scanline using
    all five filters, and select the filter that gives the smallest
    sum of absolute values of outputs.  (Consider the output bytes as
    signed differences for this test.)  This method usually
    outperforms any single fixed filter choice.  However, it is likely
    that much better heuristics will be found as more experience is
    gained with PNG.
    Filtering according to these recommendations is effective on
    interlaced as well as noninterlaced images.
 9.7. Text chunk processing
    A nonempty keyword must be provided for each text chunk.  The
    generic keyword "Comment" can be used if no better description of
    the text is available.  If a user-supplied keyword is used, be
    sure to check that it meets the restrictions on keywords.
    PNG text strings are expected to use the Latin-1 character set.
    Encoders should avoid storing characters that are not defined in
    Latin-1, and should provide character code remapping if the local
    system's character set is not Latin-1.
    Encoders should discourage the creation of single lines of text
    longer than 79 characters, in order to facilitate easy reading.

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

    It is recommended that text items less than 1K (1024 bytes) in
    size should be output using uncompressed tEXt chunks. In
    particular, it is recommended that the basic title and author
    keywords should always be output using uncompressed tEXt chunks.
    Lengthy disclaimers, on the other hand, are ideal candidates for
    zTXt.
    Placing large tEXt and zTXt chunks after the image data (after
    IDAT) can speed up image display in some situations, since the
    decoder won't have to read over the text to get to the image data.
    But it is recommended that small text chunks, such as the image
    title, appear before IDAT.
 9.8. Use of private chunks
    Applications can use PNG private chunks to carry information that
    need not be understood by other applications.  Such chunks must be
    given names with lowercase second letters, to ensure that they can
    never conflict with any future public chunk definition.  Note,
    however, that there is no guarantee that some other application
    will not use the same private chunk name.  If you use a private
    chunk type, it is prudent to store additional identifying
    information at the beginning of the chunk data.
    Use an ancillary chunk type (lowercase first letter), not a
    critical chunk type, for all private chunks that store information
    that is not absolutely essential to view the image.  Creation of
    private critical chunks is discouraged because they render PNG
    files unportable.  Such chunks should not be used in publicly
    available software or files.  If private critical chunks are
    essential for your application, it is recommended that one appear
    near the start of the file, so that a standard decoder need not
    read very far before discovering that it cannot handle the file.
    If you want others outside your organization to understand a chunk
    type that you invent, contact the maintainers of the PNG
    specification to submit a proposed chunk name and definition for
    addition to the list of special-purpose public chunks (see
    Additional chunk types, Section 4.4).  Note that a proposed public
    chunk name (with uppercase second letter) must not be used in
    publicly available software or files until registration has been
    approved.
    If an ancillary chunk contains textual information that might be
    of interest to a human user, you should not create a special chunk
    type for it.  Instead use a tEXt chunk and define a suitable
    keyword.  That way, the information will be available to users not
    using your software.

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

    Keywords in tEXt chunks should be reasonably self-explanatory,
    since the idea is to let other users figure out what the chunk
    contains.  If of general usefulness, new keywords can be
    registered with the maintainers of the PNG specification.  But it
    is permissible to use keywords without registering them first.
 9.9. Private type and method codes
    This specification defines the meaning of only some of the
    possible values of some fields.  For example, only compression
    method 0 and filter types 0 through 4 are defined.  Numbers
    greater than 127 must be used when inventing experimental or
    private definitions of values for any of these fields.  Numbers
    below 128 are reserved for possible future public extensions of
    this specification.  Note that use of private type codes may
    render a file unreadable by standard decoders.  Such codes are
    strongly discouraged except for experimental purposes, and should
    not appear in publicly available software or files.

10. Recommendations for Decoders

 This chapter gives some recommendations for decoder behavior.  The
 only absolute requirement on a PNG decoder is that it successfully
 read any file conforming to the format specified in the preceding
 chapters.  However, best results will usually be achieved by
 following these recommendations.
 10.1. Error checking
    To ensure early detection of common file-transfer problems,
    decoders should verify that all eight bytes of the PNG file
    signature are correct.  (See Rationale: PNG file signature,
    Section 12.11.) A decoder can have additional confidence in the
    file's integrity if the next eight bytes are an IHDR chunk header
    with the correct chunk length.
    Unknown chunk types must be handled as described in Chunk naming
    conventions (Section 3.3).  An unknown chunk type is not to be
    treated as an error unless it is a critical chunk.
    It is strongly recommended that decoders should verify the CRC on
    each chunk.
    In some situations it is desirable to check chunk headers (length
    and type code) before reading the chunk data and CRC.  The chunk
    type can be checked for plausibility by seeing whether all four
    bytes are ASCII letters (codes 65-90 and 97-122); note that this
    need only be done for unrecognized type codes.  If the total file

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

    size is known (from file system information, HTTP protocol, etc),
    the chunk length can be checked for plausibility as well.
    If CRCs are not checked, dropped/added data bytes or an erroneous
    chunk length can cause the decoder to get out of step and
    misinterpret subsequent data as a chunk header.  Verifying that
    the chunk type contains letters is an inexpensive way of providing
    early error detection in this situation.
    For known-length chunks such as IHDR, decoders should treat an
    unexpected chunk length as an error.  Future extensions to this
    specification will not add new fields to existing chunks; instead,
    new chunk types will be added to carry new information.
    Unexpected values in fields of known chunks (for example, an
    unexpected compression method in the IHDR chunk) must be checked
    for and treated as errors.  However, it is recommended that
    unexpected field values be treated as fatal errors only in
    critical chunks.  An unexpected value in an ancillary chunk can be
    handled by ignoring the whole chunk as though it were an unknown
    chunk type.  (This recommendation assumes that the chunk's CRC has
    been verified.  In decoders that do not check CRCs, it is safer to
    treat any unexpected value as indicating a corrupted file.)
 10.2. Pixel dimensions
    Non-square pixels can be represented (see the pHYs chunk), but
    viewers are not required to account for them; a viewer can present
    any PNG file as though its pixels are square.
    Conversely, viewers running on display hardware with non-square
    pixels are strongly encouraged to rescale images for proper
    display.
 10.3. Truecolor image handling
    To achieve PNG's goal of universal interchangeability, decoders
    are required to accept all types of PNG image: indexed-color,
    truecolor, and grayscale.  Viewers running on indexed-color
    display hardware need to be able to reduce truecolor images to
    indexed format for viewing.  This process is usually called "color
    quantization".

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

    A simple, fast way of doing this is to reduce the image to a fixed
    palette.  Palettes with uniform color spacing ("color cubes") are
    usually used to minimize the per-pixel computation.  For
    photograph-like images, dithering is recommended to avoid ugly
    contours in what should be smooth gradients; however, dithering
    introduces graininess that can be objectionable.
    The quality of rendering can be improved substantially by using a
    palette chosen specifically for the image, since a color cube
    usually has numerous entries that are unused in any particular
    image.  This approach requires more work, first in choosing the
    palette, and second in mapping individual pixels to the closest
    available color.  PNG allows the encoder to supply a suggested
    palette in a PLTE chunk, but not all encoders will do so, and the
    suggested palette may be unsuitable in any case (it may have too
    many or too few colors).  High-quality viewers will therefore need
    to have a palette selection routine at hand.  A large lookup table
    is usually the most feasible way of mapping individual pixels to
    palette entries with adequate speed.
    Numerous implementations of color quantization are available.  The
    PNG reference implementation, libpng, includes code for the
    purpose.
 10.4. Sample depth rescaling
    Decoders may wish to scale PNG data to a lesser sample depth (data
    precision) for display.  For example, 16-bit data will need to be
    reduced to 8-bit depth for use on most present-day display
    hardware.  Reduction of 8-bit data to 5-bit depth is also common.
    The most accurate scaling is achieved by the linear equation
       output = ROUND(input * MAXOUTSAMPLE / MAXINSAMPLE)
    where
       MAXINSAMPLE = (2^sampledepth)-1
       MAXOUTSAMPLE = (2^desired_sampledepth)-1
    A slightly less accurate conversion is achieved by simply shifting
    right by sampledepth-desired_sampledepth places.  For example, to
    reduce 16-bit samples to 8-bit, one need only discard the low-
    order byte.  In many situations the shift method is sufficiently
    accurate for display purposes, and it is certainly much faster.
    (But if gamma correction is being done, sample rescaling can be
    merged into the gamma correction lookup table, as is illustrated
    in Decoder gamma handling, Section 10.5.)

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

    When an sBIT chunk is present, the original pre-PNG data can be
    recovered by shifting right to the sample depth specified by sBIT.
    Note that linear scaling will not necessarily reproduce the
    original data, because the encoder is not required to have used
    linear scaling to scale the data up.  However, the encoder is
    required to have used a method that preserves the high-order bits,
    so shifting always works.  This is the only case in which shifting
    might be said to be more accurate than linear scaling.
    When comparing pixel values to tRNS chunk values to detect
    transparent pixels, it is necessary to do the comparison exactly.
    Therefore, transparent pixel detection must be done before
    reducing sample precision.
 10.5. Decoder gamma handling
    See Gamma Tutorial (Chapter 13) if you aren't already familiar
    with gamma issues.
    To produce correct tone reproduction, a good image display program
    should take into account the gammas of the image file and the
    display device, as well as the viewing_gamma appropriate to the
    lighting conditions near the display.  This can be done by
    calculating
       gbright = insample / MAXINSAMPLE
       bright = gbright ^ (1.0 / file_gamma)
       vbright = bright ^ viewing_gamma
       gcvideo = vbright ^ (1.0 / display_gamma)
       fbval = ROUND(gcvideo * MAXFBVAL)
    where MAXINSAMPLE is the maximum sample value in the file (255 for
    8-bit, 65535 for 16-bit, etc), MAXFBVAL is the maximum value of a
    frame buffer sample (255 for 8-bit, 31 for 5-bit, etc), insample
    is the value of the sample in the PNG file, and fbval is the value
    to write into the frame buffer. The first line converts from
    integer samples into a normalized 0 to 1 floating point value, the
    second undoes the gamma encoding of the image file to produce a
    linear intensity value, the third adjusts for the viewing
    conditions, the fourth corrects for the display system's gamma
    value, and the fifth converts to an integer frame buffer sample.
    In practice, the second through fourth lines can be merged into
       gcvideo = gbright^(viewing_gamma / (file_gamma*display_gamma))
    so as to perform only one power calculation. For color images, the
    entire calculation is performed separately for R, G, and B values.

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

    It is not necessary to perform transcendental math for every
    pixel.  Instead, compute a lookup table that gives the correct
    output value for every possible sample value. This requires only
    256 calculations per image (for 8-bit accuracy), not one or three
    calculations per pixel.  For an indexed-color image, a one-time
    correction of the palette is sufficient, unless the image uses
    transparency and is being displayed against a nonuniform
    background.
    In some cases even the cost of computing a gamma lookup table may
    be a concern.  In these cases, viewers are encouraged to have
    precomputed gamma correction tables for file_gamma values of 1.0
    and 0.5 with some reasonable choice of viewing_gamma and
    display_gamma, and to use the table closest to the gamma indicated
    in the file. This will produce acceptable results for the majority
    of real files.
    When the incoming image has unknown gamma (no gAMA chunk), choose
    a likely default file_gamma value, but allow the user to select a
    new one if the result proves too dark or too light.
    In practice, it is often difficult to determine what value of
    display_gamma should be used. In systems with no built-in gamma
    correction, the display_gamma is determined entirely by the CRT.
    Assuming a CRT_gamma of 2.5 is recommended, unless you have
    detailed calibration measurements of this particular CRT
    available.
    However, many modern frame buffers have lookup tables that are
    used to perform gamma correction, and on these systems the
    display_gamma value should be the gamma of the lookup table and
    CRT combined. You may not be able to find out what the lookup
    table contains from within an image viewer application, so you may
    have to ask the user what the system's gamma value is.
    Unfortunately, different manufacturers use different ways of
    specifying what should go into the lookup table, so interpretation
    of the system gamma value is system-dependent.  Gamma Tutorial
    (Chapter 13) gives some examples.
    The response of real displays is actually more complex than can be
    described by a single number (display_gamma). If actual
    measurements of the monitor's light output as a function of
    voltage input are available, the fourth and fifth lines of the
    computation above can be replaced by a lookup in these
    measurements, to find the actual frame buffer value that most
    nearly gives the desired brightness.

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

    The value of viewing_gamma depends on lighting conditions; see
    Gamma Tutorial (Chapter 13) for more detail.  Ideally, a viewer
    would allow the user to specify viewing_gamma, either directly
    numerically, or via selecting from "bright surround", "dim
    surround", and "dark surround" conditions.  Viewers that don't
    want to do this should just assume a value for viewing_gamma of
    1.0, since most computer displays live in brightly-lit rooms.
    When viewing images that are digitized from video, or that are
    destined to become video frames, the user might want to set the
    viewing_gamma to about 1.25 regardless of the actual level of room
    lighting.  This value of viewing_gamma is "built into" NTSC video
    practice, and displaying an image with that viewing_gamma allows
    the user to see what a TV set would show under the current room
    lighting conditions.  (This is not the same thing as trying to
    obtain the most accurate rendition of the content of the scene,
    which would require adjusting viewing_gamma to correspond to the
    room lighting level.)  This is another reason viewers might want
    to allow users to adjust viewing_gamma directly.
 10.6. Decoder color handling
    See Color Tutorial (Chapter 14) if you aren't already familiar
    with color issues.
    In many cases, decoders will treat image data in PNG files as
    device-dependent RGB data and display it without modification
    (except for appropriate gamma correction). This provides the
    fastest display of PNG images.  But unless the viewer uses exactly
    the same display hardware as the original image author used, the
    colors will not be exactly the same as the original author saw,
    particularly for darker or near-neutral colors.  The cHRM chunk
    provides information that allows closer color matching than that
    provided by gamma correction alone.
    Decoders can use the cHRM data to transform the image data from
    RGB to XYZ and thence into a perceptually linear color space such
    as CIE LAB.  They can then partition the colors to generate an
    optimal palette, because the geometric distance between two colors
    in CIE LAB is strongly related to how different those colors
    appear (unlike, for example, RGB or XYZ spaces).  The resulting
    palette of colors, once transformed back into RGB color space,
    could be used for display or written into a PLTE chunk.
    Decoders that are part of image processing applications might also
    transform image data into CIE LAB space for analysis.

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

    In applications where color fidelity is critical, such as product
    design, scientific visualization, medicine, architecture, or
    advertising, decoders can transform the image data from source_RGB
    to the display_RGB space of the monitor used to view the image.
    This involves calculating the matrix to go from source_RGB to XYZ
    and the matrix to go from XYZ to display_RGB, then combining them
    to produce the overall transformation.  The decoder is responsible
    for implementing gamut mapping.
    Decoders running on platforms that have a Color Management System
    (CMS) can pass the image data, gAMA and cHRM values to the CMS for
    display or further processing.
    Decoders that provide color printing facilities can use the
    facilities in Level 2 PostScript to specify image data in
    calibrated RGB space or in a device-independent color space such
    as XYZ.  This will provide better color fidelity than a simple RGB
    to CMYK conversion.  The PostScript Language Reference manual
    gives examples of this process [POSTSCRIPT].  Such decoders are
    responsible for implementing gamut mapping between source_RGB
    (specified in the cHRM chunk) and the target printer. The
    PostScript interpreter is then responsible for producing the
    required colors.
    Decoders can use the cHRM data to calculate an accurate grayscale
    representation of a color image.  Conversion from RGB to gray is
    simply a case of calculating the Y (luminance) component of XYZ,
    which is a weighted sum of the R G and B values.  The weights
    depend on the monitor type, i.e., the values in the cHRM chunk.
    Decoders may wish to do this for PNG files with no cHRM chunk.  In
    that case, a reasonable default would be the CCIR 709 primaries
    [ITU-BT709].  Do not use the original NTSC primaries, unless you
    really do have an image color-balanced for such a monitor.  Few
    monitors ever used the NTSC primaries, so such images are probably
    nonexistent these days.
 10.7. Background color
    The background color given by bKGD will typically be used to fill
    unused screen space around the image, as well as any transparent
    pixels within the image.  (Thus, bKGD is valid and useful even
    when the image does not use transparency.)  If no bKGD chunk is
    present, the viewer will need to make its own decision about a
    suitable background color.

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

    Viewers that have a specific background against which to present
    the image (such as Web browsers) should ignore the bKGD chunk, in
    effect overriding bKGD with their preferred background color or
    background image.
    The background color given by bKGD is not to be considered
    transparent, even if it happens to match the color given by tRNS
    (or, in the case of an indexed-color image, refers to a palette
    index that is marked as transparent by tRNS).  Otherwise one would
    have to imagine something "behind the background" to composite
    against.  The background color is either used as background or
    ignored; it is not an intermediate layer between the PNG image and
    some other background.
    Indeed, it will be common that bKGD and tRNS specify the same
    color, since then a decoder that does not implement transparency
    processing will give the intended display, at least when no
    partially-transparent pixels are present.
 10.8. Alpha channel processing
    In the most general case, the alpha channel can be used to
    composite a foreground image against a background image; the PNG
    file defines the foreground image and the transparency mask, but
    not the background image.  Decoders are not required to support
    this most general case.  It is expected that most will be able to
    support compositing against a single background color, however.
    The equation for computing a composited sample value is
       output = alpha * foreground + (1-alpha) * background
    where alpha and the input and output sample values are expressed
    as fractions in the range 0 to 1.  This computation should be
    performed with linear (non-gamma-encoded) sample values.  For
    color images, the computation is done separately for R, G, and B
    samples.
    The following code illustrates the general case of compositing a
    foreground image over a background image.  It assumes that you
    have the original pixel data available for the background image,
    and that output is to a frame buffer for display.  Other variants
    are possible; see the comments below the code.  The code allows
    the sample depths and gamma values of foreground image, background
    image, and frame buffer/CRT all to be different.  Don't assume
    they are the same without checking.

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

    This code is standard C, with line numbers added for reference in
    the comments below.
       01  int foreground[4];  /* image pixel: R, G, B, A */
       02  int background[3];  /* background pixel: R, G, B */
       03  int fbpix[3];       /* frame buffer pixel */
       04  int fg_maxsample;   /* foreground max sample */
       05  int bg_maxsample;   /* background max sample */
       06  int fb_maxsample;   /* frame buffer max sample */
       07  int ialpha;
       08  float alpha, compalpha;
       09  float gamfg, linfg, gambg, linbg, comppix, gcvideo;
           /* Get max sample values in data and frame buffer */
       10  fg_maxsample = (1 << fg_sample_depth) - 1;
       11  bg_maxsample = (1 << bg_sample_depth) - 1;
       12  fb_maxsample = (1 << frame_buffer_sample_depth) - 1;
           /*
            * Get integer version of alpha.
            * Check for opaque and transparent special cases;
            * no compositing needed if so.
            *
            * We show the whole gamma decode/correct process in
            * floating point, but it would more likely be done
            * with lookup tables.
            */
       13  ialpha = foreground[3];
       14  if (ialpha == 0) {
               /*
                * Foreground image is transparent here.
                * If the background image is already in the frame
                * buffer, there is nothing to do.
                */
       15      ;
       16  } else if (ialpha == fg_maxsample) {
               /*
                * Copy foreground pixel to frame buffer.
                */
       17      for (i = 0; i < 3; i++) {
       18          gamfg = (float) foreground[i] / fg_maxsample;
       19          linfg = pow(gamfg, 1.0/fg_gamma);
       20          comppix = linfg;
       21          gcvideo = pow(comppix,viewing_gamma/display_gamma);
       22          fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
       23      }

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

       24  } else {
               /*
                * Compositing is necessary.
                * Get floating-point alpha and its complement.
                * Note: alpha is always linear; gamma does not
                * affect it.
                */
       25      alpha = (float) ialpha / fg_maxsample;
       26      compalpha = 1.0 - alpha;
       27      for (i = 0; i < 3; i++) {
                   /*
                    * Convert foreground and background to floating
                    * point, then linearize (undo gamma encoding).
                    */
       28          gamfg = (float) foreground[i] / fg_maxsample;
       29          linfg = pow(gamfg, 1.0/fg_gamma);
       30          gambg = (float) background[i] / bg_maxsample;
       31          linbg = pow(gambg, 1.0/bg_gamma);
                   /*
                    * Composite.
                    */
       32          comppix = linfg * alpha + linbg * compalpha;
                   /*
                    * Gamma correct for display.
                    * Convert to integer frame buffer pixel.
                    */
       33          gcvideo = pow(comppix,viewing_gamma/display_gamma);
       34          fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
       35      }
       36  }
    Variations:
  • If output is to another PNG image file instead of a frame

buffer, lines 21, 22, 33, and 34 should be changed to be

          something like
             /*
              * Gamma encode for storage in output file.
              * Convert to integer sample value.
              */
             gamout = pow(comppix, outfile_gamma);
             outpix[i] = (int) (gamout * out_maxsample + 0.5);
          Also, it becomes necessary to process background pixels when
          alpha is zero, rather than just skipping pixels.  Thus, line
          15 will need to be replaced by copies of lines 17-23, but
          processing background instead of foreground pixel values.

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

  • If the sample depths of the output file, foreground file,

and background file are all the same, and the three gamma

          values also match, then the no-compositing code in lines
          14-23 reduces to nothing more than copying pixel values from
          the input file to the output file if alpha is one, or
          copying pixel values from background to output file if alpha
          is zero.  Since alpha is typically either zero or one for
          the vast majority of pixels in an image, this is a great
          savings.  No gamma computations are needed for most pixels.
        * When the sample depths and gamma values all match, it may
          appear attractive to skip the gamma decoding and encoding
          (lines 28-31, 33-34) and just perform line 32 using gamma-
          encoded sample values. Although this doesn't hurt image
          quality too badly, the time savings are small if alpha
          values of zero and one are special-cased as recommended
          here.
        * If the original pixel values of the background image are no
          longer available, only processed frame buffer pixels left by
          display of the background image, then lines 30 and 31 need
          to extract intensity from the frame buffer pixel values
          using code like
             /*
              * Decode frame buffer value back into linear space.
              */
             gcvideo = (float) fbpix[i] / fb_maxsample;
             linbg = pow(gcvideo, display_gamma / viewing_gamma);
          However, some roundoff error can result, so it is better to
          have the original background pixels available if at all
          possible.
        * Note that lines 18-22 are performing exactly the same gamma
          computation that is done when no alpha channel is present.
          So, if you handle the no-alpha case with a lookup table, you
          can use the same lookup table here.  Lines 28-31 and 33-34
          can also be done with (different) lookup tables.
        * Of course, everything here can be done in integer
          arithmetic.  Just be careful to maintain sufficient
          precision all the way through.
    Note: in floating point, no overflow or underflow checks are
    needed, because the input sample values are guaranteed to be
    between 0 and 1, and compositing always yields a result that is in
    between the input values (inclusive).  With integer arithmetic,
    some roundoff-error analysis might be needed to guarantee no
    overflow or underflow.

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

    When displaying a PNG image with full alpha channel, it is
    important to be able to composite the image against some
    background, even if it's only black.  Ignoring the alpha channel
    will cause PNG images that have been converted from an
    associated-alpha representation to look wrong.  (Of course, if the
    alpha channel is a separate transparency mask, then ignoring alpha
    is a useful option: it allows the hidden parts of the image to be
    recovered.)
    Even if the decoder author does not wish to implement true
    compositing logic, it is simple to deal with images that contain
    only zero and one alpha values.  (This is implicitly true for
    grayscale and truecolor PNG files that use a tRNS chunk; for
    indexed-color PNG files, it is easy to check whether tRNS contains
    any values other than 0 and 255.)  In this simple case,
    transparent pixels are replaced by the background color, while
    others are unchanged.  If a decoder contains only this much
    transparency capability, it should deal with a full alpha channel
    by treating all nonzero alpha values as fully opaque; that is, do
    not replace partially transparent pixels by the background.  This
    approach will not yield very good results for images converted
    from associated-alpha formats, but it's better than doing nothing.
 10.9. Progressive display
    When receiving images over slow transmission links, decoders can
    improve perceived performance by displaying interlaced images
    progressively.  This means that as each pass is received, an
    approximation to the complete image is displayed based on the data
    received so far.  One simple yet pleasing effect can be obtained
    by expanding each received pixel to fill a rectangle covering the
    yet-to-be-transmitted pixel positions below and to the right of
    the received pixel.  This process can be described by the
    following pseudocode:
       Starting_Row [1..7] =  { 0, 0, 4, 0, 2, 0, 1 }
       Starting_Col [1..7] =  { 0, 4, 0, 2, 0, 1, 0 }
       Row_Increment [1..7] = { 8, 8, 8, 4, 4, 2, 2 }
       Col_Increment [1..7] = { 8, 8, 4, 4, 2, 2, 1 }
       Block_Height [1..7] =  { 8, 8, 4, 4, 2, 2, 1 }
       Block_Width [1..7] =   { 8, 4, 4, 2, 2, 1, 1 }
       pass := 1
       while pass <= 7
       begin
           row := Starting_Row[pass]
           while row < height

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

           begin
               col := Starting_Col[pass]
               while col < width
               begin
                   visit (row, col,
                          min (Block_Height[pass], height - row),
                          min (Block_Width[pass], width - col))
                   col := col + Col_Increment[pass]
               end
               row := row + Row_Increment[pass]
           end
           pass := pass + 1
       end
    Here, the function "visit(row,column,height,width)" obtains the
    next transmitted pixel and paints a rectangle of the specified
    height and width, whose upper-left corner is at the specified row
    and column, using the color indicated by the pixel.  Note that row
    and column are measured from 0,0 at the upper left corner.
    If the decoder is merging the received image with a background
    image, it may be more convenient just to paint the received pixel
    positions; that is, the "visit()" function sets only the pixel at
    the specified row and column, not the whole rectangle.  This
    produces a "fade-in" effect as the new image gradually replaces
    the old.  An advantage of this approach is that proper alpha or
    transparency processing can be done as each pixel is replaced.
    Painting a rectangle as described above will overwrite
    background-image pixels that may be needed later, if the pixels
    eventually received for those positions turn out to be wholly or
    partially transparent.  Of course, this is only a problem if the
    background image is not stored anywhere offscreen.
 10.10. Suggested-palette and histogram usage
    In truecolor PNG files, the encoder may have provided a suggested
    PLTE chunk for use by viewers running on indexed-color hardware.
    If the image has a tRNS chunk, the viewer will need to adapt the
    suggested palette for use with its desired background color.  To
    do this, replace the palette entry closest to the tRNS color with
    the desired background color; or just add a palette entry for the
    background color, if the viewer can handle more colors than there
    are PLTE entries.

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

    For images of color type 6 (truecolor with alpha channel), any
    suggested palette should have been designed for display of the
    image against a uniform background of the color specified by bKGD.
    Viewers should probably ignore the palette if they intend to use a
    different background, or if the bKGD chunk is missing.  Viewers
    can use a suggested palette for display against a different
    background than it was intended for, but the results may not be
    very good.
    If the viewer presents a transparent truecolor image against a
    background that is more complex than a single color, it is
    unlikely that the suggested palette will be optimal for the
    composite image.  In this case it is best to perform a truecolor
    compositing step on the truecolor PNG image and background image,
    then color-quantize the resulting image.
    The histogram chunk is useful when the viewer cannot provide as
    many colors as are used in the image's palette.  If the viewer is
    only short a few colors, it is usually adequate to drop the
    least-used colors from the palette.  To reduce the number of
    colors substantially, it's best to choose entirely new
    representative colors, rather than trying to use a subset of the
    existing palette.  This amounts to performing a new color
    quantization step; however, the existing palette and histogram can
    be used as the input data, thus avoiding a scan of the image data.
    If no palette or histogram chunk is provided, a decoder can
    develop its own, at the cost of an extra pass over the image data.
    Alternatively, a default palette (probably a color cube) can be
    used.
    See also Recommendations for Encoders: Suggested palettes (Section
    9.5).
 10.11. Text chunk processing
    If practical, decoders should have a way to display to the user
    all tEXt and zTXt chunks found in the file.  Even if the decoder
    does not recognize a particular text keyword, the user might be
    able to understand it.
    PNG text is not supposed to contain any characters outside the ISO
    8859-1 "Latin-1" character set (that is, no codes 0-31 or 127-
    159), except for the newline character (decimal 10).  But decoders
    might encounter such characters anyway.  Some of these characters
    can be safely displayed (e.g., TAB, FF, and CR, decimal 9, 12, and
    13, respectively), but others, especially the ESC character
    (decimal 27), could pose a security hazard because unexpected

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

    actions may be taken by display hardware or software.  To prevent
    such hazards, decoders should not attempt to directly display any
    non-Latin-1 characters (except for newline and perhaps TAB, FF,
    CR) encountered in a tEXt or zTXt chunk.  Instead, ignore them or
    display them in a visible notation such as "\nnn".  See Security
    considerations (Section 8.5).
    Even though encoders are supposed to represent newlines as LF, it
    is recommended that decoders not rely on this; it's best to
    recognize all the common newline combinations (CR, LF, and CR-LF)
    and display each as a single newline.  TAB can be expanded to the
    proper number of spaces needed to arrive at a column multiple of
    8.
    Decoders running on systems with non-Latin-1 character set
    encoding should provide character code remapping so that Latin-1
    characters are displayed correctly.  Some systems may not provide
    all the characters defined in Latin-1.  Mapping unavailable
    characters to a visible notation such as "\nnn" is a good
    fallback.  In particular, character codes 127-255 should be
    displayed only if they are printable characters on the decoding
    system.  Some systems may interpret such codes as control
    characters; for security, decoders running on such systems should
    not display such characters literally.
    Decoders should be prepared to display text chunks that contain
    any number of printing characters between newline characters, even
    though encoders are encouraged to avoid creating lines in excess
    of 79 characters.

11. Glossary

 a^b
    Exponentiation; a raised to the power b.  C programmers should be
    careful not to misread this notation as exclusive-or.  Note that
    in gamma-related calculations, zero raised to any power is valid
    and must give a zero result.
 Alpha
    A value representing a pixel's degree of transparency.  The more
    transparent a pixel, the less it hides the background against
    which the image is presented.  In PNG, alpha is really the degree
    of opacity: zero alpha represents a completely transparent pixel,
    maximum alpha represents a completely opaque pixel.  But most
    people refer to alpha as providing transparency information, not
    opacity information, and we continue that custom here.

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

 Ancillary chunk
    A chunk that provides additional information.  A decoder can still
    produce a meaningful image, though not necessarily the best
    possible image, without processing the chunk.
 Bit depth
    The number of bits per palette index (in indexed-color PNGs) or
    per sample (in other color types).  This is the same value that
    appears in IHDR.
 Byte
    Eight bits; also called an octet.
 Channel
    The set of all samples of the same kind within an image; for
    example, all the blue samples in a truecolor image.  (The term
    "component" is also used, but not in this specification.)  A
    sample is the intersection of a channel and a pixel.
 Chromaticity
    A pair of values x,y that precisely specify the hue, though not
    the absolute brightness, of a perceived color.
 Chunk
    A section of a PNG file.  Each chunk has a type indicated by its
    chunk type name.  Most types of chunks also include some data.
    The format and meaning of the data within the chunk are determined
    by the type name.
 Composite
    As a verb, to form an image by merging a foreground image and a
    background image, using transparency information to determine
    where the background should be visible.  The foreground image is
    said to be "composited against" the background.
 CRC
    Cyclic Redundancy Check.  A CRC is a type of check value designed
    to catch most transmission errors.  A decoder calculates the CRC
    for the received data and compares it to the CRC that the encoder
    calculated, which is appended to the data.  A mismatch indicates
    that the data was corrupted in transit.
 Critical chunk
    A chunk that must be understood and processed by the decoder in
    order to produce a meaningful image from a PNG file.
 CRT
    Cathode Ray Tube: a common type of computer display hardware.

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

 Datastream
    A sequence of bytes.  This term is used rather than "file" to
    describe a byte sequence that is only a portion of a file.  We
    also use it to emphasize that a PNG image might be generated and
    consumed "on the fly", never appearing in a stored file at all.
 Deflate
    The name of the compression algorithm used in standard PNG files,
    as well as in zip, gzip, pkzip, and other compression programs.
    Deflate is a member of the LZ77 family of compression methods.
 Filter
    A transformation applied to image data in hopes of improving its
    compressibility.  PNG uses only lossless (reversible) filter
    algorithms.
 Frame buffer
    The final digital storage area for the image shown by a computer
    display.  Software causes an image to appear onscreen by loading
    it into the frame buffer.
 Gamma
    The brightness of mid-level tones in an image.  More precisely, a
    parameter that describes the shape of the transfer function for
    one or more stages in an imaging pipeline.  The transfer function
    is given by the expression
       output = input ^ gamma
    where both input and output are scaled to the range 0 to 1.
 Grayscale
    An image representation in which each pixel is represented by a
    single sample value representing overall luminance (on a scale
    from black to white).  PNG also permits an alpha sample to be
    stored for each pixel of a grayscale image.
 Indexed color
    An image representation in which each pixel is represented by a
    single sample that is an index into a palette or lookup table.
    The selected palette entry defines the actual color of the pixel.
 Lossless compression
    Any method of data compression that guarantees the original data
    can be reconstructed exactly, bit-for-bit.

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

 Lossy compression
    Any method of data compression that reconstructs the original data
    approximately, rather than exactly.
 LSB
    Least Significant Byte of a multi-byte value.
 Luminance
    Perceived brightness, or grayscale level, of a color.  Luminance
    and chromaticity together fully define a perceived color.
 LUT
    Look Up Table.  In general, a table used to transform data.  In
    frame buffer hardware, a LUT can be used to map indexed-color
    pixels into a selected set of truecolor values, or to perform
    gamma correction.  In software, a LUT can be used as a fast way of
    implementing any one-variable mathematical function.
 MSB
    Most Significant Byte of a multi-byte value.
 Palette
    The set of colors available in an indexed-color image.  In PNG, a
    palette is an array of colors defined by red, green, and blue
    samples.  (Alpha values can also be defined for palette entries,
    via the tRNS chunk.)
 Pixel
    The information stored for a single grid point in the image.  The
    complete image is a rectangular array of pixels.
 PNG editor
    A program that modifies a PNG file and preserves ancillary
    information, including chunks that it does not recognize.  Such a
    program must obey the rules given in Chunk Ordering Rules (Chapter
    7).
 Sample
    A single number in the image data; for example, the red value of a
    pixel.  A pixel is composed of one or more samples.  When
    discussing physical data layout (in particular, in Image layout,
    Section 2.3), we use "sample" to mean a number stored in the image
    array.  It would be more precise but much less readable to say
    "sample or palette index" in that context.  Elsewhere in the
    specification, "sample" means a color value or alpha value.  In
    the indexed-color case, these are palette entries not palette
    indexes.

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

 Sample depth
    The precision, in bits, of color values and alpha values.  In
    indexed-color PNGs the sample depth is always 8 by definition of
    the PLTE chunk.  In other color types it is the same as the bit
    depth.
 Scanline
    One horizontal row of pixels within an image.
 Truecolor
    An image representation in which pixel colors are defined by
    storing three samples for each pixel, representing red, green, and
    blue intensities respectively.  PNG also permits an alpha sample
    to be stored for each pixel of a truecolor image.
 White point
    The chromaticity of a computer display's nominal white value.
 zlib
    A particular format for data that has been compressed using
    deflate-style compression.  Also the name of a library
    implementing this method.  PNG implementations need not use the
    zlib library, but they must conform to its format for compressed
    data.

12. Appendix: Rationale

 (This appendix is not part of the formal PNG specification.)
 This appendix gives the reasoning behind some of the design decisions
 in PNG.  Many of these decisions were the subject of considerable
 debate.  The authors freely admit that another group might have made
 different decisions; however, we believe that our choices are
 defensible and consistent.
 12.1. Why a new file format?
    Does the world really need yet another graphics format?  We
    believe so.  GIF is no longer freely usable, but no other commonly
    used format can directly replace it, as is discussed in more
    detail below.  We might have used an adaptation of an existing
    format, for example GIF with an unpatented compression scheme.
    But this would require new code anyway; it would not be all that
    much easier to implement than a whole new file format.  (PNG is
    designed to be simple to implement, with the exception of the
    compression engine, which would be needed in any case.)  We feel
    that this is an excellent opportunity to design a new format that
    fixes some of the known limitations of GIF.

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

 12.2. Why these features?
    The features chosen for PNG are intended to address the needs of
    applications that previously used the special strengths of GIF.
    In particular, GIF is well adapted for online communications
    because of its streamability and progressive display capability.
    PNG shares those attributes.
    We have also addressed some of the widely known shortcomings of
    GIF.  In particular, PNG supports truecolor images.  We know of no
    widely used image format that losslessly compresses truecolor
    images as effectively as PNG does.  We hope that PNG will make use
    of truecolor images more practical and widespread.
    Some form of transparency control is desirable for applications in
    which images are displayed against a background or together with
    other images.  GIF provided a simple transparent-color
    specification for this purpose.  PNG supports a full alpha channel
    as well as transparent-color specifications.  This allows both
    highly flexible transparency and compression efficiency.
    Robustness against transmission errors has been an important
    consideration.  For example, images transferred across Internet
    are often mistakenly processed as text, leading to file
    corruption.  PNG is designed so that such errors can be detected
    quickly and reliably.
    PNG has been expressly designed not to be completely dependent on
    a single compression technique. Although deflate/inflate
    compression is mentioned in this document, PNG would still exist
    without it.
 12.3. Why not these features?
    Some features have been deliberately omitted from PNG.  These
    choices were made to simplify implementation of PNG, promote
    portability and interchangeability, and make the format as simple
    and foolproof as possible for users.  In particular:

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

  • There is no uncompressed variant of PNG. It is possible to

store uncompressed data by using only uncompressed deflate

          blocks (a feature normally used to guarantee that deflate
          does not make incompressible data much larger).  However,
          PNG software must support full deflate/inflate; any software
          that does not is not compliant with the PNG standard. The
          two most important features of PNG---portability and
          compression---are absolute requirements for online
          applications, and users demand them. Failure to support full
          deflate/inflate compromises both of these objectives.
        * There is no lossy compression in PNG.  Existing formats such
          as JFIF already handle lossy compression well.  Furthermore,
          available lossy compression methods (e.g., JPEG) are far
          from foolproof --- a poor choice of quality level can ruin
          an image.  To avoid user confusion and unintentional loss of
          information, we feel it is best to keep lossy and lossless
          formats strictly separate.  Also, lossy compression is
          complex to implement.  Adding JPEG support to a PNG decoder
          might increase its size by an order of magnitude.  This
          would certainly cause some decoders to omit support for the
          feature, which would destroy our goal of interchangeability.
        * There is no support for CMYK or other unusual color spaces.
          Again, this is in the name of promoting portability.  CMYK,
          in particular, is far too device-dependent to be useful as a
          portable image representation.
        * There is no standard chunk for thumbnail views of images.
          In discussions with software vendors who use thumbnails in
          their products, it has become clear that most would not use
          a "standard" thumbnail chunk.  For one thing, every vendor
          has a different idea of what the dimensions and
          characteristics of a thumbnail ought to be.  Also, some
          vendors keep thumbnails in separate files to accommodate
          varied image formats; they are not going to stop doing that
          simply because of a thumbnail chunk in one new format.
          Proprietary chunks containing vendor-specific thumbnails
          appear to be more practical than a common thumbnail format.
    It is worth noting that private extensions to PNG could easily add
    these features.  We will not, however, include them as part of the
    basic PNG standard.

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

    PNG also does not support multiple images in one file.  This
    restriction is a reflection of the reality that many applications
    do not need and will not support multiple images per file.  In any
    case, single images are a fundamentally different sort of object
    from sequences of images.  Rather than make false promises of
    interchangeability, we have drawn a clear distinction between
    single-image and multi-image formats.  PNG is a single-image
    format.  (But see Multiple-image extension, Section 8.4.)
 12.4. Why not use format X?
    Numerous existing formats were considered before deciding to
    develop PNG.  None could meet the requirements we felt were
    important for PNG.
    GIF is no longer suitable as a universal standard because of legal
    entanglements.  Although just replacing GIF's compression method
    would avoid that problem, GIF does not support truecolor images,
    alpha channels, or gamma correction.  The spec has more subtle
    problems too.  Only a small subset of the GIF89 spec is actually
    portable across a variety of implementations, but there is no
    codification of the most portable part of the spec.
    TIFF is far too complex to meet our goals of simplicity and
    interchangeability.  Defining a TIFF subset would meet that
    objection, but would frustrate users making the reasonable
    assumption that a file saved as TIFF from their existing software
    would load into a program supporting our flavor of TIFF.
    Furthermore, TIFF is not designed for stream processing, has no
    provision for progressive display, and does not currently provide
    any good, legally unencumbered, lossless compression method.
    IFF has also been suggested, but is not suitable in detail:
    available image representations are too machine-specific or not
    adequately compressed.  The overall chunk structure of IFF is a
    useful concept that PNG has liberally borrowed from, but we did
    not attempt to be bit-for-bit compatible with IFF chunk structure.
    Again this is due to detailed issues, notably the fact that IFF
    FORMs are not designed to be serially writable.
    Lossless JPEG is not suitable because it does not provide for the
    storage of indexed-color images.  Furthermore, its lossless
    truecolor compression is often inferior to that of PNG.

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

 12.5. Byte order
    It has been asked why PNG uses network byte order.  We have
    selected one byte ordering and used it consistently. Which order
    in particular is of little relevance, but network byte order has
    the advantage that routines to convert to and from it are already
    available on any platform that supports TCP/IP networking,
    including all PC platforms.  The functions are trivial and will be
    included in the reference implementation.
 12.6. Interlacing
    PNG's two-dimensional interlacing scheme is more complex to
    implement than GIF's line-wise interlacing.  It also costs a
    little more in file size.  However, it yields an initial image
    eight times faster than GIF (the first pass transmits only 1/64th
    of the pixels, compared to 1/8th for GIF).  Although this initial
    image is coarse, it is useful in many situations.  For example, if
    the image is a World Wide Web imagemap that the user has seen
    before, PNG's first pass is often enough to determine where to
    click.  The PNG scheme also looks better than GIF's, because
    horizontal and vertical resolution never differ by more than a
    factor of two; this avoids the odd "stretched" look seen when
    interlaced GIFs are filled in by replicating scanlines.
    Preliminary results show that small text in an interlaced PNG
    image is typically readable about twice as fast as in an
    equivalent GIF, i.e., after PNG's fifth pass or 25% of the image
    data, instead of after GIF's third pass or 50%.  This is again due
    to PNG's more balanced increase in resolution.
 12.7. Why gamma?
    It might seem natural to standardize on storing sample values that
    are linearly proportional to light intensity (that is, have gamma
    of 1.0).  But in fact, it is common for images to have a gamma of
    less than 1.  There are three good reasons for this:
  • For reasons detailed in Gamma Tutorial (Chapter 13), all

video cameras apply a "gamma correction" function to the

          intensity information.  This causes the video signal to have
          a gamma of about 0.5 relative to the light intensity in the
          original scene.  Thus, images obtained by frame-grabbing
          video already have a gamma of about 0.5.
        * The human eye has a nonlinear response to intensity, so
          linear encoding of samples either wastes sample codes in
          bright areas of the image, or provides too few sample codes
          to avoid banding artifacts in dark areas of the image, or
          both.  At least 12 bits per sample are needed to avoid

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

          visible artifacts in linear encoding with a 100:1 image
          intensity range.  An image gamma in the range 0.3 to 0.5
          allocates sample values in a way that roughly corresponds to
          the eye's response, so that 8 bits/sample are enough to
          avoid artifacts caused by insufficient sample precision in
          almost all images.  This makes "gamma encoding" a much
          better way of storing digital images than the simpler linear
          encoding.
        * Many images are created on PCs or workstations with no gamma
          correction hardware and no software willing to provide gamma
          correction either.  In these cases, the images have had
          their lighting and color chosen to look best on this
          platform --- they can be thought of as having "manual" gamma
          correction built in.  To see what the image author intended,
          it is necessary to treat such images as having a file_gamma
          value in the range 0.4-0.6, depending on the room lighting
          level that the author was working in.
    In practice, image gamma values around 1.0 and around 0.5 are both
    widely found.  Older image standards such as GIF often do not
    account for this fact.  The JFIF standard specifies that images in
    that format should use linear samples, but many JFIF images found
    on the Internet actually have a gamma somewhere near 0.4 or 0.5.
    The variety of images found and the variety of systems that people
    display them on have led to widespread problems with images
    appearing "too dark" or "too light".
    PNG expects viewers to compensate for image gamma at the time that
    the image is displayed. Another possible approach is to expect
    encoders to convert all images to a uniform gamma at encoding
    time. While that method would speed viewers slightly, it has
    fundamental flaws:
  • Gamma correction is inherently lossy due to quantization and

roundoff error. Requiring conversion at encoding time thus

          causes irreversible loss. Since PNG is intended to be a
          lossless storage format, this is undesirable; we should
          store unmodified source data.
        * The encoder might not know the source gamma value. If the
          decoder does gamma correction at viewing time, it can adjust
          the gamma (change the displayed brightness) in response to
          feedback from a human user. The encoder has no such
          recourse.
        * Whatever "standard" gamma we settled on would be wrong for
          some displays. Hence viewers would still need gamma
          correction capability.

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

    Since there will always be images with no gamma or an incorrect
    recorded gamma, good viewers will need to incorporate gamma
    adjustment code anyway. Gamma correction at viewing time is thus
    the right way to go.
    See Gamma Tutorial (Chapter 13) for more information.
 12.8. Non-premultiplied alpha
    PNG uses "unassociated" or "non-premultiplied" alpha so that
    images with separate transparency masks can be stored losslessly.
    Another common technique, "premultiplied alpha", stores pixel
    values premultiplied by the alpha fraction; in effect, the image
    is already composited against a black background.  Any image data
    hidden by the transparency mask is irretrievably lost by that
    method, since multiplying by a zero alpha value always produces
    zero.
    Some image rendering techniques generate images with premultiplied
    alpha (the alpha value actually represents how much of the pixel
    is covered by the image).  This representation can be converted to
    PNG by dividing the sample values by alpha, except where alpha is
    zero.  The result will look good if displayed by a viewer that
    handles alpha properly, but will not look very good if the viewer
    ignores the alpha channel.
    Although each form of alpha storage has its advantages, we did not
    want to require all PNG viewers to handle both forms.  We
    standardized on non-premultiplied alpha as being the lossless and
    more general case.
 12.9. Filtering
    PNG includes filtering capability because filtering can
    significantly reduce the compressed size of truecolor and
    grayscale images.  Filtering is also sometimes of value on
    indexed-color images, although this is less common.
    The filter algorithms are defined to operate on bytes, rather than
    pixels; this gains simplicity and speed with very little cost in
    compression performance.  Tests have shown that filtering is
    usually ineffective for images with fewer than 8 bits per sample,
    so providing pixelwise filtering for such images would be
    pointless.  For 16 bit/sample data, bytewise filtering is nearly
    as effective as pixelwise filtering, because MSBs are predicted
    from adjacent MSBs, and LSBs are predicted from adjacent LSBs.

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

    The encoder is allowed to change filters for each new scanline.
    This creates no additional complexity for decoders, since a
    decoder is required to contain defiltering logic for every filter
    type anyway.  The only cost is an extra byte per scanline in the
    pre-compression datastream.  Our tests showed that when the same
    filter is selected for all scanlines, this extra byte compresses
    away to almost nothing, so there is little storage cost compared
    to a fixed filter specified for the whole image.  And the
    potential benefits of adaptive filtering are too great to ignore.
    Even with the simplistic filter-choice heuristics so far
    discovered, adaptive filtering usually outperforms fixed filters.
    In particular, an adaptive filter can change behavior for
    successive passes of an interlaced image; a fixed filter cannot.
 12.10. Text strings
    Most graphics file formats include the ability to store some
    textual information along with the image.  But many applications
    need more than that: they want to be able to store several
    identifiable pieces of text.  For example, a database using PNG
    files to store medical X-rays would likely want to include
    patient's name, doctor's name, etc.  A simple way to do this in
    PNG would be to invent new private chunks holding text.  The
    disadvantage of such an approach is that other applications would
    have no idea what was in those chunks, and would simply ignore
    them.  Instead, we recommend that textual information be stored in
    standard tEXt chunks with suitable keywords.  Use of tEXt tells
    any PNG viewer that the chunk contains text that might be of
    interest to a human user.  Thus, a person looking at the file with
    another viewer will still be able to see the text, and even
    understand what it is if the keywords are reasonably self-
    explanatory.  (To this end, we recommend spelled-out keywords, not
    abbreviations that will be hard for a person to understand.
    Saving a few bytes on a keyword is false economy.)
    The ISO 8859-1 (Latin-1) character set was chosen as a compromise
    between functionality and portability.  Some platforms cannot
    display anything more than 7-bit ASCII characters, while others
    can handle characters beyond the Latin-1 set.  We felt that
    Latin-1 represents a widely useful and reasonably portable
    character set.  Latin-1 is a direct subset of character sets
    commonly used on popular platforms such as Microsoft Windows and X
    Windows.  It can also be handled on Macintosh systems with a
    simple remapping of characters.
    There is presently no provision for text employing character sets
    other than Latin-1. We recognize that the need for other character
    sets will increase.  However, PNG already requires that

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

    programmers implement a number of new and unfamiliar features, and
    text representation is not PNG's primary purpose. Since PNG
    provides for the creation and public registration of new ancillary
    chunks of general interest, we expect that text chunks for other
    character sets, such as Unicode, eventually will be registered and
    increase gradually in popularity.
 12.11. PNG file signature
    The first eight bytes of a PNG file always contain the following
    values:
       (decimal)              137  80  78  71  13  10  26  10
       (hexadecimal)           89  50  4e  47  0d  0a  1a  0a
       (ASCII C notation)    \211   P   N   G  \r  \n \032 \n
    This signature both identifies the file as a PNG file and provides
    for immediate detection of common file-transfer problems.  The
    first two bytes distinguish PNG files on systems that expect the
    first two bytes to identify the file type uniquely.  The first
    byte is chosen as a non-ASCII value to reduce the probability that
    a text file may be misrecognized as a PNG file; also, it catches
    bad file transfers that clear bit 7.  Bytes two through four name
    the format.  The CR-LF sequence catches bad file transfers that
    alter newline sequences.  The control-Z character stops file
    display under MS-DOS.  The final line feed checks for the inverse
    of the CR-LF translation problem.
    A decoder may further verify that the next eight bytes contain an
    IHDR chunk header with the correct chunk length; this will catch
    bad transfers that drop or alter null (zero) bytes.
    Note that there is no version number in the signature, nor indeed
    anywhere in the file.  This is intentional: the chunk mechanism
    provides a better, more flexible way to handle format extensions,
    as explained in Chunk naming conventions (Section 12.13).
 12.12. Chunk layout
    The chunk design allows decoders to skip unrecognized or
    uninteresting chunks: it is simply necessary to skip the
    appropriate number of bytes, as determined from the length field.
    Limiting chunk length to (2^31)-1 bytes avoids possible problems
    for implementations that cannot conveniently handle 4-byte
    unsigned values.  In practice, chunks will usually be much shorter
    than that anyway.

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

    A separate CRC is provided for each chunk in order to detect
    badly-transferred images as quickly as possible.  In particular,
    critical data such as the image dimensions can be validated before
    being used.
    The chunk length is excluded from the CRC so that the CRC can be
    calculated as the data is generated; this avoids a second pass
    over the data in cases where the chunk length is not known in
    advance.  Excluding the length from the CRC does not create any
    extra risk of failing to discover file corruption, since if the
    length is wrong, the CRC check will fail: the CRC will be computed
    on the wrong set of bytes and then be tested against the wrong
    value from the file.
 12.13. Chunk naming conventions
    The chunk naming conventions allow safe, flexible extension of the
    PNG format.  This mechanism is much better than a format version
    number, because it works on a feature-by-feature basis rather than
    being an overall indicator.  Decoders can process newer files if
    and only if the files use no unknown critical features (as
    indicated by finding unknown critical chunks).  Unknown ancillary
    chunks can be safely ignored.  We decided against having an
    overall format version number because experience has shown that
    format version numbers hurt portability as much as they help.
    Version numbers tend to be set unnecessarily high, leading to
    older decoders rejecting files that they could have processed
    (this was a serious problem for several years after the GIF89 spec
    came out, for example).  Furthermore, private extensions can be
    made either critical or ancillary, and standard decoders should
    react appropriately; overall version numbers are no help for
    private extensions.
    A hypothetical chunk for vector graphics would be a critical
    chunk, since if ignored, important parts of the intended image
    would be missing.  A chunk carrying the Mandelbrot set coordinates
    for a fractal image would be ancillary, since other applications
    could display the image without understanding what the image
    represents.  In general, a chunk type should be made critical only
    if it is impossible to display a reasonable representation of the
    intended image without interpreting that chunk.

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

    The public/private property bit ensures that any newly defined
    public chunk type name cannot conflict with proprietary chunks
    that could be in use somewhere.  However, this does not protect
    users of private chunk names from the possibility that someone
    else may use the same chunk name for a different purpose.  It is a
    good idea to put additional identifying information at the start
    of the data for any private chunk type.
    When a PNG file is modified, certain ancillary chunks may need to
    be changed to reflect changes in other chunks. For example, a
    histogram chunk needs to be changed if the image data changes.  If
    the file editor does not recognize histogram chunks, copying them
    blindly to a new output file is incorrect; such chunks should be
    dropped.  The safe/unsafe property bit allows ancillary chunks to
    be marked appropriately.
    Not all possible modification scenarios are covered by the
    safe/unsafe semantics.  In particular, chunks that are dependent
    on the total file contents are not supported.  (An example of such
    a chunk is an index of IDAT chunk locations within the file:
    adding a comment chunk would inadvertently break the index.)
    Definition of such chunks is discouraged.  If absolutely necessary
    for a particular application, such chunks can be made critical
    chunks, with consequent loss of portability to other applications.
    In general, ancillary chunks can depend on critical chunks but not
    on other ancillary chunks.  It is expected that mutually dependent
    information should be put into a single chunk.
    In some situations it may be unavoidable to make one ancillary
    chunk dependent on another.  Although the chunk property bits are
    insufficient to represent this case, a simple solution is
    available: in the dependent chunk, record the CRC of the chunk
    depended on.  It can then be determined whether that chunk has
    been changed by some other program.
    The same technique can be useful for other purposes.  For example,
    if a program relies on the palette being in a particular order, it
    can store a private chunk containing the CRC of the PLTE chunk.
    If this value matches when the file is again read in, then it
    provides high confidence that the palette has not been tampered
    with.  Note that it is not necessary to mark the private chunk
    unsafe-to-copy when this technique is used; thus, such a private
    chunk can survive other editing of the file.

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

 12.14. Palette histograms
    A viewer may not be able to provide as many colors as are listed
    in the image's palette.  (For example, some colors could be
    reserved by a window system.)  To produce the best results in this
    situation, it is helpful to have information about the frequency
    with which each palette index actually appears, in order to choose
    the best palette for dithering or to drop the least-used colors.
    Since images are often created once and viewed many times, it
    makes sense to calculate this information in the encoder, although
    it is not mandatory for the encoder to provide it.
    Other image formats have usually addressed this problem by
    specifying that the palette entries should appear in order of
    frequency of use.  That is an inferior solution, because it
    doesn't give the viewer nearly as much information: the viewer
    can't determine how much damage will be done by dropping the last
    few colors.  Nor does a sorted palette give enough information to
    choose a target palette for dithering, in the case that the viewer
    needs to reduce the number of colors substantially.  A palette
    histogram provides the information needed to choose such a target
    palette without making a pass over the image data.

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

13. Appendix: Gamma Tutorial

 (This appendix is not part of the formal PNG specification.)
 It would be convenient for graphics programmers if all of the
 components of an imaging system were linear.  The voltage coming from
 an electronic camera would be directly proportional to the intensity
 (power) of light in the scene, the light emitted by a CRT would be
 directly proportional to its input voltage, and so on.  However,
 real-world devices do not behave in this way.  All CRT displays,
 almost all photographic film, and many electronic cameras have
 nonlinear signal-to-light-intensity or intensity-to-signal
 characteristics.
 Fortunately, all of these nonlinear devices have a transfer function
 that is approximated fairly well by a single type of mathematical
 function: a power function.  This power function has the general
 equation
    output = input ^ gamma
 where ^ denotes exponentiation, and "gamma" (often printed using the
 Greek letter gamma, thus the name) is simply the exponent of the
 power function.
 By convention, "input" and "output" are both scaled to the range
 0..1, with 0 representing black and 1 representing maximum white (or
 red, etc).  Normalized in this way, the power function is completely
 described by a single number, the exponent "gamma".
 So, given a particular device, we can measure its output as a
 function of its input, fit a power function to this measured transfer
 function, extract the exponent, and call it gamma.  We often say
 "this device has a gamma of 2.5" as a shorthand for "this device has
 a power-law response with an exponent of 2.5".  We can also talk
 about the gamma of a mathematical transform, or of a lookup table in
 a frame buffer, so long as the input and output of the thing are
 related by the power-law expression above.
 How do gammas combine?
    Real imaging systems will have several components, and more than
    one of these can be nonlinear.  If all of the components have
    transfer characteristics that are power functions, then the
    transfer function of the entire system is also a power function.
    The exponent (gamma) of the whole system's transfer function is
    just the product of all of the individual exponents (gammas) of
    the separate stages in the system.

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

    Also, stages that are linear pose no problem, since a power
    function with an exponent of 1.0 is really a linear function.  So
    a linear transfer function is just a special case of a power
    function, with a gamma of 1.0.
    Thus, as long as our imaging system contains only stages with
    linear and power-law transfer functions, we can meaningfully talk
    about the gamma of the entire system.  This is indeed the case
    with most real imaging systems.
 What should overall gamma be?
    If the overall gamma of an imaging system is 1.0, its output is
    linearly proportional to its input.  This means that the ratio
    between the intensities of any two areas in the reproduced image
    will be the same as it was in the original scene.  It might seem
    that this should always be the goal of an imaging system: to
    accurately reproduce the tones of the original scene.  Alas, that
    is not the case.
    When the reproduced image is to be viewed in "bright surround"
    conditions, where other white objects nearby in the room have
    about the same brightness as white in the image, then an overall
    gamma of 1.0 does indeed give real-looking reproduction of a
    natural scene.  Photographic prints viewed under room light and
    computer displays in bright room light are typical "bright
    surround" viewing conditions.
    However, sometimes images are intended to be viewed in "dark
    surround" conditions, where the room is substantially black except
    for the image.  This is typical of the way movies and slides
    (transparencies) are viewed by projection.  Under these
    circumstances, an accurate reproduction of the original scene
    results in an image that human viewers judge as "flat" and lacking
    in contrast.  It turns out that the projected image needs to have
    a gamma of about 1.5 relative to the original scene for viewers to
    judge it "natural".  Thus, slide film is designed to have a gamma
    of about 1.5, not 1.0.
    There is also an intermediate condition called "dim surround",
    where the rest of the room is still visible to the viewer, but is
    noticeably darker than the reproduced image itself.  This is
    typical of television viewing, at least in the evening, as well as
    subdued-light computer work areas.  In dim surround conditions,
    the reproduced image needs to have a gamma of about 1.25 relative
    to the original scene in order to look natural.

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

    The requirement for boosted contrast (gamma) in dark surround
    conditions is due to the way the human visual system works, and
    applies equally well to computer monitors.  Thus, a PNG viewer
    trying to achieve the maximum realism for the images it displays
    really needs to know what the room lighting conditions are, and
    adjust the gamma of the displayed image accordingly.
    If asking the user about room lighting conditions is inappropriate
    or too difficult, just assume that the overall gamma
    (viewing_gamma as defined below) should be 1.0 or 1.25.  That's
    all that most systems that implement gamma correction do.
 What is a CRT's gamma?
    All CRT displays have a power-law transfer characteristic with a
    gamma of about 2.5.  This is due to the physical processes
    involved in controlling the electron beam in the electron gun, and
    has nothing to do with the phosphor.
    An exception to this rule is fancy "calibrated" CRTs that have
    internal electronics to alter their transfer function.  If you
    have one of these, you probably should believe what the
    manufacturer tells you its gamma is.  But in all other cases,
    assuming 2.5 is likely to be pretty accurate.
    There are various images around that purport to measure gamma,
    usually by comparing the intensity of an area containing
    alternating white and black with a series of areas of continuous
    gray of different intensity.  These are usually not reliable.
    Test images that use a "checkerboard" pattern of black and white
    are the worst, because a single white pixel will be reproduced
    considerably darker than a large area of white.  An image that
    uses alternating black and white horizontal lines (such as the
    "gamma.png" test image at
    ftp://ftp.uu.net/graphics/png/images/suite/gamma.png) is much
    better, but even it may be inaccurate at high "picture" settings
    on some CRTs.
    If you have a good photometer, you can measure the actual light
    output of a CRT as a function of input voltage and fit a power
    function to the measurements.  However, note that this procedure
    is very sensitive to the CRT's black level adjustment, somewhat
    sensitive to its picture adjustment, and also affected by ambient
    light.  Furthermore, CRTs spread some light from bright areas of
    an image into nearby darker areas; a single bright spot against a
    black background may be seen to have a "halo".  Your measuring
    technique will need to minimize the effects of this.

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

    Because of the difficulty of measuring gamma, using either test
    images or measuring equipment, you're usually better off just
    assuming gamma is 2.5 rather than trying to measure it.
 What is gamma correction?
    A CRT has a gamma of 2.5, and we can't change that.  To get an
    overall gamma of 1.0 (or somewhere near that) for an imaging
    system, we need to have at least one other component of the "image
    pipeline" that is nonlinear.  If, in fact, there is only one
    nonlinear stage in addition to the CRT, then it's traditional to
    say that the CRT has a certain gamma, and that the other nonlinear
    stage provides "gamma correction" to compensate for the CRT.
    However, exactly where the "correction" is done depends on
    circumstance.
    In all broadcast video systems, gamma correction is done in the
    camera.  This choice was made in the days when television
    electronics were all analog, and a good gamma-correction circuit
    was expensive to build.  The original NTSC video standard required
    cameras to have a transfer function with a gamma of 1/2.2, or
    about 0.45.  Recently, a more complex two-part transfer function
    has been adopted [SMPTE-170M], but its behavior can be well
    approximated by a power function with a gamma of 0.5.  When the
    resulting image is displayed on a CRT with a gamma of 2.5, the
    image on screen ends up with a gamma of about 1.25 relative to the
    original scene, which is appropriate for "dim surround" viewing.
    These days, video signals are often digitized and stored in
    computer frame buffers.  This works fine, but remember that gamma
    correction is "built into" the video signal, and so the digitized
    video has a gamma of about 0.5 relative to the original scene.
    Computer rendering programs often produce linear samples.  To
    display these correctly, intensity on the CRT needs to be directly
    proportional to the sample values in the frame buffer.  This can
    be done with a special hardware lookup table between the frame
    buffer and the CRT hardware.  The lookup table (often called LUT)
    is loaded with a mapping that implements a power function with a
    gamma of 0.4, thus providing "gamma correction" for the CRT gamma.
    Thus, gamma correction sometimes happens before the frame buffer,
    sometimes after.  As long as images created in a particular
    environment are always displayed in that environment, everything
    is fine.  But when people try to exchange images, differences in
    gamma correction conventions often result in images that seem far
    too bright and washed out, or far too dark and contrasty.

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

 Gamma-encoded samples are good
    So, is it better to do gamma correction before or after the frame
    buffer?
    In an ideal world, sample values would be stored in floating
    point, there would be lots of precision, and it wouldn't really
    matter much.  But in reality, we're always trying to store images
    in as few bits as we can.
    If we decide to use samples that are linearly proportional to
    intensity, and do the gamma correction in the frame buffer LUT, it
    turns out that we need to use at least 12 bits for each of red,
    green, and blue to have enough precision in intensity.  With any
    less than that, we will sometimes see "contour bands" or "Mach
    bands" in the darker areas of the image, where two adjacent sample
    values are still far enough apart in intensity for the difference
    to be visible.
    However, through an interesting coincidence, the human eye's
    subjective perception of brightness is related to the physical
    stimulation of light intensity in a manner that is very much like
    the power function used for gamma correction.  If we apply gamma
    correction to measured (or calculated) light intensity before
    quantizing to an integer for storage in a frame buffer, we can get
    away with using many fewer bits to store the image.  In fact, 8
    bits per color is almost always sufficient to avoid contouring
    artifacts.  This is because, since gamma correction is so closely
    related to human perception, we are assigning our 256 available
    sample codes to intensity values in a manner that approximates how
    visible those intensity changes are to the eye.  Compared to a
    linear-sample image, we allocate fewer sample values to brighter
    parts of the tonal range and more sample values to the darker
    portions of the tonal range.
    Thus, for the same apparent image quality, images using gamma-
    encoded sample values need only about two-thirds as many bits of
    storage as images using linear samples.

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

 General gamma handling
    When more than two nonlinear transfer functions are involved in
    the image pipeline, the term "gamma correction" becomes too vague.
    If we consider a pipeline that involves capturing (or calculating)
    an image, storing it in an image file, reading the file, and
    displaying the image on some sort of display screen, there are at
    least 5 places in the pipeline that could have nonlinear transfer
    functions.  Let's give each a specific name for their
    characteristic gamma:
    camera_gamma
       the characteristic of the image sensor
    encoding_gamma
       the gamma of any transformation performed by the software
       writing the image file
    decoding_gamma
       the gamma of any transformation performed by the software
       reading the image file
    LUT_gamma
       the gamma of the frame buffer LUT, if present
    CRT_gamma
       the gamma of the CRT, generally 2.5
    In addition, let's add a few other names:
    file_gamma
       the gamma of the image in the file, relative to the original
       scene.  This is
          file_gamma = camera_gamma * encoding_gamma
    display_gamma
       the gamma of the "display system" downstream of the frame
       buffer.  This is
          display_gamma = LUT_gamma * CRT_gamma
    viewing_gamma
       the overall gamma that we want to obtain to produce pleasing
       images --- generally 1.0 to 1.5.

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

    The file_gamma value, as defined above, is what goes in the gAMA
    chunk in a PNG file.  If file_gamma is not 1.0, we know that gamma
    correction has been done on the sample values in the file, and we
    could call them "gamma corrected" samples.  However, since there
    can be so many different values of gamma in the image display
    chain, and some of them are not known at the time the image is
    written, the samples are not really being "corrected" for a
    specific display condition.  We are really using a power function
    in the process of encoding an intensity range into a small integer
    field, and so it is more correct to say "gamma encoded" samples
    instead of "gamma corrected" samples.
    When displaying an image file, the image decoding program is
    responsible for making the overall gamma of the system equal to
    the desired viewing_gamma, by selecting the decoding_gamma
    appropriately.  When displaying a PNG file, the gAMA chunk
    provides the file_gamma value.  The display_gamma may be known for
    this machine, or it might be obtained from the system software, or
    the user might have to be asked what it is.  The correct
    viewing_gamma depends on lighting conditions, and that will
    generally have to come from the user.
    Ultimately, you should have
       file_gamma * decoding_gamma * display_gamma = viewing_gamma
 Some specific examples
    In digital video systems, camera_gamma is about 0.5 by declaration
    of the various video standards documents.  CRT_gamma is 2.5 as
    usual, while encoding_gamma, decoding_gamma, and LUT_gamma are all
    1.0.  As a result, viewing_gamma ends up being about 1.25.
    On frame buffers that have hardware gamma correction tables, and
    that are calibrated to display linear samples correctly,
    display_gamma is 1.0.
    Many workstations and X terminals and PC displays lack gamma
    correction lookup tables.  Here, LUT_gamma is always 1.0, so
    display_gamma is 2.5.

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

    On the Macintosh, there is a LUT.  By default, it is loaded with a
    table whose gamma is about 0.72, giving a display_gamma (LUT and
    CRT combined) of about 1.8.  Some Macs have a "Gamma" control
    panel that allows gamma to be changed to 1.0, 1.2, 1.4, 1.8, or
    2.2.  These settings load alternate LUTs that are designed to give
    a display_gamma that is equal to the label on the selected button.
    Thus, the "Gamma" control panel setting can be used directly as
    display_gamma in decoder calculations.
    On recent SGI systems, there is a hardware gamma-correction table
    whose contents are controlled by the (privileged) "gamma" program.
    The gamma of the table is actually the reciprocal of the number
    that "gamma" prints, and it does not include the CRT gamma. To
    obtain the display_gamma, you need to find the SGI system gamma
    (either by looking in a file, or asking the user) and then
    calculating
       display_gamma = 2.5 / SGI_system_gamma
    You will find SGI systems with the system gamma set to 1.0 and 2.2
    (or higher), but the default when machines are shipped is 1.7.
 A note about video gamma
    The original NTSC video standards specified a simple power-law
    camera transfer function with a gamma of 1/2.2 or 0.45.  This is
    not possible to implement exactly in analog hardware because the
    function has infinite slope at x=0, so all cameras deviated to
    some degree from this ideal.  More recently, a new camera transfer
    function that is physically realizable has been accepted as a
    standard [SMPTE-170M].  It is
       Vout = 4.5 * Vin                    if Vin < 0.018
       Vout = 1.099 * (Vin^0.45) - 0.099   if Vin >= 0.018
    where Vin and Vout are measured on a scale of 0 to 1.  Although
    the exponent remains 0.45, the multiplication and subtraction
    change the shape of the transfer function, so it is no longer a
    pure power function.  If you want to perform extremely precise
    calculations on video signals, you should use the expression above
    (or its inverse, as required).
    However, PNG does not provide a way to specify that an image uses
    this exact transfer function; the gAMA chunk always assumes a pure
    power-law function. If we plot the two-part transfer function
    above along with the family of pure power functions, we find that
    a power function with a gamma of about 0.5 to 0.52 (not 0.45) most
    closely approximates the transfer function.  Thus, when writing a

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

    PNG file with data obtained from digitizing the output of a modern
    video camera, the gAMA chunk should contain 0.5 or 0.52, not 0.45.
    The remaining difference between the true transfer function and
    the power function is insignificant for almost all purposes.  (In
    fact, the alignment errors in most cameras are likely to be larger
    than the difference between these functions.)  The designers of
    PNG deemed the simplicity and flexibility of a power-law
    definition of gAMA to be more important than being able to
    describe the SMPTE-170M transfer curve exactly.
    The PAL and SECAM video standards specify a power-law camera
    transfer function with a gamma of 1/2.8 or 0.36 --- not the 1/2.2
    of NTSC.  However, this is too low in practice, so real cameras
    are likely to have their gamma set close to NTSC practice.  Just
    guessing 0.45 or 0.5 is likely to give you viewable results, but
    if you want precise values you'll probably have to measure the
    particular camera.
 Further reading
    If you have access to the World Wide Web, read Charles Poynton's
    excellent "Gamma FAQ" [GAMMA-FAQ] for more information about
    gamma.

14. Appendix: Color Tutorial

 (This appendix is not part of the formal PNG specification.)
 About chromaticity
    The cHRM chunk is used, together with the gAMA chunk, to convey
    precise color information so that a PNG image can be displayed or
    printed with better color fidelity than is possible without this
    information.  The preceding chapters state how this information is
    encoded in a PNG image.  This tutorial briefly outlines the
    underlying color theory for those who might not be familiar with
    it.
    Note that displaying an image with incorrect gamma will produce
    much larger color errors than failing to use the chromaticity
    data.  First be sure the monitor set-up and gamma correction are
    right, then worry about chromaticity.
 The problem
    The color of an object depends not only on the precise spectrum of
    light emitted or reflected from it, but also on the observer ---
    their species, what else they can see at the same time, even what

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

    they have recently looked at!  Furthermore, two very different
    spectra can produce exactly the same color sensation.  Color is
    not an objective property of real-world objects; it is a
    subjective, biological sensation.  However, by making some
    simplifying assumptions (such as: we are talking about human
    vision) it is possible to produce a mathematical model of color
    and thereby obtain good color accuracy.
 Device-dependent color
    Display the same RGB data on three different monitors, side by
    side, and you will get a noticeably different color balance on
    each display.  This is because each monitor emits a slightly
    different shade and intensity of red, green, and blue light.  RGB
    is an example of a device-dependent color model --- the color you
    get depends on the device.  This also means that a particular
    color --- represented as say RGB 87, 146, 116 on one monitor ---
    might have to be specified as RGB 98, 123, 104 on another to
    produce the same color.
 Device-independent color
    A full physical description of a color would require specifying
    the exact spectral power distribution of the light source.
    Fortunately, the human eye and brain are not so sensitive as to
    require exact reproduction of a spectrum.  Mathematical, device-
    independent color models exist that describe fairly well how a
    particular color will be seen by humans.  The most important
    device-independent color model, to which all others can be
    related, was developed by the International Lighting Committee
    (CIE, in French) and is called XYZ.
    In XYZ, X is the sum of a weighted power distribution over the
    whole visible spectrum.  So are Y and Z, each with different
    weights.  Thus any arbitrary spectral power distribution is
    condensed down to just three floating point numbers.  The weights
    were derived from color matching experiments done on human
    subjects in the 1920s.  CIE XYZ has been an International Standard
    since 1931, and it has a number of useful properties:
  • two colors with the same XYZ values will look the same to

humans

  • two colors with different XYZ values will not look the same
  • the Y value represents all the brightness information

(luminance)

  • the XYZ color of any object can be objectively measured

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

    Color models based on XYZ have been used for many years by people
    who need accurate control of color --- lighting engineers for film
    and TV, paint and dyestuffs manufacturers, and so on.  They are
    thus proven in industrial use.  Accurate, device-independent color
    started to spread from high-end, specialized areas into the
    mainstream during the late 1980s and early 1990s, and PNG takes
    notice of that trend.
 Calibrated, device-dependent color
    Traditionally, image file formats have used uncalibrated, device-
    dependent color.  If the precise details of the original display
    device are known, it becomes possible to convert the device-
    dependent colors of a particular image to device-independent ones.
    Making simplifying assumptions, such as working with CRTs (which
    are much easier than printers), all we need to know are the XYZ
    values of each primary color and the CRT_gamma.
    So why does PNG not store images in XYZ instead of RGB?  Well, two
    reasons.  First, storing images in XYZ would require more bits of
    precision, which would make the files bigger.  Second, all
    programs would have to convert the image data before viewing it.
    Whether calibrated or not, all variants of RGB are close enough
    that undemanding viewers can get by with simply displaying the
    data without color correction.  By storing calibrated RGB, PNG
    retains compatibility with existing programs that expect RGB data,
    yet provides enough information for conversion to XYZ in
    applications that need precise colors.  Thus, we get the best of
    both worlds.
 What are chromaticity and luminance?
    Chromaticity is an objective measurement of the color of an
    object, leaving aside the brightness information.  Chromaticity
    uses two parameters x and y, which are readily calculated from
    XYZ:
       x = X / (X + Y + Z)
       y = Y / (X + Y + Z)
    XYZ colors having the same chromaticity values will appear to have
    the same hue but can vary in absolute brightness.  Notice that x,y
    are dimensionless ratios, so they have the same values no matter
    what units we've used for X,Y,Z.

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

    The Y value of an XYZ color is directly proportional to its
    absolute brightness and is called the luminance of the color.  We
    can describe a color either by XYZ coordinates or by chromaticity
    x,y plus luminance Y.  The XYZ form has the advantage that it is
    linearly related to (linear, gamma=1.0) RGB color spaces.
 How are computer monitor colors described?
    The "white point" of a monitor is the chromaticity x,y of the
    monitor's nominal white, that is, the color produced when
    R=G=B=maximum.
    It's customary to specify monitor colors by giving the
    chromaticities of the individual phosphors R, G, and B, plus the
    white point.  The white point allows one to infer the relative
    brightnesses of the three phosphors, which isn't determined by
    their chromaticities alone.
    Note that the absolute brightness of the monitor is not specified.
    For computer graphics work, we generally don't care very much
    about absolute brightness levels.  Instead of dealing with
    absolute XYZ values (in which X,Y,Z are expressed in physical
    units of radiated power, such as candelas per square meter), it is
    convenient to work in "relative XYZ" units, where the monitor's
    nominal white is taken to have a luminance (Y) of 1.0.  Given this
    assumption, it's simple to compute XYZ coordinates for the
    monitor's white, red, green, and blue from their chromaticity
    values.
    Why does cHRM use x,y rather than XYZ?  Simply because that is how
    manufacturers print the information in their spec sheets!
    Usually, the first thing a program will do is convert the cHRM
    chromaticities into relative XYZ space.
 What can I do with it?
    If a PNG file has the gAMA and cHRM chunks, the source_RGB values
    can be converted to XYZ.  This lets you:
  • do accurate grayscale conversion (just use the Y component)
  • convert to RGB for your own monitor (to see the original

colors)

  • print the image in Level 2 PostScript with better color

fidelity than a simple RGB to CMYK conversion could provide

  • calculate an optimal color palette
  • pass the image data to a color management system
  • etc.

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

 How do I convert from source_RGB to XYZ?
    Make a few simplifying assumptions first, like the monitor really
    is jet black with no input and the guns don't interfere with one
    another.  Then, given that you know the CIE XYZ values for each of
    red, green, and blue for a particular monitor, you put them into a
    matrix m:
               Xr Xg Xb
          m =  Yr Yg Yb
               Zr Zg Zb
    Here we assume we are working with linear RGB floating point data
    in the range 0..1.  If the gamma is not 1.0, make it so on the
    floating point data.  Then convert source_RGB to XYZ by matrix
    multiplication:
          X     R
          Y = m G
          Z     B
    In other words, X = Xr*R + Xg*G + Xb*B, and similarly for Y and Z.
    You can go the other way too:
          R      X
          G = im Y
          B      Z
    where im is the inverse of the matrix m.
 What is a gamut?
    The gamut of a device is the subset of visible colors which that
    device can display.  (It has nothing to do with gamma.)  The gamut
    of an RGB device can be visualized as a polyhedron in XYZ space;
    the vertices correspond to the device's black, blue, red, green,
    magenta, cyan, yellow and white.
    Different devices have different gamuts, in other words one device
    will be able to display certain colors (usually highly saturated
    ones) that another device cannot.  The gamut of a particular RGB
    device can be determined from its R, G, and B chromaticities and
    white point (the same values given in the cHRM chunk).  The gamut
    of a color printer is more complex and can only be determined by
    measurement.  However, printer gamuts are typically smaller than
    monitor gamuts, meaning that there can be many colors in a
    displayable image that cannot physically be printed.

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

    Converting image data from one device to another generally results
    in gamut mismatches --- colors that cannot be represented exactly
    on the destination device.  The process of making the colors fit,
    which can range from a simple clip to elaborate nonlinear scaling
    transformations, is termed gamut mapping.  The aim is to produce a
    reasonable visual representation of the original image.
 Further reading
    References [COLOR-1] through [COLOR-5] provide more detail about
    color theory.

15. Appendix: Sample CRC Code

 The following sample code represents a practical implementation of
 the CRC (Cyclic Redundancy Check) employed in PNG chunks.  (See also
 ISO 3309 [ISO-3309] or ITU-T V.42 [ITU-V42] for a formal
 specification.)
 The sample code is in the ANSI C programming language.  Non C users
 may find it easier to read with these hints:
 &
    Bitwise AND operator.
 ^
    Bitwise exclusive-OR operator.  (Caution: elsewhere in this
    document, ^ represents exponentiation.)
 >>
    Bitwise right shift operator.  When applied to an unsigned
    quantity, as here, right shift inserts zeroes at the left.
 !
    Logical NOT operator.
 ++
    "n++" increments the variable n.
 0xNNN
    0x introduces a hexadecimal (base 16) constant.  Suffix L
    indicates a long value (at least 32 bits).
    /* Table of CRCs of all 8-bit messages. */
    unsigned long crc_table[256];
    /* Flag: has the table been computed? Initially false. */
    int crc_table_computed = 0;

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

    /* Make the table for a fast CRC. */
    void make_crc_table(void)
    {
      unsigned long c;
      int n, k;
      for (n = 0; n < 256; n++) {
        c = (unsigned long) n;
        for (k = 0; k < 8; k++) {
          if (c & 1)
            c = 0xedb88320L ^ (c >> 1);
          else
            c = c >> 1;
        }
        crc_table[n] = c;
      }
      crc_table_computed = 1;
    }
    /* Update a running CRC with the bytes buf[0..len-1]--the CRC
       should be initialized to all 1's, and the transmitted value
       is the 1's complement of the final running CRC (see the
       crc() routine below)). */
    unsigned long update_crc(unsigned long crc, unsigned char *buf,
                             int len)
    {
      unsigned long c = crc;
      int n;
      if (!crc_table_computed)
        make_crc_table();
      for (n = 0; n < len; n++) {
        c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8);
      }
      return c;
    }
    /* Return the CRC of the bytes buf[0..len-1]. */
    unsigned long crc(unsigned char *buf, int len)
    {
      return update_crc(0xffffffffL, buf, len) ^ 0xffffffffL;
    }

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

16. Appendix: Online Resources

 (This appendix is not part of the formal PNG specification.)
 This appendix gives the locations of some Internet resources for PNG
 software developers.  By the nature of the Internet, the list is
 incomplete and subject to change.
 Archive sites
    The latest released versions of this document and related
    information can always be found at the PNG FTP archive site,
    ftp://ftp.uu.net/graphics/png/.  The PNG specification is
    available in several formats, including HTML, plain text, and
    PostScript.
 Reference implementation and test images
    A reference implementation in portable C is available from the PNG
    FTP archive site, ftp://ftp.uu.net/graphics/png/src/.  The
    reference implementation is freely usable in all applications,
    including commercial applications.
    Test images are available from
    ftp://ftp.uu.net/graphics/png/images/.
 Electronic mail
    The maintainers of the PNG specification can be contacted by e-
    mail at png-info@uunet.uu.net or at png-group@w3.org.
 PNG home page
    There is a World Wide Web home page for PNG at
    http://quest.jpl.nasa.gov/PNG/.  This page is a central location
    for current information about PNG and PNG-related tools.

17. Appendix: Revision History

 (This appendix is not part of the formal PNG specification.)
 The PNG format has been frozen since the Ninth Draft of March 7,
 1995, and all future changes are intended to be backwards compatible.
 The revisions since the Ninth Draft are simply clarifications,
 improvements in presentation, and additions of supporting material.
 On 1 October 1996, the PNG specification was approved as a W3C (World
 Wide Web Consortium) Recommendation.

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

 Changes since the Tenth Draft of 5 May, 1995
  • Clarified meaning of a suggested-palette PLTE chunk in a

truecolor image that uses transparency

  • Clarified exact semantics of sBIT and allowed sample depth

scaling procedures

  • Clarified status of spaces in tEXt chunk keywords
  • Distinguished private and public extension values in type

and method fields

  • Added a "Creation Time" tEXt keyword
  • Macintosh representation of PNG specified
  • Added discussion of security issues
  • Added more extensive discussion of gamma and chromaticity

handling, including tutorial appendixes

  • Clarified terminology, notably sample depth vs. bit depth
  • Added a glossary
  • Editing and reformatting

18. References

 [COLOR-1]
    Hall, Roy, Illumination and Color in Computer Generated Imagery.
    Springer-Verlag, New York, 1989.  ISBN 0-387-96774-5.
 [COLOR-2]
    Kasson, J., and W. Plouffe, "An Analysis of Selected Computer
    Interchange Color Spaces", ACM Transactions on Graphics, vol 11 no
    4 (1992), pp 373-405.
 [COLOR-3]
    Lilley, C., F. Lin, W.T. Hewitt, and T.L.J. Howard, Colour in
    Computer Graphics. CVCP, Sheffield, 1993.  ISBN 1-85889-022-5.
    Also available from
    <URL:http://info.mcc.ac.uk/CGU/ITTI/Col/colour_announce.html>
 [COLOR-4]
    Stone, M.C., W.B. Cowan, and J.C. Beatty, "Color gamut mapping and
    the printing of digital images", ACM Transactions on Graphics, vol
    7 no 3 (1988), pp 249-292.
 [COLOR-5]
    Travis, David, Effective Color Displays --- Theory and Practice.
    Academic Press, London, 1991.  ISBN 0-12-697690-2.
 [GAMMA-FAQ]
    Poynton, C., "Gamma FAQ".
    <URL:http://www.inforamp.net/%7Epoynton/Poynton-colour.html>

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

 [ISO-3309]
    International Organization for Standardization, "Information
    Processing Systems --- Data Communication High-Level Data Link
    Control Procedure --- Frame Structure", IS 3309, October 1984, 3rd
    Edition.
 [ISO-8859]
    International Organization for Standardization, "Information
    Processing --- 8-bit Single-Byte Coded Graphic Character Sets ---
    Part 1: Latin Alphabet No. 1", IS 8859-1, 1987.
    Also see sample files at
    ftp://ftp.uu.net/graphics/png/documents/iso_8859-1.*
 [ITU-BT709]
    International Telecommunications Union, "Basic Parameter Values
    for the HDTV Standard for the Studio and for International
    Programme Exchange", ITU-R Recommendation BT.709 (formerly CCIR
    Rec. 709), 1990.
 [ITU-V42]
    International Telecommunications Union, "Error-correcting
    Procedures for DCEs Using Asynchronous-to-Synchronous Conversion",
    ITU-T Recommendation V.42, 1994, Rev. 1.
 [PAETH]
    Paeth, A.W., "Image File Compression Made Easy", in Graphics Gems
    II, James Arvo, editor.  Academic Press, San Diego, 1991.  ISBN
    0-12-064480-0.
 [POSTSCRIPT]
    Adobe Systems Incorporated, PostScript Language Reference Manual,
    2nd edition. Addison-Wesley, Reading, 1990.  ISBN 0-201-18127-4.
 [PNG-EXTENSIONS]
    PNG Group, "PNG Special-Purpose Public Chunks".  Available in
    several formats from
    ftp://ftp.uu.net/graphics/png/documents/pngextensions.*
 [RFC-1123]
    Braden, R., Editor, "Requirements for Internet Hosts ---
    Application and Support", STD 3, RFC 1123, USC/Information
    Sciences Institute, October 1989.
    <URL:ftp://ds.internic.net/rfc/rfc1123.txt>

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

 [RFC-2045]
    Freed, N., and N. Borenstein, "Multipurpose Internet Mail
    Extensions (MIME) Part One: Format of Internet Message Bodies",
    RFC 2045, Innosoft, First Virtual, November 1996.
    <URL:ftp://ds.internic.net/rfc/rfc2045.txt>
 [RFC-2048]
    Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail
    Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
    Innosoft, MCI, USC/Information Sciences Institute, November 1996.
    <URL:ftp://ds.internic.net/rfc/rfc2048.txt>
 [RFC-1950]
    Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
    Specification version 3.3", RFC 1950, Aladdin Enterprises, May
    1996.
    <URL:ftp://ds.internic.net/rfc/rfc1950.txt>
 [RFC-1951]
    Deutsch, P., "DEFLATE Compressed Data Format Specification version
    1.3", RFC 1951, Aladdin Enterprises, May 1996.
    <URL:ftp://ds.internic.net/rfc/rfc1951.txt>
 [SMPTE-170M]
    Society of Motion Picture and Television Engineers, "Television
    --- Composite Analog Video Signal --- NTSC for Studio
    Applications", SMPTE-170M, 1994.

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

19. Credits

 Editor
    Thomas Boutell, boutell@boutell.com
 Contributing Editor
    Tom Lane, tgl@sss.pgh.pa.us
 Authors
    Authors' names are presented in alphabetical order.
  • Mark Adler, madler@alumni.caltech.edu
  • Thomas Boutell, boutell@boutell.com
  • Christian Brunschen, cb@df.lth.se
  • Adam M. Costello, amc@cs.berkeley.edu
  • Lee Daniel Crocker, lee@piclab.com
  • Andreas Dilger, adilger@enel.ucalgary.ca
  • Oliver Fromme, fromme@rz.tu-clausthal.de
  • Jean-loup Gailly, gzip@prep.ai.mit.edu
  • Chris Herborth, chrish@qnx.com
  • Alex Jakulin, Aleks.Jakulin@snet.fri.uni-lj.si
  • Neal Kettler, kettler@cs.colostate.edu
  • Tom Lane, tgl@sss.pgh.pa.us
  • Alexander Lehmann, alex@hal.rhein-main.de
  • Chris Lilley, chris@w3.org
  • Dave Martindale, davem@cs.ubc.ca
  • Owen Mortensen, 104707.650@compuserve.com
  • Keith S. Pickens, ksp@swri.edu
  • Robert P. Poole, lionboy@primenet.com
  • Glenn Randers-Pehrson, glennrp@arl.mil or

randeg@alumni.rpi.edu

  • Greg Roelofs, newt@pobox.com
  • Willem van Schaik, willem@gintic.gov.sg
  • Guy Schalnat
  • Paul Schmidt, pschmidt@photodex.com
  • Tim Wegner, 71320.675@compuserve.com
  • Jeremy Wohl, jeremyw@anders.com
    The authors wish to acknowledge the contributions of the Portable
    Network Graphics mailing list, the readers of comp.graphics, and
    the members of the World Wide Web Consortium (W3C).

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

    The Adam7 interlacing scheme is not patented and it is not the
    intention of the originator of that scheme to patent it. The
    scheme may be freely used by all PNG implementations. The name
    "Adam7" may be freely used to describe interlace method 1 of the
    PNG specification.
 Trademarks
    GIF is a service mark of CompuServe Incorporated.  IBM PC is a
    trademark of International Business Machines Corporation.
    Macintosh is a trademark of Apple Computer, Inc.  Microsoft and
    MS-DOS are trademarks of Microsoft Corporation.  PhotoCD is a
    trademark of Eastman Kodak Company.  PostScript and TIFF are
    trademarks of Adobe Systems Incorporated.  SGI is a trademark of
    Silicon Graphics, Inc.  X Window System is a trademark of the
    Massachusetts Institute of Technology.

COPYRIGHT NOTICE

 Copyright (c) 1996 by: Massachusetts Institute of Technology (MIT)
 This W3C specification is being provided by the copyright holders
 under the following license. By obtaining, using and/or copying this
 specification, you agree that you have read, understood, and will
 comply with the following terms and conditions:
 Permission to use, copy, and distribute this specification for any
 purpose and without fee or royalty is hereby granted, provided that
 the full text of this NOTICE appears on ALL copies of the
 specification or portions thereof, including modifications, that you
 make.
 THIS SPECIFICATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO
 REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED.  BY WAY OF
 EXAMPLE, BUT NOT LIMITATION, COPYRIGHT HOLDERS MAKE NO
 REPRESENTATIONS OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY
 PARTICULAR PURPOSE OR THAT THE USE OF THE SPECIFICATION WILL NOT
 INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER
 RIGHTS.  COPYRIGHT HOLDERS WILL BEAR NO LIABILITY FOR ANY USE OF THIS
 SPECIFICATION.

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

 The name and trademarks of copyright holders may NOT be used in
 advertising or publicity pertaining to the specification without
 specific, written prior permission.  Title to copyright in this
 specification and any associated documentation will at all times
 remain with copyright holders.

Security Considerations

 Security issues are discussed in Security considerations (Section
 8.5).

Author's Address

 Thomas Boutell
 PO Box 20837
 Seattle, WA  98102
 Phone: (206) 329-4969
 EMail: boutell@boutell.com

Boutell, et. al. Informational [Page 102]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2083.txt · Last modified: 1997/03/22 01:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki