Comments on this document can be sent to the PNG specification maintainers at png-info@uunet.uu.net or at png-list@dworkin.wustl.edu.
Distribution of this memo is unlimited.
At present, the latest version of this document is available on the
World Wide Web from
ftp://swrinde.nde.swri.edu/pub/png-group/documents/.
Permission is granted to copy and distribute this document for any purpose and without charge, provided that the copyright notice and this notice are preserved, and that any substantive changes or deletions from the original are clearly marked.
http://www.w3.org/pub/WWW/TR/REC-png.html.
Whenever you use an unregistered chunk you should also include a tEXt chunk describing it, for example:
tEXtComment\0 This file contains a spLT chunk written according to the format given in Version 19961015 of the PNG Proposed Chunks document.
Chunk name Multiple Ordering
OK? constraints
spLT Yes Before IDAT
This chunk's contents are a zero-byte-terminated text string that names the palette, followed by a series of palette entries, each a ten-byte series, containing five unsigned integers:
n bytes: (Latin-1 text) palette_name
1 byte: (null) terminator
2 bytes: (unsigned integer) red intensity
0: black
etc.
65535: full red intensity
2 bytes: (unsigned integer) green intensity
2 bytes: (unsigned integer) blue intensity
2 bytes: (unsigned integer) alpha
0: fully transparent
etc.
65535: fully opaque
2 bytes: (unsigned integer) frequency
(relative frequency of occurrence)
etc.
There can be any number of entries; a decoder determines the number of
entries from the remaining chunk length after the "palette_name" field and its
zero-byte terminator.
This length not divisible by ten is an error. Entries must appear
in decreasing order of "frequency".
The "palette_name" (e.g. "256 color including Macintosh default", "256 color including Windows-3.1 default", "Browser Safe Palette") identifies the palette, which can permit applications or people to choose the appropriate one when more than one suggested palette appears in a PNG file. The "palette_name" string must follow the format of a tEXt keyword: It must consist only of printable Latin-1 characters and must not have leading or trailing blanks, but can have single embedded blanks. There must be at least one and no more than 79 characters in the name. Names are case-sensitive.
The red, green, and blue values are not premultiplied by alpha, nor are they precomposited against any background. A decoder can build a palette by compositing those palette entries against any background color or set of background colors that it chooses. See [link to bKGD]
Each frequency entry is proportional to the fraction of pixels in the image that are closest to that palette entry, without regard to any compositing against a background palette. The exact scale factor is chosen by the encoder, but should be chosen so that the range of individual values reasonably fills the range 0 to 65535. It is acceptable to artificially inflate the "frequency" values for "important" colors such as those in a company logo or in the facial features of a portrait. Zero is a valid value for frequency, meaning the color is "least important" or that it is rarely if ever used. When all of the frequency values are zero, the "frequency" is undefined.
The palette uses 16 bits (2 bytes) per value regardless of the image bit depth specification. Decoders wishing to construct a palette with a smaller bit depth can accomplish this by scaling down the RGB entries, as described under "sample depth rescaling" in the PNG specification. The palette samples have the same gamma and chromaticity values as those of the pixel samples.
Note: Earlier versions of the PNG specification recommended that the PLTE [link to PLTE] and hIST chunks be used for this purpose. While this is still allowed, to maintain backward compatibility, the spLT chunk is preferable, particularly when transparent pixels are present. When both the PLTE and spLT chunks are present, the PLTE data should only be used for decoding the indexed-color (color type 3) pixels, and the spLT data should be used for constructing the display palette. If the hIST chunk is also present, decoders that process the spLT chunk should ignore it.
This chunk can appear for any color type. If this chunk does appear, it must precede the first IDAT chunk. There can be multiple spLT chunks, with different names.
The format of this chunk has not changed since version 960406 of the png-proposed-chunks document. There is some change to the wording of the specification (interpretation of zero values of frequency) in the 19961015 version. A variant of the format, with "gamma" and "signature" fields, was proposed in the 19960927 version, where it was called spAL, but that variant has been abandoned and we have reverted to the April 1996 (960406) version of the format.
Gamma field: In the 19960927 version, a "gamma" field was added, primarily for use in multiple-image formats. This seemed to introduce more problems than it resolved, so it has been removed from the present proposal, and multiple-image formats can define a variant of sPLT (with a different chunk name such as "gPLT") that has a gamma field, if necessary.
Signature field: In the 19960927 version, a "signature" field was added to distinguish the September version from the April version. Since the present version has the identical format to the April version, no "signature" field is needed, and it has been removed.
Zero "frequency": There have been changes to the interpretation of frequency==0.
http://www.w3.org/pub/WWW/TR/REC-png.html.
The same precautions taken when displaying tEXt data should be taken when displaying the text contained in the "palette_name" string of the spLT chunk. Viewers should not display this string directly without first checking for the presence of nonprintable characters, and for the <ESC> character in particular.
No known additional security hazards are posed by the chunks described here.