PNG Proposed sPLT Chunk, draft 19961111

File: png-proposed-sPLT-19961111.txt

Status of this Memo

This document is an informal draft of the PNG development group.

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

Notices

Copyright © 1996 Thomas Boutell

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.

Changes from the 07 November 1996 sPLT draft (version 19961107):

Abstract

This document describes a special-purpose chunk type, sPLT, that has been proposed for use in various PNG (Portable Network Graphics) applications. It has not yet been approved for registration by the PNG developers, and therefore is experimental and its format is subject to change.

Table of Contents

1. Introduction

The chunk described here has been proposed to the PNG development group. Its definition is subject to change until such time as the group formally registers it. No decoder is required or expected to implement this chunk except for experimental or evaluation purposes. Comments on this proposal, and new proposals for additional chunk types, should be sent to the PNG specification maintainers at png-info@uunet.uu.net. The basic PNG specification is available from the W3C archive at http://www.w3.org/pub/WWW/TR/REC-png.html.

2. Using Proposed PNG Chunks

The chunk described in this document has not yet been registered by the PNG maintainers. Therefore it has a lower-case letter in the second position of the chunkname. It is an experimental chunk and the format is subject to change. If and when it becomes registered, the second letter of the chunk name will become uppercase, and the "signature" field, if present, and its zero-byte terminator will be deleted. The chunk description will be moved either to a PNG extensions document or to the core PNG specification. There will be no further change to the chunk format after it has been registered.

Whenever you use an unregistered chunk you should also include a tEXt chunk describing it, for example:

tEXtComment\0
This file contains a spAL chunk written according to
the format given in Version 19961022 of the PNG Proposed sPLT
Chunk document.

3. Summary of Proposed Chunk

This table summarizes some properties of the proposed chunk described in this document.
   Chunk name      Multiple   Ordering
                      OK?     constraints
   
   spAL               Yes     Before IDAT

4. Proposed Chunk Specification

This section provides the detailed specification for the proposed chunk.

4.1. spAL 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's contents are a zero-byte-terminated text string that names the palette [followed by a 20-byte signature and a zero-byte terminator] and a 1-byte spAL_sample_depth integer, followed by a series of palette entries, each a six-byte or ten-byte series containing five unsigned integers:

n bytes:     (Latin-1 text) palette_name
1 byte:      (null) terminator

[ 20 bytes:  signature ("PNG group 1996-10-22")
  1 byte:    (null) separator ]

1 byte:      (unsigned integer)  spAL_sample_depth
             must be 8 or 16

1 or 2 bytes:  (unsigned integer)  red intensity
           0:   black
           etc.
           255 or 65535: full red intensity

1 or 2 bytes:  (unsigned integer)  green intensity

1 or 2 bytes:  (unsigned integer)  blue intensity

1 or 2 bytes:  (unsigned integer)  alpha
           0: fully transparent
           etc.
           255 or 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 [, the "signature" and its zero-byte terminator], and the spAL_sample_depth byte. This length not divisible by six (if spAL_sample_depth==8) or by ten (if spAL_sample_depth==16) is an error. 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" (e.g. "256 color including Macintosh default", "256 color including Windows-3.1 default", "Optimal 512") identifies the palette. It may help applications or people to choose the appropriate suggested palette when more than one appears in a PNG file. The "palette_name" string must follow the same restrictions imposed on tEXt keywords: 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. This differs from the treatment of suggested palettes represented by PLTE: in an image that uses transparency, spAL provides suggested uncomposited color values, while a suggested-palette PLTE provides suggested colors after compositing against the bKGD color. A decoder can build a target palette by compositing spAL palette entries against any background color or set of background colors that it chooses. It can then composite the truecolor PNG image against the desired background, and finally quantize the composited image into the target palette.

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. But when all of the frequency values are zero, the "frequency" is undefined.

The palette uses 8 bits or 16 bits (1 or 2 bytes) per value according to the number given in the spAL_sample_depth field, regardless of the image bit depth specification. Decoders wishing to construct a palette with a different bit depth can accomplish this by scaling the RGBA entries, as described under "[link] Sample depth rescaling" in the PNG specification. The palette samples have the same gamma and chromaticity values as those of the PNG image.

spAL can appear for any color type. It is expected, but not actually required, that all entries in an spAL for a grayscale PNG will have R=G=B, and that all entries will have the maximum alpha value in a PNG that does not have transparency (no tRNS chunk nor alpha channel). [Would it be smarter to just require these statements to be true?] In an indexed-color (color type 3) PNG, PLTE defines the full color range of the PNG image, but spAL can be used to define alternative reduced palettes for viewers that are unable to display all the colors present in the PLTE chunk.

If spAL appears, it must precede the first IDAT chunk. There can be multiple spAL chunks, but if so they must have different palette_names.

Note: The core PNG specification recommends the use of PLTE and hIST chunks to define suggested palettes for truecolor images. This is still allowed, but spAL provides a more flexible solution:

In PNG files of color types 2 and 6, an spAL-aware decoder should treat PLTE and hIST as equivalent to a nameless 8-bit spAL with all entries fully opaque (alpha = 255). An encoder that uses spAL may choose to write a PLTE/hIST suggested palette as well, for backwards compatibility with decoders that do not recognize spAL. Note that hIST defines the frequency of PLTE entries, not the entries of spAL.

5. Discussion

This discussion does not form a part of the proposed specification and will not appear in the final documentation.

5.1. spAL Discussion

It is proposed to register the chunk as sPLT and to include it in the "PNG extensions" document. The registered version will not include the "signature" field and its zero-byte terminator, and the final specification will not contain any material from this document that is included in square brackets ("[...]").

The format of this chunk has not changed since version 19961022 of this document. The chunk was originally called spLT but the name was changed to spAL in the 19960927 version of the png-proposed-chunks document when the format changed from 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 19961008 version has the identical format to the April version, no "signature" field was needed, and it was removed.

Zero "frequency": There have been changes to the interpretation of frequency==0.

Palette sample depth: Changed from 16 bits to 8 or 16 bits in the 19961022 version. Since the format changed, the chunk name was changed back to spAL again and a new "signature" field was added. Test implementations can safely distinguish among the April 1996 version (spLT, no signature), the September 27 version (spAL, 1996-09-14 signature), and this version (spAL, 1996-10-22 signature).

The 19961107 and 19961111 drafts clarify the interaction of spAL with PLTE: in color types 2 and 6, PLTE should be treated as if it were (another) spAL. The meaning of spAL in color types 0, 3, and 4 is also clarified.

6. Security considerations

Security considerations are addressed in the basic PNG specification, 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" [and "signature"] string of the spAL 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.

7. Credits

Trademarks

Contributors

The names of contributors whose names do not already appear in the PNG specification are presented in alphabetical order:

Editor

End of PNG Proposed sPLT Chunk Listing. Expires 11 May 1997.