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/WD-png.
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 spLT chunk written according to the format given in Version 0.960406 of the PNG Proposed Chunks document.
Chunk name Multiple Ordering
OK? constraints
alIG No Before IDAT
fiNG No None
spLT Yes Before IDAT
The format of this chunk has not changed since version 0.960406 of this document.
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 pictureAll 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 = baselineIf 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 = 3/4 * height bottom = heightIf 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.
The format of this chunk has not changed since version 0.960710 of this document.
The fiNG chunk's contents are
fingerprint 16 bytesThe 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.
The format of this chunk has not changed since version 0.960406 of this document.
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:
name: n bytes (ASCII text)
null byte 1 byte (terminator)
red: 2 bytes (0 = black, 65535 = red)
green: 2 bytes (0 = black, 65535 = green)
blue: 2 bytes (0 = black, 65535 = blue)
alpha: 2 bytes (0 = fully transparent, 65535 = fully opaque)
frequency: 2 bytes (relative frequency of occurrence)
...
There can be any number of entries; a decoder determines the number of entries from the remaining chunk length after the null-terminated "name" string. This length not divisible by ten is an error. Entries must appear in decreasing order of "frequency".
The "name" (e.g. "rgba512 8-8-4-2 color cube", "rgb256 winter scenery", "rgb242 6-6-6 color cube plus 26 gray levels", "Windows white background", "50-color rgb palette for use with early versions of Mosaic") identifies the palette, which may permit applications or people to choose the appropriate one when more than one suggested palette appears in a PNG file. The "name" string must consist only of printable ASCII characters and may not have leading or trailing blanks, but may 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.
Note that the palette uses 16 bits (2 bytes) per value regardless of the image bit depth specification. Decoders wishing to construct 8-bit palettes can accomplish this by scaling down the RGB entries to 8 bits. [link to bit_depth rescaling].
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 may appear for any color type. If this chunk does appear, it must precede the first IDAT chunk. There may be multiple spLT chunks, with different names.
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 spLT 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.