PNG Proposed Chunks, draft 19961008

File

png-proposed-chunks-19961008.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

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 14 September 1996 draft (version 19960914):

Clarified that applications should ignore gAMA and cHRM when they process the srGB chunk.
Changed the "name" examples in the spAL chunk description.
Added statements about the proposed registered chunk names and the documents in which the specification will be included when registered.

Abstract

This document describes some special-purpose chunk types that have been proposed for use in various PNG (Portable Network Graphics) applications. They have not yet been approved for registration by the PNG developers, and therefore are experimental and their format is subject to change. The proposed chunks are alIG, fiNG, spAL, and srGB.

1. Introduction
2. Using Proposed PNG Chunks
3. Summary of Proposed Chunks
4. Proposed Chunk Specifications
5. Chunks not described here
6. Security considerations
7. References
8. Credits

1. Introduction

Chunks described here have been proposed to the PNG development group. Their definitions are subject to change until such time as the group formally registers them. No decoder is required or expected to implement these chunks except for experimental or evaluation purposes. Comments on these proposals, 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/WD-png

2. Using Proposed PNG Chunks

No chunks described in this document have yet been registered by the PNG maintainers. Therefore they have a lower-case letter in the second position of the chunkname. They are experimental chunks and the format is subject to change. If and when any become registered, the second letter of the chunk name will become uppercase, 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 format.

Whenever you use any of these unregistered chunks 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 19960914 of the PNG Proposed
Chunks document.

For those proposed chunks that have a "signature" field, decoders should check to ensure that the signature field is present and that its contents exactly match the specified string.

3. Summary of Proposed Chunks

This table summarizes some properties of the proposed chunks described in this document.

   Chunk name      Multiple   Ordering
                      OK?     constraints
   
   alIG               No      Before IDAT
   fiNG               No      None
   spAL               Yes     Before IDAT
   srGB               No      Before PLTE and IDAT

4. Proposed Chunk Specifications

This section provides the detailed specifications for the proposed chunks.

4.1. `alIG` Alignment

This chunk can be used to provide alignment information to applications. It is especially useful for transparent images in which the edges of the interesting part of the picture do not correspond exactly to the edges of the image data. It can be helpful in aligning the picture with adjacent text, if there is a specific location in the picture that should be aligned with the text baseline. (We use "picture" to mean the thing depicted, as opposed to "image" which is the entire width x height rectangle described by the PNG stream.)

The format of this chunk has not changed since version 19960406 of this document. There has been no change to any part of the specification for this chunk since version 19960914.

It has not yet been decided which document should contain the specification of this chunk in its registered form. It is proposed to register this chunk as "aLIG".

This chunk's contents are

left      4 bytes  left side of picture
center    4 bytes  center of picture (horizontal)
right     4 bytes  right side of picture
top       4 bytes  top of picture
middle    4 bytes  middle of picture (vertical)
baseline  4 bytes  typographic baseline of picture (vertical)
bottom    4 bytes  bottom of picture

All values are signed 32-bit integer values, measured in pixels downward from the top of the image or rightward from the left edge of the image.

Applications will not normally try to use all of the alignment values at once. A browser might use the "center" value when it wishes to center the image left-to-right on a page. A typographic system might use the "top" value to line up an image that contains a fancy capital letter with the top of the adjacent text, or the "baseline" value to line up images containing mathematical equations. Typographic systems could also determine the typographic "height", "depth", "width", and reference point values:

font_height := baseline - top
font_width  := right - left
font_depth  := bottom - baseline
font_ref_x  := left
font_ref_y  := baseline

If the alIG chunk is not present, applications can assume the following values:

left        := 0
center      := width/2
right       := width
top         := 0
middle      := height/2
baseline    := height
bottom      := height

If an encoder writes the alIG chunk, it must supply all of the fields, and should use these values as defaults.

Only one alIG chunk is permitted in a PNG datastream. If present, it must appear prior to the first IDAT chunk.

4.2. `fiNG` Fingerprint

This chunk contains an MD5 fingerprint of the uncompressed, unfiltered, uninterlaced image data, that can be used for rapidly determining whether two files contain the same image, without having to actually decode the IDAT chunks.

The MD5 fingerprint is calculated according to the RSA Data Security, Inc. MD5 Message-Digest Algorithm, copyright by RDS Data Security, Inc., 1991-1992. A reference implementation of the algorithm and the license for its use are given in [MD5].

The format of this chunk has not changed since version 19960710 of this document. There are presently no plans to register this chunk. There has been no change to any part of the specification for this chunk since version 19960710.

The fiNG chunk's contents are

16 bytes: image fingerprint

The fingerprint is the MD5 digest value computed on the image data, promoted by left-bit-replication (see bit_depth scaling in PNG spec) to 16-bit RGBA (colortype 6). Scaling is done without regard to the sBIT chunk, if present. When promoting truecolor images, fill the alpha samples with 0xffff (all ones). The fingerprint is calculated without regard to any ancillary chunks. The value is computed on the data in the same order as the bytes would appear in a color type 6 datastream, except that no filter bytes are included in the calculation. The MD5 fingerprint value is computed as described in RFC 1321 [RFC1321].

An image's fingerprint will not change if the image is changed from interlaced to noninterlaced, or compressed with a different method, or filtered differently, or if any ancillary chunks are added, modified, or removed. It will change if there is any lossy conversion of the pixel data or if the PLTE data is changed in an indexed-color image.

The fiNG fingerprint is trivial to forge. Be cautious when using a fingerprint chunk generated by someone else. It is safer to recalculate and install your own fiNG chunk when you receive an image from outside of your control.

While the fiNG chunk does not have any ordering requirements, you should put it early in the file for quick access.

4.3. `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 truecolor image can be quantized.

The format of this chunk has not changed since version 19960914 of this document. There has been no change to any part of the specification for this chunk since version 19960914. In the previous version it was called spLT and the name has been changed to avoid confusion. It is proposed to register the chunk as sPLT and to include it in the "PNG extensions" document. The "signature" field and its null separator will not be included in the registered version of this chunk.

This chunk's contents are a zero-byte-terminated text string that names the palette, a zero-byte-terminated signature to identify the version, followed by a 4-byte gamma value, 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

20 bytes: signature ("PNG group 1996-09-14")
1 byte:   (null) separator

4 bytes:  (unsigned integer) gamma

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 gamma field. This length not divisible by ten is an error. Entries must appear in decreasing order of "frequency".

The "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 "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 gamma field gives the value of gamma, times 100000, that is associated with the palette entries.

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.

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 "bit depth rescaling" in the PNG specification.

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 spAL chunk is preferable, particularly when transparent pixels are present. When both the PLTE and spAL chunks are present, the PLTE data should only be used for decoding the indexed-color (color type 3) pixels, and the spAL data should be used for constructing the display palette. If the hIST chunk is also present, decoders that process the spAL 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 spAL chunks, with different names.

4.4. `srGB` Standard RGB profile

If the srGB chunk is present, the image conforms to the International Color Consortium's sRGB profile, and should be displayed using the specified rendering intent.

The format of this chunk has not changed since version 19960914 of this document. There has been no change to any part of the specification for this chunk since version 19961008. It is proposed to register this chunk using the name "sRGB" and to include the specification in the "PNG extensions" document. The "signature" field and its null separator will not be included in the registered version of this chunk.

An srGB chunk contains:

20 bytes: signature ("PNG group 1996-09-14")

1 byte: null separator

1 byte: Rendering intent
        0: Perceptual rendering intent
        1: Relative colorimetric rendering intent
        2: Saturation preserving rendering intent
        3: Absolute colorimetric rendering intent

If the srGB chunk is present, the image conforms to the transfer characteristic, chromaticities, illuminant, viewing flare, ambient illumination, and other properties as specified by the International Color Consortium [ICC] sRGB named profile described in [STOKES]. This means that the image was written by an ICC-sRGB-profile-aware application and if displayed by an ICC-sRGB-profile-aware application using the specified rendering intent, near-optimum rendering can be achieved within the physical limitations of the output device.

An application that creates the sRGB chunk must also create gAMA and cHRM chunks for compatibility with applications that do not recognize and process the srGB chunk. They must contain the following values:

gAMA:
   Image gamma:   45000

cHRM:
   White Point x: 31270
   White Point y: 32900
   Red x:         64000
   Red y:         33000
   Green x:       30000
   Green y:       60000
   Blue x:        15000
   Blue y:        06000

When the srGB chunk is present, applications that recognize the srGB chunk and are capable of processing the ICC sRGB profile should ignore the gAMA and cHRM chunks and process the srGB chunk instead, because this gives a more precise version of the same information.

Applications that recognize the srGB chunk but are not capable of processing the full sRGB profile data should also ignore the gAMA and cHRM chunks, since they already know the values that they should contain, and instead use the values of gAMA and cHRM given above as though they had appeared in gAMA and cHRM chunks. Using the sRGB values in preference to the gAMA/cHRM chunk data provides a measure of resiliency in case a non-sRGB-aware PNG editor erroneously changes gAMA or cHRM.

Only one instance of the srGB chunk is permitted in a PNG datastream, and if it appears, it must appear ahead of the IDAT chunk, and ahead of the PLTE chunk, if the PLTE chunk is present.

5. Chunks not described here

Additional chunks have been proposed for scientific visualization purposes. Since they are not expected to be implemented by general-purpose decoders, the are described separately in the PNG Scientific Visualization Chunks document [SCIVIS]. The proposed chunks described there are drNG/DrNG, faLT, loGE/LoGE, pCAL, tsCL, xsCL, ysCL, and zsCA.

6. Security considerations

Security considerations are addressed in the basic PNG specification,


http://www.w3.org/pub/WWW/TR/WD-png

The same precautions taken when displaying tEXt data should be taken when displaying the text contained in the "name" strings of the spAL chunk. Viewers should not display these strings directly without first checking for the presence of nonprintable characters, and for the <ESC> character in particular.

The fiNG fingerprint is trivial to forge. Be cautious when using a fingerprint chunk generated by someone else.

No known additional security hazards are posed by the chunks described here.