============================== Proposed Incorporation of sPLT draft 1.0.0 (Tue 22 Sep 1998) ============================== editor: Adam M. Costello Description =========== This is a set of edits to be applied to the PNG 1.0 spec to incorporate the sPLT chunk. It uses the RFC 2083 text version as its basis. The motivation is that the core spec already discusses PLTE/hIST, which is generally an inferior method of providing suggested palettes, so sPLT should be discussed in the same document. Except for section 4.3 (chunk summary), this proposal has no overlap with the gamma handling proposal, so either one or both may be applied. Format ====== Lines beginning with ">" are quoted for context purposes and don't need to be changed. Lines beginning with "-" are to be removed. Lines beginning with "?" are new text that is *not* to be inserted, unless we change our minds. Lines beginning with "#" are comments, which may be helpful to whomever applies the edits. Lines containing only "..." indicate skipped material that doesn't need to be changed. Other non-blank lines are to be inserted. Principles ========== * All content from the sPLT section of the latest drafts of the PNG Extensions document should be used, with no substantive changes. * Editorial changes for aesthetic purposes are okay. These are almost always for the purpose of seamless integration with the rest of the spec. The most notable change is that the content is divided among three sections. Edits ===== ... > 4. Chunk Specifications ... > 4.1.2. PLTE Palette ... > 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, If neither PLTE nor sPLT (Section 4.2.x) is present, > such a viewer will need to select colors on > its own, but it is often preferable for this to be done once by > the encoder. (See Recommendations for Encoders: Suggested > palettes, Section 9.5.) ... - 4.2.4. hIST Image histogram 4.2.4. hIST Palette 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. A hIST chunk can appear only when a PLTE 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. ... 4.2.x. sPLT Suggested palette This chunk can be used to suggest a reduced palette to be used when the display device is not capable of displaying the full range of colors present in the image. If present, it provides a recommended set of colors, with alpha and frequency information, that can be used to construct a reduced palette to which the PNG image can be quantized. This chunk contains a null-terminated text string that names the palette and a one-byte sample depth, followed by a series of palette entries, each a six-byte or ten-byte series containing five unsigned integers: Palette name: 1-79 bytes (character string) Null terminator: 1 byte Sample depth: 1 byte Red: 1 or 2 bytes Green: 1 or 2 bytes Blue: 1 or 2 bytes Alpha: 1 or 2 bytes Frequency: 2 bytes ... etc... There can be any number of entries; a decoder determines the number of entries from the remaining chunk length after the sample depth byte. It is an error if this remaining length is not divisible by 6 (if the sPLT sample depth is 8) or by 10 (if the sPLT sample depth is 16). Entries must appear in decreasing order of frequency. There is no requirement that the entries all be used by the image, nor that they all be different. The palette name can be any convenient name for referring to the palette (for example, "256 color including Macintosh default", "256 color including Windows-3.1 default", "Optimal 512"). It may help applications or people to choose the appropriate suggested palette when more than one appears in a PNG file. The palette name is case-sensitive and subject to the same restrictions as a tEXt keyword: it must contain only printable Latin-1 [ISO/IEC-8859-1] characters (33-126 and 161-255) and spaces (32), but no leading, trailing, or consecutive spaces. The sPLT sample depth must be 8 or 16. The red, green, blue, and alpha samples are either one or two bytes each, depending on the sPLT sample depth, regardless of the image bit depth. The color samples are not premultiplied by alpha, nor are they precomposited against any background. An alpha value of 0 means fully transparent, while an alpha value of 255 (when the sPLT sample depth is 8) or 65535 (when the sPLT sample depth is 16) means fully opaque. The palette samples have the same gamma and chromaticity values as those of the PNG image. Each frequency value is proportional to the fraction of pixels in the image that are closest to that palette entry in RGBA space, before the image has been composited against any background. 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 frequencies for "important" colors such as those in a company logo or in the facial features of a portrait. Zero is a valid frequency meaning the color is "least important" or that it is rarely if ever used. But when all of the frequencies are zero, they are meaningless (nothing may be inferred about the actually frequencies of the colors). The sPLT chunk can appear for any PNG color type. Note that entries in sPLT can fall outside the colorspace of the PNG image; for example, in a grayscale PNG, sPLT entries would typically satisfy R=G=B, but this is not required. Similarly, sPLT entries can have nonopaque alpha values even when the PNG image does not use transparency. If sPLT appears, it must precede the first IDAT chunk. There can be multiple sPLT chunks, but if so they must have different palette names. See Recommendations for Encoders: Suggested palettes (Section 9.5) and Recommendations for Decoders: Suggested-palette and histogram usage (Section 10.10). ... > 4.3. Summary of standard chunks ... > 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 sPLT Yes Before IDAT > tIME No None > tEXt Yes None > zTXt Yes None ... > 9. Recommendations for Encoders ... > 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. Suggested palettes can appear as sPLT chunks in any PNG file, or as a PLTE chunk in truecolor PNG files. In either case, the suggested palette is not an essential part of the image data, but it may be used to present the image on indexed-color display hardware. Suggested palettes are 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.) When sPLT is used to provide a suggested palette, it is recommended that the encoder use the frequency fields to indicate the relative importance of the palette entries, rather than leave them all zero (meaning undefined). The frequency values are most easily computed as "nearest neighbor" counts, that is, the approximate usage of each RGBA palette entry if no dithering is applied. (These counts will often be available for free as a consequence of developing the suggested palette.) Because the suggested palette includes transparency information, it should be computed for the uncomposited image. Even for indexed-color images, sPLT can be used to define alternative reduced palettes for viewers that are unable to display all the colors present in the PLTE chunk. An older method for including a suggested palette in a truecolor PNG file uses the PLTE chunk. The histogram (frequencies) should appear in a separate hIST chunk. Also, PLTE does not include transparency information, so for - 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. # The preceeding and following paragraphs have been swapped from # their original order. > For images of color type 2 (truecolor without alpha channel), it > is recommended that - the palette and histogram PLTE and hIST > 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). > If PLTE appears without bKGD in an image of color type 6, the > circumstances under which the palette was computed are > unspecified. For providing suggested palettes, sPLT is more flexible than PLTE in the following ways: * With sPLT, there can be multiple suggested palettes. A choose adecoder may n appropriate palette based on name or number of choose aentries. * In an RGBA (color type 6) PNG, PLTE represents a palette already composited against the bKGD color, so it is useful only for display against that background color. The sPLT chunk provides an uncomposited palette, which is useful for display against backgrounds of the decoder's choice. * Since sPLT is a noncritical chunk, a PNG editor can add or modify suggested palettes without being forced to discard unknown unsafe-to-copy chunks. * Whereas sPLT is allowed in PNG files of color types 0, 3, and 4 (grayscale and indexed), PLTE cannot be used to provide reduced palettes in these cases. * More than 256 entries can appear in sPLT. An encoder that uses sPLT may choose to write a PLTE/hIST suggested palette as well, for backwards compatibility with decoders that do not recognize sPLT. ... > 10. Recommendations for Decoders ... > 10.3. Truecolor image handling ... > 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). PNG allows the encoder to supply suggested palettes, but not all encoders will do so, and the suggested palettes may be unsuitable in any case (they 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. ... > 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. For viewers running on indexed-color hardware trying to display a truecolor image, or an indexed-color image whose palette is too large for the framebuffer, the encoder may have provided one or more suggested palettes in sPLT chunks. If one of them, based on its size and perhaps its name, the decoder can use that palette. Note that suggested palettes with a sample depth different from what the decoder needs can be converted using sample depth rescaling (Section 10.4). When the background is a solid color, the decoder should composite the image and the suggested palette against that color, then quantize the resulting image to the resulting RGB palette. When the image uses transparency and the background is not a solid color, no suggested palette is likely to be useful. - 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. For truecolor images, a suggested palette might also be provided in a PLTE chunk. If the image has a tRNS chunk and the background is a solid color, the viewer can adapt the suggested paletted for use with this background color. To do this, replace the palette entry closest to the tRNS color with the background color, or just add a palette entry for the background color if the viewer can handle more colors than there are palette entries. > For images of color type 6 (truecolor with alpha channel), any - suggested palette PLTE chunk > 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 the > 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 PLTE chunk > 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. In truecolor PNG files, if both PLTE and sPLT appear, the decoder can choose from among the palettes suggested by both, bearing in mind the different transparency semantics mentioned above. - The histogram chunk is useful when the viewer cannot provide as - many colors as are used in the image's palette. The frequencies in sPLT and hIST chunks are useful when the viewer cannot provide as many colors as are used in the 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 frequencies can > be used as the input data, thus avoiding a scan of the image data. - If no palette or histogram chunk is If no suggested palettes are > 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).