tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2083


PNG (Portable Network Graphics) Specification Version 1.0

Part 3 of 4, p. 41 to 69
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 41 
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

   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.

Top      Up      ToC       Page 42 
      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

   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.

Top      Up      ToC       Page 43 
      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

         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

      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.

Top      Up      ToC       Page 44 
      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.

Top      Up      ToC       Page 45 
      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 = 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

      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.

Top      Up      ToC       Page 46 
      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-

                  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

      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.

Top      Up      ToC       Page 47 
      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

      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.

Top      Up      ToC       Page 48 
      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.

Top      Up      ToC       Page 49 
      If PLTE appears without bKGD in an image of color type 6, the
      circumstances under which the palette was computed are

   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.

Top      Up      ToC       Page 50 
      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

      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

      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.

Top      Up      ToC       Page 51 
      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

Top      Up      ToC       Page 52 
      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

   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

Top      Up      ToC       Page 53 
      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

   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)


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

Top      Up      ToC       Page 54 
      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

         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.

Top      Up      ToC       Page 55 
      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

      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

      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.

Top      Up      ToC       Page 56 
      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.

Top      Up      ToC       Page 57 
      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.

Top      Up      ToC       Page 58 
      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

      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.

Top      Up      ToC       Page 59 
      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      }

Top      Up      ToC       Page 60 
         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  }


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

Top      Up      ToC       Page 61 
          * 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
          * 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
          * 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.

Top      Up      ToC       Page 62 
      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

      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
             row := Starting_Row[pass]

             while row < height

Top      Up      ToC       Page 63 
                 col := Starting_Col[pass]

                 while col < width
                     visit (row, col,
                            min (Block_Height[pass], height - row),
                            min (Block_Width[pass], width - col))
                     col := col + Col_Increment[pass]
                 row := row + Row_Increment[pass]

             pass := pass + 1

      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.

Top      Up      ToC       Page 64 
      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

      See also Recommendations for Encoders: Suggested palettes (Section

   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

Top      Up      ToC       Page 65 
      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

      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

      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.

      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.

Top      Up      ToC       Page 66 
   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.

      Eight bits; also called an octet.

      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.

      A pair of values x,y that precisely specify the hue, though not
      the absolute brightness, of a perceived color.

      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.

      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.

      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.

      Cathode Ray Tube: a common type of computer display hardware.

Top      Up      ToC       Page 67 
      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.

      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.

      A transformation applied to image data in hopes of improving its
      compressibility.  PNG uses only lossless (reversible) filter

   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.

      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.

      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.

Top      Up      ToC       Page 68 
   Lossy compression
      Any method of data compression that reconstructs the original data
      approximately, rather than exactly.

      Least Significant Byte of a multi-byte value.

      Perceived brightness, or grayscale level, of a color.  Luminance
      and chromaticity together fully define a perceived color.

      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.

      Most Significant Byte of a multi-byte value.

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

      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

      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

Top      Up      ToC       Page 69 
   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

      One horizontal row of pixels within an image.

      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.

      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

(page 69 continued on part 4)

Next RFC Part