[ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]
Alternate Formats: rfc2083.txt | rfc2083.txt.pdf
RFC 2083 - PNG (Portable Network Graphics) Specification Version 1.0
|
 |
|
Previous: RFC 2082 - RIP-2 MD5 Authentication |
Next: RFC 2084 - Considerations for Web Transaction Security |
RFC2083 - PNG (Portable Network Graphics) Specification Version
Network Working Group T. Boutell, et. al.
Request for Comments: 2083 Boutell.Com, Inc.
Category: Informational March 1997
PNG (Portable Network Graphics) Specification
Version 1.0
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
IESG Note:
The IESG takes no position on the validity of any Intellectual
Property Rights statements contained in this document.
Abstract
This document describes PNG (Portable Network Graphics), an
extensible file format for the lossless, portable, well-compressed
storage of raster images. PNG provides a patent-free replacement for
GIF and can also replace many common uses of TIFF. Indexed-color,
grayscale, and truecolor images are supported, plus an optional alpha
channel. Sample depths range from 1 to 16 bits.
PNG is designed to work well in online viewing applications, such as
the World Wide Web, so it is fully streamable with a progressive
display option. PNG is robust, providing both full file integrity
checking and simple detection of common transmission errors. Also,
PNG can store gamma and chromaticity data for improved color matching
on heterogeneous platforms.
This specification defines the Internet Media Type image/png.
Table of Contents
1. Introduction .................................................. 4
2. Data Representation ........................................... 5
2.1. Integers and byte order .................................. 5
2.2. Color values ............................................. 6
2.3. Image layout ............................................. 6
2.4. Alpha channel ............................................ 7
2.5. Filtering ................................................ 8
2.6. Interlaced data order .................................... 8
2.7. Gamma correction ......................................... 10
2.8. Text strings ............................................. 10
3. File Structure ................................................ 11
3.1. PNG file signature ....................................... 11
3.2. Chunk layout ............................................. 11
3.3. Chunk naming conventions ................................. 12
3.4. CRC algorithm ............................................ 15
4. Chunk Specifications .......................................... 15
4.1. Critical chunks .......................................... 15
4.1.1. IHDR Image header .................................. 15
4.1.2. PLTE Palette ....................................... 17
4.1.3. IDAT Image data .................................... 18
4.1.4. IEND Image trailer ................................. 19
4.2. Ancillary chunks ......................................... 19
4.2.1. bKGD Background color .............................. 19
4.2.2. cHRM Primary chromaticities and white point ........ 20
4.2.3. gAMA Image gamma ................................... 21
4.2.4. hIST Image histogram ............................... 21
4.2.5. pHYs Physical pixel dimensions ..................... 22
4.2.6. sBIT Significant bits .............................. 22
4.2.7. tEXt Textual data .................................. 24
4.2.8. tIME Image last-modification time .................. 25
4.2.9. tRNS Transparency .................................. 26
4.2.10. zTXt Compressed textual data ...................... 27
4.3. Summary of standard chunks ............................... 28
4.4. Additional chunk types ................................... 29
5. Deflate/Inflate Compression ................................... 29
6. Filter Algorithms ............................................. 31
6.1. Filter types ............................................. 31
6.2. Filter type 0: None ...................................... 32
6.3. Filter type 1: Sub ....................................... 33
6.4. Filter type 2: Up ........................................ 33
6.5. Filter type 3: Average ................................... 34
6.6. Filter type 4: Paeth...................................... 35
7. Chunk Ordering Rules .......................................... 36
7.1. Behavior of PNG editors .................................. 37
7.2. Ordering of ancillary chunks ............................. 38
7.3. Ordering of critical chunks .............................. 38
8. Miscellaneous Topics .......................................... 39
8.1. File name extension ...................................... 39
8.2. Internet media type ...................................... 39
8.3. Macintosh file layout .................................... 39
8.4. Multiple-image extension ................................. 39
8.5. Security considerations .................................. 40
9. Recommendations for Encoders .................................. 41
9.1. Sample depth scaling ..................................... 41
9.2. Encoder gamma handling ................................... 42
9.3. Encoder color handling ................................... 45
9.4. Alpha channel creation ................................... 47
9.5. Suggested palettes ....................................... 48
9.6. Filter selection ......................................... 49
9.7. Text chunk processing .................................... 49
9.8. Use of private chunks .................................... 50
9.9. Private type and method codes ............................ 51
10. Recommendations for Decoders ................................. 51
10.1. Error checking .......................................... 52
10.2. Pixel dimensions ........................................ 52
10.3. Truecolor image handling ................................ 52
10.4. Sample depth rescaling .................................. 53
10.5. Decoder gamma handling .................................. 54
10.6. Decoder color handling .................................. 56
10.7. Background color ........................................ 57
10.8. Alpha channel processing ................................ 58
10.9. Progressive display ..................................... 62
10.10. Suggested-palette and histogram usage .................. 63
10.11. Text chunk processing .................................. 64
11. Glossary ..................................................... 65
12. Appendix: Rationale .......................................... 69
12.1. Why a new file format? .................................. 69
12.2. Why these features? ..................................... 70
12.3. Why not these features? ................................. 70
12.4. Why not use format X? ................................... 72
12.5. Byte order .............................................. 73
12.6. Interlacing ............................................. 73
12.7. Why gamma? .............................................. 73
12.8. Non-premultiplied alpha ................................. 75
12.9. Filtering ............................................... 75
12.10. Text strings ........................................... 76
12.11. PNG file signature ..................................... 77
12.12. Chunk layout ........................................... 77
12.13. Chunk naming conventions ............................... 78
12.14. Palette histograms ..................................... 80
13. Appendix: Gamma Tutorial ..................................... 81
14. Appendix: Color Tutorial ..................................... 89
15. Appendix: Sample CRC Code .................................... 94
16. Appendix: Online Resources ................................... 96
17. Appendix: Revision History ................................... 96
18. References ................................................... 97
19. Credits ......................................................100
1. Introduction
The PNG format provides a portable, legally unencumbered, well-
compressed, well-specified standard for lossless bitmapped image
files.
Although the initial motivation for developing PNG was to replace
GIF, the design provides some useful new features not available in
GIF, with minimal cost to developers.
GIF features retained in PNG include:
* Indexed-color images of up to 256 colors.
* Streamability: files can be read and written serially, thus
allowing the file format to be used as a communications
protocol for on-the-fly generation and display of images.
* Progressive display: a suitably prepared image file can be
displayed as it is received over a communications link,
yielding a low-resolution image very quickly followed by
gradual improvement of detail.
* Transparency: portions of the image can be marked as
transparent, creating the effect of a non-rectangular image.
* Ancillary information: textual comments and other data can be
stored within the image file.
* Complete hardware and platform independence.
* Effective, 100% lossless compression.
Important new features of PNG, not available in GIF, include:
* Truecolor images of up to 48 bits per pixel.
* Grayscale images of up to 16 bits per pixel.
* Full alpha channel (general transparency masks).
* Image gamma information, which supports automatic display of
images with correct brightness/contrast regardless of the
machines used to originate and display the image.
* Reliable, straightforward detection of file corruption.
* Faster initial presentation in progressive display mode.
PNG is designed to be:
* Simple and portable: developers should be able to implement PNG
easily.
* Legally unencumbered: to the best knowledge of the PNG authors,
no algorithms under legal challenge are used. (Some
considerable effort has been spent to verify this.)
* Well compressed: both indexed-color and truecolor images are
compressed as effectively as in any other widely used lossless
format, and in most cases more effectively.
* Interchangeable: any standard-conforming PNG decoder must read
all conforming PNG files.
* Flexible: the format allows for future extensions and private
add-ons, without compromising interchangeability of basic PNG.
* Robust: the design supports full file integrity checking as
well as simple, quick detection of common transmission errors.
The main part of this specification gives the definition of the file
format and recommendations for encoder and decoder behavior. An
appendix gives the rationale for many design decisions. Although the
rationale is not part of the formal specification, reading it can
help implementors understand the design. Cross-references in the
main text point to relevant parts of the rationale. Additional
appendixes, also not part of the formal specification, provide
tutorials on gamma and color theory as well as other supporting
material.
In this specification, the word "must" indicates a mandatory
requirement, while "should" indicates recommended behavior.
See Rationale: Why a new file format? (Section 12.1), Why these
features? (Section 12.2), Why not these features? (Section 12.3), Why
not use format X? (Section 12.4).
Pronunciation
PNG is pronounced "ping".
2. Data Representation
This chapter discusses basic data representations used in PNG files,
as well as the expected representation of the image data.
2.1. Integers and byte order
All integers that require more than one byte must be in network
byte order: the most significant byte comes first, then the less
significant bytes in descending order of significance (MSB LSB for
two-byte integers, B3 B2 B1 B0 for four-byte integers). The
highest bit (value 128) of a byte is numbered bit 7; the lowest
bit (value 1) is numbered bit 0. Values are unsigned unless
otherwise noted. Values explicitly noted as signed are represented
in two's complement notation.
See Rationale: Byte order (Section 12.5).
2.2. Color values
Colors can be represented by either grayscale or RGB (red, green,
blue) sample data. Grayscale data represents luminance; RGB data
represents calibrated color information (if the cHRM chunk is
present) or uncalibrated device-dependent color (if cHRM is
absent). All color values range from zero (representing black) to
most intense at the maximum value for the sample depth. Note that
the maximum value at a given sample depth is (2^sampledepth)-1,
not 2^sampledepth.
Sample values are not necessarily linear; the gAMA chunk specifies
the gamma characteristic of the source device, and viewers are
strongly encouraged to compensate properly. See Gamma correction
(Section 2.7).
Source data with a precision not directly supported in PNG (for
example, 5 bit/sample truecolor) must be scaled up to the next
higher supported bit depth. This scaling is reversible with no
loss of data, and it reduces the number of cases that decoders
have to cope with. See Recommendations for Encoders: Sample depth
scaling (Section 9.1) and Recommendations for Decoders: Sample
depth rescaling (Section 10.4).
2.3. Image layout
Conceptually, a PNG image is a rectangular pixel array, with
pixels appearing left-to-right within each scanline, and scanlines
appearing top-to-bottom. (For progressive display purposes, the
data may actually be transmitted in a different order; see
Interlaced data order, Section 2.6.) The size of each pixel is
determined by the bit depth, which is the number of bits per
sample in the image data.
Three types of pixel are supported:
* An indexed-color pixel is represented by a single sample
that is an index into a supplied palette. The image bit
depth determines the maximum number of palette entries, but
not the color precision within the palette.
* A grayscale pixel is represented by a single sample that is
a grayscale level, where zero is black and the largest value
for the bit depth is white.
* A truecolor pixel is represented by three samples: red (zero
= black, max = red) appears first, then green (zero = black,
max = green), then blue (zero = black, max = blue). The bit
depth specifies the size of each sample, not the total pixel
size.
Optionally, grayscale and truecolor pixels can also include an
alpha sample, as described in the next section.
Pixels are always packed into scanlines with no wasted bits
between pixels. Pixels smaller than a byte never cross byte
boundaries; they are packed into bytes with the leftmost pixel in
the high-order bits of a byte, the rightmost in the low-order
bits. Permitted bit depths and pixel types are restricted so that
in all cases the packing is simple and efficient.
PNG permits multi-sample pixels only with 8- and 16-bit samples,
so multiple samples of a single pixel are never packed into one
byte. 16-bit samples are stored in network byte order (MSB
first).
Scanlines always begin on byte boundaries. When pixels have fewer
than 8 bits and the scanline width is not evenly divisible by the
number of pixels per byte, the low-order bits in the last byte of
each scanline are wasted. The contents of these wasted bits are
unspecified.
An additional "filter type" byte is added to the beginning of
every scanline (see Filtering, Section 2.5). The filter type byte
is not considered part of the image data, but it is included in
the datastream sent to the compression step.
2.4. Alpha channel
An alpha channel, representing transparency information on a per-
pixel basis, can be included in grayscale and truecolor PNG
images.
An alpha value of zero represents full transparency, and a value
of (2^bitdepth)-1 represents a fully opaque pixel. Intermediate
values indicate partially transparent pixels that can be combined
with a background image to yield a composite image. (Thus, alpha
is really the degree of opacity of the pixel. But most people
refer to alpha as providing transparency information, not opacity
information, and we continue that custom here.)
Alpha channels can be included with images that have either 8 or
16 bits per sample, but not with images that have fewer than 8
bits per sample. Alpha samples are represented with the same bit
depth used for the image samples. The alpha sample for each pixel
is stored immediately following the grayscale or RGB samples of
the pixel.
The color values stored for a pixel are not affected by the alpha
value assigned to the pixel. This rule is sometimes called
"unassociated" or "non-premultiplied" alpha. (Another common
technique is to store sample values premultiplied by the alpha
fraction; in effect, such an image is already composited against a
black background. PNG does not use premultiplied alpha.)
Transparency control is also possible without the storage cost of
a full alpha channel. In an indexed-color image, an alpha value
can be defined for each palette entry. In grayscale and truecolor
images, a single pixel value can be identified as being
"transparent". These techniques are controlled by the tRNS
ancillary chunk type.
If no alpha channel nor tRNS chunk is present, all pixels in the
image are to be treated as fully opaque.
Viewers can support transparency control partially, or not at all.
See Rationale: Non-premultiplied alpha (Section 12.8),
Recommendations for Encoders: Alpha channel creation (Section
9.4), and Recommendations for Decoders: Alpha channel processing
(Section 10.8).
2.5. Filtering
PNG allows the image data to be filtered before it is compressed.
Filtering can improve the compressibility of the data. The filter
step itself does not reduce the size of the data. All PNG filters
are strictly lossless.
PNG defines several different filter algorithms, including "None"
which indicates no filtering. The filter algorithm is specified
for each scanline by a filter type byte that precedes the filtered
scanline in the precompression datastream. An intelligent encoder
can switch filters from one scanline to the next. The method for
choosing which filter to employ is up to the encoder.
See Filter Algorithms (Chapter 6) and Rationale: Filtering
(Section 12.9).
2.6. Interlaced data order
A PNG image can be stored in interlaced order to allow progressive
display. The purpose of this feature is to allow images to "fade
in" when they are being displayed on-the-fly. Interlacing
slightly expands the file size on average, but it gives the user a
meaningful display much more rapidly. Note that decoders are
required to be able to read interlaced images, whether or not they
actually perform progressive display.
With interlace method 0, pixels are stored sequentially from left
to right, and scanlines sequentially from top to bottom (no
interlacing).
Interlace method 1, known as Adam7 after its author, Adam M.
Costello, consists of seven distinct passes over the image. Each
pass transmits a subset of the pixels in the image. The pass in
which each pixel is transmitted is defined by replicating the
following 8-by-8 pattern over the entire image, starting at the
upper left corner:
1 6 4 6 2 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7
3 6 4 6 3 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7
Within each pass, the selected pixels are transmitted left to
right within a scanline, and selected scanlines sequentially from
top to bottom. For example, pass 2 contains pixels 4, 12, 20,
etc. of scanlines 0, 8, 16, etc. (numbering from 0,0 at the upper
left corner). The last pass contains the entirety of scanlines 1,
3, 5, etc.
The data within each pass is laid out as though it were a complete
image of the appropriate dimensions. For example, if the complete
image is 16 by 16 pixels, then pass 3 will contain two scanlines,
each containing four pixels. When pixels have fewer than 8 bits,
each such scanline is padded as needed to fill an integral number
of bytes (see Image layout, Section 2.3). Filtering is done on
this reduced image in the usual way, and a filter type byte is
transmitted before each of its scanlines (see Filter Algorithms,
Chapter 6). Notice that the transmission order is defined so that
all the scanlines transmitted in a pass will have the same number
of pixels; this is necessary for proper application of some of the
filters.
Caution: If the image contains fewer than five columns or fewer
than five rows, some passes will be entirely empty. Encoders and
decoders must handle this case correctly. In particular, filter
type bytes are only associated with nonempty scanlines; no filter
type bytes are present in an empty pass.
See Rationale: Interlacing (Section 12.6) and Recommendations for
Decoders: Progressive display (Section 10.9).
2.7. Gamma correction
PNG images can specify, via the gAMA chunk, the gamma
characteristic of the image with respect to the original scene.
Display programs are strongly encouraged to use this information,
plus information about the display device they are using and room
lighting, to present the image to the viewer in a way that
reproduces what the image's original author saw as closely as
possible. See Gamma Tutorial (Chapter 13) if you aren't already
familiar with gamma issues.
Gamma correction is not applied to the alpha channel, if any.
Alpha samples always represent a linear fraction of full opacity.
For high-precision applications, the exact chromaticity of the RGB
data in a PNG image can be specified via the cHRM chunk, allowing
more accurate color matching than gamma correction alone will
provide. See Color Tutorial (Chapter 14) if you aren't already
familiar with color representation issues.
See Rationale: Why gamma? (Section 12.7), Recommendations for
Encoders: Encoder gamma handling (Section 9.2), and
Recommendations for Decoders: Decoder gamma handling (Section
10.5).
2.8. Text strings
A PNG file can store text associated with the image, such as an
image description or copyright notice. Keywords are used to
indicate what each text string represents.
ISO 8859-1 (Latin-1) is the character set recommended for use in
text strings [ISO-8859]. This character set is a superset of 7-
bit ASCII.
Character codes not defined in Latin-1 should not be used, because
they have no platform-independent meaning. If a non-Latin-1 code
does appear in a PNG text string, its interpretation will vary
across platforms and decoders. Some systems might not even be
able to display all the characters in Latin-1, but most modern
systems can.
Provision is also made for the storage of compressed text.
See Rationale: Text strings (Section 12.10).
3. File Structure
A PNG file consists of a PNG signature followed by a series of
chunks. This chapter defines the signature and the basic properties
of chunks. Individual chunk types are discussed in the next chapter.
3.1. PNG file signature
The first eight bytes of a PNG file always contain the following
(decimal) values:
137 80 78 71 13 10 26 10
This signature indicates that the remainder of the file contains a
single PNG image, consisting of a series of chunks beginning with
an IHDR chunk and ending with an IEND chunk.
See Rationale: PNG file signature (Section 12.11).
3.2. Chunk layout
Each chunk consists of four parts:
Length
A 4-byte unsigned integer giving the number of bytes in the
chunk's data field. The length counts only the data field, not
itself, the chunk type code, or the CRC. Zero is a valid
length. Although encoders and decoders should treat the length
as unsigned, its value must not exceed (2^31)-1 bytes.
Chunk Type
A 4-byte chunk type code. For convenience in description and
in examining PNG files, type codes are restricted to consist of
uppercase and lowercase ASCII letters (A-Z and a-z, or 65-90
and 97-122 decimal). However, encoders and decoders must treat
the codes as fixed binary values, not character strings. For
example, it would not be correct to represent the type code
IDAT by the EBCDIC equivalents of those letters. Additional
naming conventions for chunk types are discussed in the next
section.
Chunk Data
The data bytes appropriate to the chunk type, if any. This
field can be of zero length.
CRC
A 4-byte CRC (Cyclic Redundancy Check) calculated on the
preceding bytes in the chunk, including the chunk type code and
chunk data fields, but not including the length field. The CRC
is always present, even for chunks containing no data. See CRC
algorithm (Section 3.4).
The chunk data length can be any number of bytes up to the
maximum; therefore, implementors cannot assume that chunks are
aligned on any boundaries larger than bytes.
Chunks can appear in any order, subject to the restrictions placed
on each chunk type. (One notable restriction is that IHDR must
appear first and IEND must appear last; thus the IEND chunk serves
as an end-of-file marker.) Multiple chunks of the same type can
appear, but only if specifically permitted for that type.
See Rationale: Chunk layout (Section 12.12).
3.3. Chunk naming conventions
Chunk type codes are assigned so that a decoder can determine some
properties of a chunk even when it does not recognize the type
code. These rules are intended to allow safe, flexible extension
of the PNG format, by allowing a decoder to decide what to do when
it encounters an unknown chunk. The naming rules are not normally
of interest when the decoder does recognize the chunk's type.
Four bits of the type code, namely bit 5 (value 32) of each byte,
are used to convey chunk properties. This choice means that a
human can read off the assigned properties according to whether
each letter of the type code is uppercase (bit 5 is 0) or
lowercase (bit 5 is 1). However, decoders should test the
properties of an unknown chunk by numerically testing the
specified bits; testing whether a character is uppercase or
lowercase is inefficient, and even incorrect if a locale-specific
case definition is used.
It is worth noting that the property bits are an inherent part of
the chunk name, and hence are fixed for any chunk type. Thus,
TEXT and Text would be unrelated chunk type codes, not the same
chunk with different properties. Decoders must recognize type
codes by a simple four-byte literal comparison; it is incorrect to
perform case conversion on type codes.
The semantics of the property bits are:
Ancillary bit: bit 5 of first byte
0 (uppercase) = critical, 1 (lowercase) = ancillary.
Chunks that are not strictly necessary in order to meaningfully
display the contents of the file are known as "ancillary"
chunks. A decoder encountering an unknown chunk in which the
ancillary bit is 1 can safely ignore the chunk and proceed to
display the image. The time chunk (tIME) is an example of an
ancillary chunk.
Chunks that are necessary for successful display of the file's
contents are called "critical" chunks. A decoder encountering
an unknown chunk in which the ancillary bit is 0 must indicate
to the user that the image contains information it cannot
safely interpret. The image header chunk (IHDR) is an example
of a critical chunk.
Private bit: bit 5 of second byte
0 (uppercase) = public, 1 (lowercase) = private.
A public chunk is one that is part of the PNG specification or
is registered in the list of PNG special-purpose public chunk
types. Applications can also define private (unregistered)
chunks for their own purposes. The names of private chunks
must have a lowercase second letter, while public chunks will
always be assigned names with uppercase second letters. Note
that decoders do not need to test the private-chunk property
bit, since it has no functional significance; it is simply an
administrative convenience to ensure that public and private
chunk names will not conflict. See Additional chunk types
(Section 4.4) and Recommendations for Encoders: Use of private
chunks (Section 9.8).
Reserved bit: bit 5 of third byte
Must be 0 (uppercase) in files conforming to this version of
PNG.
The significance of the case of the third letter of the chunk
name is reserved for possible future expansion. At the present
time all chunk names must have uppercase third letters.
(Decoders should not complain about a lowercase third letter,
however, as some future version of the PNG specification could
define a meaning for this bit. It is sufficient to treat a
chunk with a lowercase third letter in the same way as any
other unknown chunk type.)
Safe-to-copy bit: bit 5 of fourth byte
0 (uppercase) = unsafe to copy, 1 (lowercase) = safe to copy.
This property bit is not of interest to pure decoders, but it
is needed by PNG editors (programs that modify PNG files).
This bit defines the proper handling of unrecognized chunks in
a file that is being modified.
If a chunk's safe-to-copy bit is 1, the chunk may be copied to
a modified PNG file whether or not the software recognizes the
chunk type, and regardless of the extent of the file
modifications.
If a chunk's safe-to-copy bit is 0, it indicates that the chunk
depends on the image data. If the program has made any changes
to critical chunks, including addition, modification, deletion,
or reordering of critical chunks, then unrecognized unsafe
chunks must not be copied to the output PNG file. (Of course,
if the program does recognize the chunk, it can choose to
output an appropriately modified version.)
A PNG editor is always allowed to copy all unrecognized chunks
if it has only added, deleted, modified, or reordered ancillary
chunks. This implies that it is not permissible for ancillary
chunks to depend on other ancillary chunks.
PNG editors that do not recognize a critical chunk must report
an error and refuse to process that PNG file at all. The
safe/unsafe mechanism is intended for use with ancillary
chunks. The safe-to-copy bit will always be 0 for critical
chunks.
Rules for PNG editors are discussed further in Chunk Ordering
Rules (Chapter 7).
For example, the hypothetical chunk type name "bLOb" has the
property bits:
bLOb <-- 32 bit chunk type code represented in text form
||||
|||+- Safe-to-copy bit is 1 (lower case letter; bit 5 is 1)
||+-- Reserved bit is 0 (upper case letter; bit 5 is 0)
|+--- Private bit is 0 (upper case letter; bit 5 is 0)
+---- Ancillary bit is 1 (lower case letter; bit 5 is 1)
Therefore, this name represents an ancillary, public, safe-to-copy
chunk.
See Rationale: Chunk naming conventions (Section 12.13).
3.4. CRC algorithm
Chunk CRCs are calculated using standard CRC methods with pre and
post conditioning, as defined by ISO 3309 [ISO-3309] or ITU-T V.42
[ITU-V42]. The CRC polynomial employed is
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1
The 32-bit CRC register is initialized to all 1's, and then the
data from each byte is processed from the least significant bit
(1) to the most significant bit (128). After all the data bytes
are processed, the CRC register is inverted (its ones complement
is taken). This value is transmitted (stored in the file) MSB
first. For the purpose of separating into bytes and ordering, the
least significant bit of the 32-bit CRC is defined to be the
coefficient of the x^31 term.
Practical calculation of the CRC always employs a precalculated
table to greatly accelerate the computation. See Sample CRC Code
(Chapter 15).
4. Chunk Specifications
This chapter defines the standard types of PNG chunks.
4.1. Critical chunks
All implementations must understand and successfully render the
standard critical chunks. A valid PNG image must contain an IHDR
chunk, one or more IDAT chunks, and an IEND chunk.
4.1.1. IHDR Image header
The IHDR chunk must appear FIRST. It contains:
Width: 4 bytes
Height: 4 bytes
Bit depth: 1 byte
Color type: 1 byte
Compression method: 1 byte
Filter method: 1 byte
Interlace method: 1 byte
Width and height give the image dimensions in pixels. They are
4-byte integers. Zero is an invalid value. The maximum for each
is (2^31)-1 in order to accommodate languages that have
difficulty with unsigned 4-byte values.
Bit depth is a single-byte integer giving the number of bits
per sample or per palette index (not per pixel). Valid values
are 1, 2, 4, 8, and 16, although not all values are allowed for
all color types.
Color type is a single-byte integer that describes the
interpretation of the image data. Color type codes represent
sums of the following values: 1 (palette used), 2 (color used),
and 4 (alpha channel used). Valid values are 0, 2, 3, 4, and 6.
Bit depth restrictions for each color type are imposed to
simplify implementations and to prohibit combinations that do
not compress well. Decoders must support all legal
combinations of bit depth and color type. The allowed
combinations are:
Color Allowed Interpretation
Type Bit Depths
0 1,2,4,8,16 Each pixel is a grayscale sample.
2 8,16 Each pixel is an R,G,B triple.
3 1,2,4,8 Each pixel is a palette index;
a PLTE chunk must appear.
4 8,16 Each pixel is a grayscale sample,
followed by an alpha sample.
6 8,16 Each pixel is an R,G,B triple,
followed by an alpha sample.
The sample depth is the same as the bit depth except in the
case of color type 3, in which the sample depth is always 8
bits.
Compression method is a single-byte integer that indicates the
method used to compress the image data. At present, only
compression method 0 (deflate/inflate compression with a 32K
sliding window) is defined. All standard PNG images must be
compressed with this scheme. The compression method field is
provided for possible future expansion or proprietary variants.
Decoders must check this byte and report an error if it holds
an unrecognized code. See Deflate/Inflate Compression (Chapter
5) for details.
Filter method is a single-byte integer that indicates the
preprocessing method applied to the image data before
compression. At present, only filter method 0 (adaptive
filtering with five basic filter types) is defined. As with
the compression method field, decoders must check this byte and
report an error if it holds an unrecognized code. See Filter
Algorithms (Chapter 6) for details.
Interlace method is a single-byte integer that indicates the
transmission order of the image data. Two values are currently
defined: 0 (no interlace) or 1 (Adam7 interlace). See
Interlaced data order (Section 2.6) for details.
4.1.2. PLTE Palette
The PLTE chunk contains from 1 to 256 palette entries, each a
three-byte series of the form:
Red: 1 byte (0 = black, 255 = red)
Green: 1 byte (0 = black, 255 = green)
Blue: 1 byte (0 = black, 255 = blue)
The number of entries is determined from the chunk length. A
chunk length not divisible by 3 is an error.
This chunk must appear for color type 3, and can appear for
color types 2 and 6; it must not appear for color types 0 and
4. If this chunk does appear, it must precede the first IDAT
chunk. There must not be more than one PLTE chunk.
For color type 3 (indexed color), the PLTE chunk is required.
The first entry in PLTE is referenced by pixel value 0, the
second by pixel value 1, etc. The number of palette entries
must not exceed the range that can be represented in the image
bit depth (for example, 2^4 = 16 for a bit depth of 4). It is
permissible to have fewer entries than the bit depth would
allow. In that case, any out-of-range pixel value found in the
image data is an error.
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, 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.)
Note that the palette uses 8 bits (1 byte) per sample
regardless of the image bit depth specification. In
particular, the palette is 8 bits deep even when it is a
suggested quantization of a 16-bit truecolor image.
There is no requirement that the palette entries all be used by
the image, nor that they all be different.
4.1.3. IDAT Image data
The IDAT chunk contains the actual image data. To create this
data:
* Begin with image scanlines represented as described in
Image layout (Section 2.3); the layout and total size of
this raw data are determined by the fields of IHDR.
* Filter the image data according to the filtering method
specified by the IHDR chunk. (Note that with filter
method 0, the only one currently defined, this implies
prepending a filter type byte to each scanline.)
* Compress the filtered data using the compression method
specified by the IHDR chunk.
The IDAT chunk contains the output datastream of the
compression algorithm.
To read the image data, reverse this process.
There can be multiple IDAT chunks; if so, they must appear
consecutively with no other intervening chunks. The compressed
datastream is then the concatenation of the contents of all the
IDAT chunks. The encoder can divide the compressed datastream
into IDAT chunks however it wishes. (Multiple IDAT chunks are
allowed so that encoders can work in a fixed amount of memory;
typically the chunk size will correspond to the encoder's
buffer size.) It is important to emphasize that IDAT chunk
boundaries have no semantic significance and can occur at any
point in the compressed datastream. A PNG file in which each
IDAT chunk contains only one data byte is legal, though
remarkably wasteful of space. (For that matter, zero-length
IDAT chunks are legal, though even more wasteful.)
See Filter Algorithms (Chapter 6) and Deflate/Inflate
Compression (Chapter 5) for details.
4.1.4. IEND Image trailer
The IEND chunk must appear LAST. It marks the end of the PNG
datastream. The chunk's data field is empty.
4.2. Ancillary chunks
All ancillary chunks are optional, in the sense that encoders need
not write them and decoders can ignore them. However, encoders
are encouraged to write the standard ancillary chunks when the
information is available, and decoders are encouraged to interpret
these chunks when appropriate and feasible.
The standard ancillary chunks are listed in alphabetical order.
This is not necessarily the order in which they would appear in a
file.
4.2.1. bKGD Background color
The bKGD chunk specifies a default background color to present
the image against. Note that viewers are not bound to honor
this chunk; a viewer can choose to use a different background.
For color type 3 (indexed color), the bKGD chunk contains:
Palette index: 1 byte
The value is the palette index of the color to be used as
background.
For color types 0 and 4 (grayscale, with or without alpha),
bKGD contains:
Gray: 2 bytes, range 0 .. (2^bitdepth)-1
(For consistency, 2 bytes are used regardless of the image bit
depth.) The value is the gray level to be used as background.
For color types 2 and 6 (truecolor, with or without alpha),
bKGD contains:
Red: 2 bytes, range 0 .. (2^bitdepth)-1
Green: 2 bytes, range 0 .. (2^bitdepth)-1
Blue: 2 bytes, range 0 .. (2^bitdepth)-1
(For consistency, 2 bytes per sample are used regardless of the
image bit depth.) This is the RGB color to be used as
background.
When present, the bKGD chunk must precede the first IDAT chunk,
and must follow the PLTE chunk, if any.
See Recommendations for Decoders: Background color (Section
10.7).
4.2.2. cHRM Primary chromaticities and white point
Applications that need device-independent specification of
colors in a PNG file can use the cHRM chunk to specify the 1931
CIE x,y chromaticities of the red, green, and blue primaries
used in the image, and the referenced white point. See Color
Tutorial (Chapter 14) for more information.
The cHRM chunk contains:
White Point x: 4 bytes
White Point y: 4 bytes
Red x: 4 bytes
Red y: 4 bytes
Green x: 4 bytes
Green y: 4 bytes
Blue x: 4 bytes
Blue y: 4 bytes
Each value is encoded as a 4-byte unsigned integer,
representing the x or y value times 100000. For example, a
value of 0.3127 would be stored as the integer 31270.
cHRM is allowed in all PNG files, although it is of little
value for grayscale images.
If the encoder does not know the chromaticity values, it should
not write a cHRM chunk; the absence of a cHRM chunk indicates
that the image's primary colors are device-dependent.
If the cHRM chunk appears, it must precede the first IDAT
chunk, and it must also precede the PLTE chunk if present.
See Recommendations for Encoders: Encoder color handling
(Section 9.3), and Recommendations for Decoders: Decoder color
handling (Section 10.6).
4.2.3. gAMA Image gamma
The gAMA chunk specifies the gamma of the camera (or simulated
camera) that produced the image, and thus the gamma of the
image with respect to the original scene. More precisely, the
gAMA chunk encodes the file_gamma value, as defined in Gamma
Tutorial (Chapter 13).
The gAMA chunk contains:
Image gamma: 4 bytes
The value is encoded as a 4-byte unsigned integer, representing
gamma times 100000. For example, a gamma of 0.45 would be
stored as the integer 45000.
If the encoder does not know the image's gamma value, it should
not write a gAMA chunk; the absence of a gAMA chunk indicates
that the gamma is unknown.
If the gAMA chunk appears, it must precede the first IDAT
chunk, and it must also precede the PLTE chunk if present.
See Gamma correction (Section 2.7), Recommendations for
Encoders: Encoder gamma handling (Section 9.2), and
Recommendations for Decoders: Decoder gamma handling (Section
10.5).
4.2.4. hIST Image 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. 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.
The hIST chunk contains a series of 2-byte (16 bit) unsigned
integers. There must be exactly one entry for each entry in
the PLTE chunk. Each entry is proportional to the fraction of
pixels in the image that have that palette index; the exact
scale factor is chosen by the encoder.
Histogram entries are approximate, with the exception that a
zero entry specifies that the corresponding palette entry is
not used at all in the image. It is required that a histogram
entry be nonzero if there are any pixels of that color.
When the palette is a suggested quantization of a truecolor
image, the histogram is necessarily approximate, since a
decoder may map pixels to palette entries differently than the
encoder did. In this situation, zero entries should not
appear.
The hIST chunk, if it appears, must follow the PLTE chunk, and
must precede the first IDAT chunk.
See Rationale: Palette histograms (Section 12.14), and
Recommendations for Decoders: Suggested-palette and histogram
usage (Section 10.10).
4.2.5. pHYs Physical pixel dimensions
The pHYs chunk specifies the intended pixel size or aspect
ratio for display of the image. It contains:
Pixels per unit, X axis: 4 bytes (unsigned integer)
Pixels per unit, Y axis: 4 bytes (unsigned integer)
Unit specifier: 1 byte
The following values are legal for the unit specifier:
0: unit is unknown
1: unit is the meter
When the unit specifier is 0, the pHYs chunk defines pixel
aspect ratio only; the actual size of the pixels remains
unspecified.
Conversion note: one inch is equal to exactly 0.0254 meters.
If this ancillary chunk is not present, pixels are assumed to
be square, and the physical size of each pixel is unknown.
If present, this chunk must precede the first IDAT chunk.
See Recommendations for Decoders: Pixel dimensions (Section
10.2).
4.2.6. sBIT Significant bits
To simplify decoders, PNG specifies that only certain sample
depths can be used, and further specifies that sample values
should be scaled to the full range of possible values at the
sample depth. However, the sBIT chunk is provided in order to
store the original number of significant bits. This allows
decoders to recover the original data losslessly even if the
data had a sample depth not directly supported by PNG. We
recommend that an encoder emit an sBIT chunk if it has
converted the data from a lower sample depth.
For color type 0 (grayscale), the sBIT chunk contains a single
byte, indicating the number of bits that were significant in
the source data.
For color type 2 (truecolor), the sBIT chunk contains three
bytes, indicating the number of bits that were significant in
the source data for the red, green, and blue channels,
respectively.
For color type 3 (indexed color), the sBIT chunk contains three
bytes, indicating the number of bits that were significant in
the source data for the red, green, and blue components of the
palette entries, respectively.
For color type 4 (grayscale with alpha channel), the sBIT chunk
contains two bytes, indicating the number of bits that were
significant in the source grayscale data and the source alpha
data, respectively.
For color type 6 (truecolor with alpha channel), the sBIT chunk
contains four bytes, indicating the number of bits that were
significant in the source data for the red, green, blue and
alpha channels, respectively.
Each depth specified in sBIT must be greater than zero and less
than or equal to the sample depth (which is 8 for indexed-color
images, and the bit depth given in IHDR for other color types).
A decoder need not pay attention to sBIT: the stored image is a
valid PNG file of the sample depth indicated by IHDR. However,
if the decoder wishes to recover the original data at its
original precision, this can be done by right-shifting the
stored samples (the stored palette entries, for an indexed-
color image). The encoder must scale the data in such a way
that the high-order bits match the original data.
If the sBIT chunk appears, it must precede the first IDAT
chunk, and it must also precede the PLTE chunk if present.
See Recommendations for Encoders: Sample depth scaling (Section
9.1) and Recommendations for Decoders: Sample depth rescaling
(Section 10.4).
4.2.7. tEXt Textual data
Textual information that the encoder wishes to record with the
image can be stored in tEXt chunks. Each tEXt chunk contains a
keyword and a text string, in the format:
Keyword: 1-79 bytes (character string)
Null separator: 1 byte
Text: n bytes (character string)
The keyword and text string are separated by a zero byte (null
character). Neither the keyword nor the text string can
contain a null character. Note that the text string is not
null-terminated (the length of the chunk is sufficient
information to locate the ending). The keyword must be at
least one character and less than 80 characters long. The text
string can be of any length from zero bytes up to the maximum
permissible chunk size less the length of the keyword and
separator.
Any number of tEXt chunks can appear, and more than one with
the same keyword is permissible.
The keyword indicates the type of information represented by
the text string. The following keywords are predefined and
should be used where appropriate:
Title Short (one line) title or caption for image
Author Name of image's creator
Description Description of image (possibly long)
Copyright Copyright notice
Creation Time Time of original image creation
Software Software used to create the image
Disclaimer Legal disclaimer
Warning Warning of nature of content
Source Device used to create the image
Comment Miscellaneous comment; conversion from
GIF comment
For the Creation Time keyword, the date format defined in
section 5.2.14 of RFC 1123 is suggested, but not required
[RFC-1123]. Decoders should allow for free-format text
associated with this or any other keyword.
Other keywords may be invented for other purposes. Keywords of
general interest can be registered with the maintainers of the
PNG specification. However, it is also permitted to use
private unregistered keywords. (Private keywords should be
reasonably self-explanatory, in order to minimize the chance
that the same keyword will be used for incompatible purposes by
different people.)
Both keyword and text are interpreted according to the ISO
8859-1 (Latin-1) character set [ISO-8859]. The text string can
contain any Latin-1 character. Newlines in the text string
should be represented by a single linefeed character (decimal
10); use of other control characters in the text is
discouraged.
Keywords must contain only printable Latin-1 characters and
spaces; that is, only character codes 32-126 and 161-255
decimal are allowed. To reduce the chances for human
misreading of a keyword, leading and trailing spaces are
forbidden, as are consecutive spaces. Note also that the non-
breaking space (code 160) is not permitted in keywords, since
it is visually indistinguishable from an ordinary space.
Keywords must be spelled exactly as registered, so that
decoders can use simple literal comparisons when looking for
particular keywords. In particular, keywords are considered
case-sensitive.
See Recommendations for Encoders: Text chunk processing
(Section 9.7) and Recommendations for Decoders: Text chunk
processing (Section 10.11).
4.2.8. tIME Image last-modification time
The tIME chunk gives the time of the last image modification
(not the time of initial image creation). It contains:
Year: 2 bytes (complete; for example, 1995, not 95)
Month: 1 byte (1-12)
Day: 1 byte (1-31)
Hour: 1 byte (0-23)
Minute: 1 byte (0-59)
Second: 1 byte (0-60) (yes, 60, for leap seconds; not 61,
a common error)
Universal Time (UTC, also called GMT) should be specified
rather than local time.
The tIME chunk is intended for use as an automatically-applied
time stamp that is updated whenever the image data is changed.
It is recommended that tIME not be changed by PNG editors that
do not change the image data. See also the Creation Time tEXt
keyword, which can be used for a user-supplied time.
4.2.9. tRNS Transparency
The tRNS chunk specifies that the image uses simple
transparency: either alpha values associated with palette
entries (for indexed-color images) or a single transparent
color (for grayscale and truecolor images). Although simple
transparency is not as elegant as the full alpha channel, it
requires less storage space and is sufficient for many common
cases.
For color type 3 (indexed color), the tRNS chunk contains a
series of one-byte alpha values, corresponding to entries in
the PLTE chunk:
Alpha for palette index 0: 1 byte
Alpha for palette index 1: 1 byte
... etc ...
Each entry indicates that pixels of the corresponding palette
index must be treated as having the specified alpha value.
Alpha values have the same interpretation as in an 8-bit full
alpha channel: 0 is fully transparent, 255 is fully opaque,
regardless of image bit depth. The tRNS chunk must not contain
more alpha values than there are palette entries, but tRNS can
contain fewer values than there are palette entries. In this
case, the alpha value for all remaining palette entries is
assumed to be 255. In the common case in which only palette
index 0 need be made transparent, only a one-byte tRNS chunk is
needed.
For color type 0 (grayscale), the tRNS chunk contains a single
gray level value, stored in the format:
Gray: 2 bytes, range 0 .. (2^bitdepth)-1
(For consistency, 2 bytes are used regardless of the image bit
depth.) Pixels of the specified gray level are to be treated as
transparent (equivalent to alpha value 0); all other pixels are
to be treated as fully opaque (alpha value (2^bitdepth)-1).
For color type 2 (truecolor), the tRNS chunk contains a single
RGB color value, stored in the format:
Red: 2 bytes, range 0 .. (2^bitdepth)-1
Green: 2 bytes, range 0 .. (2^bitdepth)-1
Blue: 2 bytes, range 0 .. (2^bitdepth)-1
(For consistency, 2 bytes per sample are used regardless of the
image bit depth.) Pixels of the specified color value are to be
treated as transparent (equivalent to alpha value 0); all other
pixels are to be treated as fully opaque (alpha value
(2^bitdepth)-1).
tRNS is prohibited for color types 4 and 6, since a full alpha
channel is already present in those cases.
Note: when dealing with 16-bit grayscale or truecolor data, it
is important to compare both bytes of the sample values to
determine whether a pixel is transparent. Although decoders
may drop the low-order byte of the samples for display, this
must not occur until after the data has been tested for
transparency. For example, if the grayscale level 0x0001 is
specified to be transparent, it would be incorrect to compare
only the high-order byte and decide that 0x0002 is also
transparent.
When present, the tRNS chunk must precede the first IDAT chunk,
and must follow the PLTE chunk, if any.
4.2.10. zTXt Compressed textual data
The zTXt chunk contains textual data, just as tEXt does;
however, zTXt takes advantage of compression. zTXt and tEXt
chunks are semantically equivalent, but zTXt is recommended for
storing large blocks of text.
A zTXt chunk contains:
Keyword: 1-79 bytes (character string)
Null separator: 1 byte
Compression method: 1 byte
Compressed text: n bytes
The keyword and null separator are exactly the same as in the
tEXt chunk. Note that the keyword is not compressed. The
compression method byte identifies the compression method used
in this zTXt chunk. The only value presently defined for it is
0 (deflate/inflate compression). The compression method byte is
followed by a compressed datastream that makes up the remainder
of the chunk. For compression method 0, this datastream
adheres to the zlib datastream format (see Deflate/Inflate
Compression, Chapter 5). Decompression of this datastream
yields Latin-1 text that is identical to the text that would be
stored in an equivalent tEXt chunk.
Any number of zTXt and tEXt chunks can appear in the same file.
See the preceding definition of the tEXt chunk for the
predefined keywords and the recommended format of the text.
See Recommendations for Encoders: Text chunk processing
(Section 9.7), and Recommendations for Decoders: Text chunk
processing (Section 10.11).
4.3. Summary of standard chunks
This table summarizes some properties of the standard chunk types.
Critical chunks (must appear in this order, except PLTE
is optional):
Name Multiple Ordering constraints
OK?
IHDR No Must be first
PLTE No Before IDAT
IDAT Yes Multiple IDATs must be consecutive
IEND No Must be last
Ancillary chunks (need not appear in this order):
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
tIME No None
tEXt Yes None
zTXt Yes None
Standard keywords for tEXt and zTXt chunks:
Title Short (one line) title or caption for image
Author Name of image's creator
Description Description of image (possibly long)
Copyright Copyright notice
Creation Time Time of original image creation
Software Software used to create the image
Disclaimer Legal disclaimer
Warning Warning of nature of content
Source Device used to create the image
Comment Miscellaneous comment; conversion from
GIF comment
4.4. Additional chunk types
Additional public PNG chunk types are defined in the document "PNG
Special-Purpose Public Chunks" [PNG-EXTENSIONS]. Chunks described
there are expected to be less widely supported than those defined
in this specification. However, application authors are
encouraged to use those chunk types whenever appropriate for their
applications. Additional chunk types can be proposed for
inclusion in that list by contacting the PNG specification
maintainers at png-info@uunet.uu.net or at png-group@w3.org.
New public chunks will only be registered if they are of use to
others and do not violate the design philosophy of PNG. Chunk
registration is not automatic, although it is the intent of the
authors that it be straightforward when a new chunk of potentially
wide application is needed. Note that the creation of new
critical chunk types is discouraged unless absolutely necessary.
Applications can also use private chunk types to carry data that
is not of interest to other applications. See Recommendations for
Encoders: Use of private chunks (Section 9.8).
Decoders must be prepared to encounter unrecognized public or
private chunk type codes. Unrecognized chunk types must be
handled as described in Chunk naming conventions (Section 3.3).
5. Deflate/Inflate Compression
PNG compression method 0 (the only compression method presently
defined for PNG) specifies deflate/inflate compression with a 32K
sliding window. Deflate compression is an LZ77 derivative used in
zip, gzip, pkzip and related programs. Extensive research has been
done supporting its patent-free status. Portable C implementations
are freely available.
Deflate-compressed datastreams within PNG are stored in the "zlib"
format, which has the structure:
Compression method/flags code: 1 byte
Additional flags/check bits: 1 byte
Compressed data blocks: n bytes
Check value: 4 bytes
Further details on this format are given in the zlib specification
[RFC-1950].
For PNG compression method 0, the zlib compression method/flags code
must specify method code 8 ("deflate" compression) and an LZ77 window
size of not more than 32K. Note that the zlib compression method
number is not the same as the PNG compression method number. The
additional flags must not specify a preset dictionary.
The compressed data within the zlib datastream is stored as a series
of blocks, each of which can represent raw (uncompressed) data,
LZ77-compressed data encoded with fixed Huffman codes, or LZ77-
compressed data encoded with custom Huffman codes. A marker bit in
the final block identifies it as the last block, allowing the decoder
to recognize the end of the compressed datastream. Further details
on the compression algorithm and the encoding are given in the
deflate specification [RFC-1951].
The check value stored at the end of the zlib datastream is
calculated on the uncompressed data represented by the datastream.
Note that the algorithm used is not the same as the CRC calculation
used for PNG chunk check values. The zlib check value is useful
mainly as a cross-check that the deflate and inflate algorithms are
implemented correctly. Verifying the chunk CRCs provides adequate
confidence that the PNG file has been transmitted undamaged.
In a PNG file, the concatenation of the contents of all the IDAT
chunks makes up a zlib datastream as specified above. This
datastream decompresses to filtered image data as described elsewhere
in this document.
It is important to emphasize that the boundaries between IDAT chunks
are arbitrary and can fall anywhere in the zlib datastream. There is
not necessarily any correlation between IDAT chunk boundaries and
deflate block boundaries or any other feature of the zlib data. For
example, it is entirely possible for the terminating zlib check value
to be split across IDAT chunks.
In the same vein, there is no required correlation between the
structure of the image data (i.e., scanline boundaries) and deflate
block boundaries or IDAT chunk boundaries. The complete image data
is represented by a single zlib datastream that is stored in some
number of IDAT chunks; a decoder that assumes any more than this is
incorrect. (Of course, some encoder implementations may emit files
in which some of these structures are indeed related. But decoders
cannot rely on this.)
PNG also uses zlib datastreams in zTXt chunks. In a zTXt chunk, the
remainder of the chunk following the compression method byte is a
zlib datastream as specified above. This datastream decompresses to
the user-readable text described by the chunk's keyword. Unlike the
image data, such datastreams are not split across chunks; each zTXt
chunk contains an independent zlib datastream.
Additional documentation and portable C code for deflate and inflate
are available from the Info-ZIP archives at
<URL:ftp://ftp.uu.net/pub/archiving/zip/>.
6. Filter Algorithms
This chapter describes the filter algorithms that can be applied
before compression. The purpose of these filters is to prepare the
image data for optimum compression.
6.1. Filter types
PNG filter method 0 defines five basic filter types:
Type Name
0 None
1 Sub
2 Up
3 Average
4 Paeth
(Note that filter method 0 in IHDR specifies exactly this set of
five filter types. If the set of filter types is ever extended, a
different filter method number will be assigned to the extended
set, so that decoders need not decompress the data to discover
that it contains unsupported filter types.)
The encoder can choose which of these filter algorithms to apply
on a scanline-by-scanline basis. In the image data sent to the
compression step, each scanline is preceded by a filter type byte
that specifies the filter algorithm used for that scanline.
Filtering algorithms are applied to bytes, not to pixels,
regardless of the bit depth or color type of the image. The
filtering algorithms work on the byte sequence formed by a
scanline that has been represented as described in Image layout
(Section 2.3). If the image includes an alpha channel, the alpha
data is filtered in the same way as the image data.
When the image is interlaced, each pass of the interlace pattern
is treated as an independent image for filtering purposes. The
filters work on the byte sequences formed by the pixels actually
transmitted during a pass, and the "previous scanline" is the one
previously transmitted in the same pass, not the one adjacent in
the complete image. Note that the subimage transmitted in any one
pass is always rectangular, but is of smaller width and/or height
than the complete image. Filtering is not applied when this
subimage is empty.
For all filters, the bytes "to the left of" the first pixel in a
scanline must be treated as being zero. For filters that refer to
the prior scanline, the entire prior scanline must be treated as
being zeroes for the first scanline of an image (or of a pass of
an interlaced image).
To reverse the effect of a filter, the decoder must use the
decoded values of the prior pixel on the same line, the pixel
immediately above the current pixel on the prior line, and the
pixel just to the left of the pixel above. This implies that at
least one scanline's worth of image data will have to be stored by
the decoder at all times. Even though some filter types do not
refer to the prior scanline, the decoder will always need to store
each scanline as it is decoded, since the next scanline might use
a filter that refers to it.
PNG imposes no restriction on which filter types can be applied to
an image. However, the filters are not equally effective on all
types of data. See Recommendations for Encoders: Filter selection
(Section 9.6).
See also Rationale: Filtering (Section 12.9).
6.2. Filter type 0: None
With the None filter, the scanline is transmitted unmodified; it
is only necessary to insert a filter type byte before the data.
6.3. Filter type 1: Sub
The Sub filter transmits the difference between each byte and the
value of the corresponding byte of the prior pixel.
To compute the Sub filter, apply the following formula to each
byte of the scanline:
Sub(x) = Raw(x) - Raw(x-bpp)
where x ranges from zero to the number of bytes representing the
scanline minus one, Raw(x) refers to the raw data byte at that
byte position in the scanline, and bpp is defined as the number of
bytes per complete pixel, rounding up to one. For example, for
color type 2 with a bit depth of 16, bpp is equal to 6 (three
samples, two bytes per sample); for color type 0 with a bit depth
of 2, bpp is equal to 1 (rounding up); for color type 4 with a bit
depth of 16, bpp is equal to 4 (two-byte grayscale sample, plus
two-byte alpha sample).
Note this computation is done for each byte, regardless of bit
depth. In a 16-bit image, each MSB is predicted from the
preceding MSB and each LSB from the preceding LSB, because of the
way that bpp is defined.
Unsigned arithmetic modulo 256 is used, so that both the inputs
and outputs fit into bytes. The sequence of Sub values is
transmitted as the filtered scanline.
For all x < 0, assume Raw(x) = 0.
To reverse the effect of the Sub filter after decompression,
output the following value:
Sub(x) + Raw(x-bpp)
(computed mod 256), where Raw refers to the bytes already decoded.
6.4. Filter type 2: Up
The Up filter is just like the Sub filter except that the pixel
immediately above the current pixel, rather than just to its left,
is used as the predictor.
To compute the Up filter, apply the following formula to each byte
of the scanline:
Up(x) = Raw(x) - Prior(x)
where x ranges from zero to the number of bytes representing the
scanline minus one, Raw(x) refers to the raw data byte at that
byte position in the scanline, and Prior(x) refers to the
unfiltered bytes of the prior scanline.
Note this is done for each byte, regardless of bit depth.
Unsigned arithmetic modulo 256 is used, so that both the inputs
and outputs fit into bytes. The sequence of Up values is
transmitted as the filtered scanline.
On the first scanline of an image (or of a pass of an interlaced
image), assume Prior(x) = 0 for all x.
To reverse the effect of the Up filter after decompression, output
the following value:
Up(x) + Prior(x)
(computed mod 256), where Prior refers to the decoded bytes of the
prior scanline.
6.5. Filter type 3: Average
The Average filter uses the average of the two neighboring pixels
(left and above) to predict the value of a pixel.
To compute the Average filter, apply the following formula to each
byte of the scanline:
Average(x) = Raw(x) - floor((Raw(x-bpp)+Prior(x))/2)
where x ranges from zero to the number of bytes representing the
scanline minus one, Raw(x) refers to the raw data byte at that
byte position in the scanline, Prior(x) refers to the unfiltered
bytes of the prior scanline, and bpp is defined as for the Sub
filter.
Note this is done for each byte, regardless of bit depth. The
sequence of Average values is transmitted as the filtered
scanline.
The subtraction of the predicted value from the raw byte must be
done modulo 256, so that both the inputs and outputs fit into
bytes. However, the sum Raw(x-bpp)+Prior(x) must be formed
without overflow (using at least nine-bit arithmetic). floor()
indicates that the result of the division is rounded to the next
lower integer if fractional; in other words, it is an integer
division or right shift operation.
For all x < 0, assume Raw(x) = 0. On the first scanline of an
image (or of a pass of an interlaced image), assume Prior(x) = 0
for all x.
To reverse the effect of the Average filter after decompression,
output the following value:
Average(x) + floor((Raw(x-bpp)+Prior(x))/2)
where the result is computed mod 256, but the prediction is
calculated in the same way as for encoding. Raw refers to the
bytes already decoded, and Prior refers to the decoded bytes of
the prior scanline.
6.6. Filter type 4: Paeth
The Paeth filter computes a simple linear function of the three
neighboring pixels (left, above, upper left), then chooses as
predictor the neighboring pixel closest to the computed value.
This technique is due to Alan W. Paeth [PAETH].
To compute the Paeth filter, apply the following formula to each
byte of the scanline:
Paeth(x) = Raw(x) - PaethPredictor(Raw(x-bpp), Prior(x),
Prior(x-bpp))
where x ranges from zero to the number of bytes representing the
scanline minus one, Raw(x) refers to the raw data byte at that
byte position in the scanline, Prior(x) refers to the unfiltered
bytes of the prior scanline, and bpp is defined as for the Sub
filter.
Note this is done for each byte, regardless of bit depth.
Unsigned arithmetic modulo 256 is used, so that both the inputs
and outputs fit into bytes. The sequence of Paeth values is
transmitted as the filtered scanline.
The PaethPredictor function is defined by the following
pseudocode:
function PaethPredictor (a, b, c)
begin
; a = left, b = above, c = upper left
p := a + b - c ; initial estimate
pa := abs(p - a) ; distances to a, b, c
pb := abs(p - b)
pc := abs(p - c)
; return nearest of a,b,c,
; breaking ties in order a,b,c.
if pa <= pb AND pa <= pc then return a
else if pb <= pc then return b
else return c
end
The calculations within the PaethPredictor function must be
performed exactly, without overflow. Arithmetic modulo 256 is to
be used only for the final step of subtracting the function result
from the target byte value.
Note that the order in which ties are broken is critical and must
not be altered. The tie break order is: pixel to the left, pixel
above, pixel to the upper left. (This order differs from that
given in Paeth's article.)
For all x < 0, assume Raw(x) = 0 and Prior(x) = 0. On the first
scanline of an image (or of a pass of an interlaced image), assume
Prior(x) = 0 for all x.
To reverse the effect of the Paeth filter after decompression,
output the following value:
Paeth(x) + PaethPredictor(Raw(x-bpp), Prior(x), Prior(x-bpp))
(computed mod 256), where Raw and Prior refer to bytes already
decoded. Exactly the same PaethPredictor function is used by both
encoder and decoder.
7. Chunk Ordering Rules
To allow new chunk types to be added to PNG, it is necessary to
establish rules about the ordering requirements for all chunk types.
Otherwise a PNG editing program cannot know what to do when it
encounters an unknown chunk.
We define a "PNG editor" as a program that modifies a PNG file and
wishes to preserve as much as possible of the ancillary information
in the file. Two examples of PNG editors are a program that adds or
modifies text chunks, and a program that adds a suggested palette to
a truecolor PNG file. Ordinary image editors are not PNG editors in
this sense, because they usually discard all unrecognized information
while reading in an image. (Note: we strongly encourage programs
handling PNG files to preserve ancillary information whenever
possible.)
As an example of possible problems, consider a hypothetical new
ancillary chunk type that is safe-to-copy and is required to appear
after PLTE if PLTE is present. If our program to add a suggested
PLTE does not recognize this new chunk, it may insert PLTE in the
wrong place, namely after the new chunk. We could prevent such
problems by requiring PNG editors to discard all unknown chunks, but
that is a very unattractive solution. Instead, PNG requires
ancillary chunks not to have ordering restrictions like this.
To prevent this type of problem while allowing for future extension,
we put some constraints on both the behavior of PNG editors and the
allowed ordering requirements for chunks.
7.1. Behavior of PNG editors
The rules for PNG editors are:
* When copying an unknown unsafe-to-copy ancillary chunk, a
PNG editor must not move the chunk relative to any critical
chunk. It can relocate the chunk freely relative to other
ancillary chunks that occur between the same pair of
critical chunks. (This is well defined since the editor
must not add, delete, modify, or reorder critical chunks if
it is preserving unknown unsafe-to-copy chunks.)
* When copying an unknown safe-to-copy ancillary chunk, a PNG
editor must not move the chunk from before IDAT to after
IDAT or vice versa. (This is well defined because IDAT is
always present.) Any other reordering is permitted.
* When copying a known ancillary chunk type, an editor need
only honor the specific chunk ordering rules that exist for
that chunk type. However, it can always choose to apply the
above general rules instead.
* PNG editors must give up on encountering an unknown critical
chunk type, because there is no way to be certain that a
valid file will result from modifying a file containing such
a chunk. (Note that simply discarding the chunk is not good
enough, because it might have unknown implications for the
interpretation of other chunks.)
These rules are expressed in terms of copying chunks from an input
file to an output file, but they apply in the obvious way if a PNG
file is modified in place.
See also Chunk naming conventions (Section 3.3).
7.2. Ordering of ancillary chunks
The ordering rules for an ancillary chunk type cannot be any
stricter than this:
* Unsafe-to-copy chunks can have ordering requirements
relative to critical chunks.
* Safe-to-copy chunks can have ordering requirements relative
to IDAT.
The actual ordering rules for any particular ancillary chunk type
may be weaker. See for example the ordering rules for the
standard ancillary chunk types (Summary of standard chunks,
Section 4.3).
Decoders must not assume more about the positioning of any
ancillary chunk than is specified by the chunk ordering rules. In
particular, it is never valid to assume that a specific ancillary
chunk type occurs with any particular positioning relative to
other ancillary chunks. (For example, it is unsafe to assume that
your private ancillary chunk occurs immediately before IEND. Even
if your application always writes it there, a PNG editor might
have inserted some other ancillary chunk after it. But you can
safely assume that your chunk will remain somewhere between IDAT
and IEND.)
7.3. Ordering of critical chunks
Critical chunks can have arbitrary ordering requirements, because
PNG editors are required to give up if they encounter unknown
critical chunks. For example, IHDR has the special ordering rule
that it must always appear first. A PNG editor, or indeed any
PNG-writing program, must know and follow the ordering rules for
any critical chunk type that it can emit.
8. Miscellaneous Topics
8.1. File name extension
On systems where file names customarily include an extension
signifying file type, the extension ".png" is recommended for PNG
files. Lower case ".png" is preferred if file names are case-
sensitive.
8.2. Internet media type
The Internet Assigned Numbers Authority (IANA) has registered
"image/png" as the Internet Media Type for PNG [RFC-2045, RFC-
2048]. For robustness, decoders may choose to also support the
interim media type "image/x-png" which was in use before
registration was complete.
8.3. Macintosh file layout
In the Apple Macintosh system, the following conventions are
recommended:
* The four-byte file type code for PNG files is "PNGf". (This
code has been registered with Apple for PNG files.) The
creator code will vary depending on the creating
application.
* The contents of the data fork must be a PNG file exactly as
described in the rest of this specification.
* The contents of the resource fork are unspecified. It may
be empty or may contain application-dependent resources.
* When transferring a Macintosh PNG file to a non-Macintosh
system, only the data fork should be transferred.
8.4. Multiple-image extension
PNG itself is strictly a single-image format. However, it may be
necessary to store multiple images within one file; for example,
this is needed to convert some GIF files. In the future, a
multiple-image format based on PNG may be defined. Such a format
will be considered a separate file format and will have a
different signature. PNG-supporting applications may or may not
choose to support the multiple-image format.
See Rationale: Why not these features? (Section 12.3).
8.5. Security considerations
A PNG file or datastream is composed of a collection of explicitly
typed "chunks". Chunks whose contents are defined by the
specification could actually contain anything, including malicious
code. But there is no known risk that such malicious code could
be executed on the recipient's computer as a result of decoding
the PNG image.
The possible security risks associated with future chunk types
cannot be specified at this time. Security issues will be
considered when evaluating chunks proposed for registration as
public chunks. There is no additional security risk associated
with unknown or unimplemented chunk types, because such chunks
will be ignored, or at most be copied into another PNG file.
The tEXt and zTXt chunks contain data that is meant to be
displayed as plain text. It is possible that if the decoder
displays such text without filtering out control characters,
especially the ESC (escape) character, certain systems or
terminals could behave in undesirable and insecure ways. We
recommend that decoders filter out control characters to avoid
this risk; see Recommendations for Decoders: Text chunk processing
(Section 10.11).
Because every chunk's length is available at its beginning, and
because every chunk has a CRC trailer, there is a very robust
defense against corrupted data and against fraudulent chunks that
attempt to overflow the decoder's buffers. Also, the PNG
signature bytes provide early detection of common file
transmission errors.
A decoder that fails to check CRCs could be subject to data
corruption. The only likely consequence of such corruption is
incorrectly displayed pixels within the image. Worse things might
happen if the CRC of the IHDR chunk is not checked and the width
or height fields are corrupted. See Recommendations for Decoders:
Error checking (Section 10.1).
A poorly written decoder might be subject to buffer overflow,
because chunks can be extremely large, up to (2^31)-1 bytes long.
But properly written decoders will handle large chunks without
difficulty.
9. Recommendations for Encoders
This chapter gives some recommendations for encoder behavior. The
only absolute requirement on a PNG encoder is that it produce files
that conform to the format specified in the preceding chapters.
However, best results will usually be achieved by following these
recommendations.
9.1. Sample depth scaling
When encoding input samples that have a sample depth that cannot
be directly represented in PNG, the encoder must scale the samples
up to a sample depth that is allowed by PNG. The most accurate
scaling method is the linear equation
output = ROUND(input * MAXOUTSAMPLE / MAXINSAMPLE)
where the input samples range from 0 to MAXINSAMPLE and the
outputs range from 0 to MAXOUTSAMPLE (which is (2^sampledepth)-1).
A close approximation to the linear scaling method can be achieved
by "left bit replication", which is shifting the valid bits to
begin in the most significant bit and repeating the most
significant bits into the open bits. This method is often faster
to compute than linear scaling. As an example, assume that 5-bit
samples are being scaled up to 8 bits. If the source sample value
is 27 (in the range from 0-31), then the original bits are:
4 3 2 1 0
---------
1 1 0 1 1
Left bit replication gives a value of 222:
7 6 5 4 3 2 1 0
----------------
1 1 0 1 1 1 1 0
|=======| |===|
| Leftmost Bits Repeated to Fill Open Bits
|
Original Bits
which matches the value computed by the linear equation. Left bit
replication usually gives the same value as linear scaling, and is
never off by more than one.
A distinctly less accurate approximation is obtained by simply
left-shifting the input value and filling the low order bits with
zeroes. This scheme cannot reproduce white exactly, since it does
not generate an all-ones maximum value; the net effect is to
darken the image slightly. This method is not recommended in
general, but it does have the effect of improving compression,
particularly when dealing with greater-than-eight-bit sample
depths. Since the relative error introduced by zero-fill scaling
is small at high sample depths, some encoders may choose to use
it. Zero-fill must not be used for alpha channel data, however,
since many decoders will special-case alpha values of all zeroes
and all ones. It is important to represent both those values
exactly in the scaled data.
When the encoder writes an sBIT chunk, it is required to do the
scaling in such a way that the high-order bits of the stored
samples match the original data. That is, if the sBIT chunk
specifies a sample depth of S, the high-order S bits of the stored
data must agree with the original S-bit data values. This allows
decoders to recover the original data by shifting right. The
added low-order bits are not constrained. Note that all the above
scaling methods meet this restriction.
When scaling up source data, it is recommended that the low-order
bits be filled consistently for all samples; that is, the same
source value should generate the same sample value at any pixel
position. This improves compression by reducing the number of
distinct sample values. However, this is not a requirement, and
some encoders may choose not to follow it. For example, an
encoder might instead dither the low-order bits, improving
displayed image quality at the price of increasing file size.
In some applications the original source data may have a range
that is not a power of 2. The linear scaling equation still works
for this case, although the shifting methods do not. It is
recommended that an sBIT chunk not be written for such images,
since sBIT suggests that the original data range was exactly
0..2^S-1.
9.2. Encoder gamma handling
See Gamma Tutorial (Chapter 13) if you aren't already familiar
with gamma issues.
Proper handling of gamma encoding and the gAMA chunk in an encoder
depends on the prior history of the sample values and on whether
these values have already been quantized to integers.
If the encoder has access to sample intensity values in floating-
point or high-precision integer form (perhaps from a computer
image renderer), then it is recommended that the encoder perform
its own gamma encoding before quantizing the data to integer
values for storage in the file. Applying gamma encoding at this
stage results in images with fewer banding artifacts at a given
sample depth, or allows smaller samples while retaining the same
visual quality.
A linear intensity level, expressed as a floating-point value in
the range 0 to 1, can be converted to a gamma-encoded sample value
by
sample = ROUND((intensity ^ encoder_gamma) * MAXSAMPLE)
The file_gamma value to be written in the PNG gAMA chunk is the
same as encoder_gamma in this equation, since we are assuming the
initial intensity value is linear (in effect, camera_gamma is
1.0).
If the image is being written to a file only, the encoder_gamma
value can be selected somewhat arbitrarily. Values of 0.45 or 0.5
are generally good choices because they are common in video
systems, and so most PNG decoders should do a good job displaying
such images.
Some image renderers may simultaneously write the image to a PNG
file and display it on-screen. The displayed pixels should be
gamma corrected for the display system and viewing conditions in
use, so that the user sees a proper representation of the intended
scene. An appropriate gamma correction value is
screen_gc = viewing_gamma / display_gamma
If the renderer wants to write the same gamma-corrected sample
values to the PNG file, avoiding a separate gamma-encoding step
for file output, then this screen_gc value should be written in
the gAMA chunk. This will allow a PNG decoder to reproduce what
the file's originator saw on screen during rendering (provided the
decoder properly supports arbitrary values in a gAMA chunk).
However, it is equally reasonable for a renderer to apply gamma
correction for screen display using a gamma appropriate to the
viewing conditions, and to separately gamma-encode the sample
values for file storage using a standard value of gamma such as
0.5. In fact, this is preferable, since some PNG decoders may not
accurately display images with unusual gAMA values.
Computer graphics renderers often do not perform gamma encoding,
instead making sample values directly proportional to scene light
intensity. If the PNG encoder receives sample values that have
already been quantized into linear-light integer values, there is
no point in doing gamma encoding on them; that would just result
in further loss of information. The encoder should just write the
sample values to the PNG file. This "linear" sample encoding is
equivalent to gamma encoding with a gamma of 1.0, so graphics
programs that produce linear samples should always emit a gAMA
chunk specifying a gamma of 1.0.
When the sample values come directly from a piece of hardware, the
correct gAMA value is determined by the gamma characteristic of
the hardware. In the case of video digitizers ("frame grabbers"),
gAMA should be 0.45 or 0.5 for NTSC (possibly less for PAL or
SECAM) since video camera transfer functions are standardized.
Image scanners are less predictable. Their output samples may be
linear (gamma 1.0) since CCD sensors themselves are linear, or the
scanner hardware may have already applied gamma correction
designed to compensate for dot gain in subsequent printing (gamma
of about 0.57), or the scanner may have corrected the samples for
display on a CRT (gamma of 0.4-0.5). You will need to refer to
the scanner's manual, or even scan a calibrated gray wedge, to
determine what a particular scanner does.
File format converters generally should not attempt to convert
supplied images to a different gamma. Store the data in the PNG
file without conversion, and record the source gamma if it is
known. Gamma alteration at file conversion time causes re-
quantization of the set of intensity levels that are represented,
introducing further roundoff error with little benefit. It's
almost always better to just copy the sample values intact from
the input to the output file.
In some cases, the supplied image may be in an image format (e.g.,
TIFF) that can describe the gamma characteristic of the image. In
such cases, a file format converter is strongly encouraged to
write a PNG gAMA chunk that corresponds to the known gamma of the
source image. Note that some file formats specify the gamma of
the display system, not the camera. If the input file's gamma
value is greater than 1.0, it is almost certainly a display system
gamma, and you should use its reciprocal for the PNG gAMA.
If the encoder or file format converter does not know how an image
was originally created, but does know that the image has been
displayed satisfactorily on a display with gamma display_gamma
under lighting conditions where a particular viewing_gamma is
appropriate, then the image can be marked as having the
file_gamma:
file_gamma = viewing_gamma / display_gamma
This will allow viewers of the PNG file to see the same image that
the person running the file format converter saw. Although this
may not be precisely the correct value of the image gamma, it's
better to write a gAMA chunk with an approximately right value
than to omit the chunk and force PNG decoders to guess at an
appropriate gamma.
On the other hand, if the image file is being converted as part of
a "bulk" conversion, with no one looking at each image, then it is
better to omit the gAMA chunk entirely. If the image gamma has to
be guessed at, leave it to the decoder to do the guessing.
Gamma does not apply to alpha samples; alpha is always represented
linearly.
See also Recommendations for Decoders: Decoder gamma handling
(Section 10.5).
9.3. Encoder color handling
See Color Tutorial (Chapter 14) if you aren't already familiar
with color issues.
If it is possible for the encoder to determine the chromaticities
of the source display primaries, or to make a strong guess based
on the origin of the image or the hardware running it, then the
encoder is strongly encouraged to output the cHRM chunk. If it
does so, the gAMA chunk should also be written; decoders can do
little with cHRM if gAMA is missing.
Video created with recent video equipment probably uses the CCIR
709 primaries and D65 white point [ITU-BT709], which are:
R G B White
x 0.640 0.300 0.150 0.3127
y 0.330 0.600 0.060 0.3290
An older but still very popular video standard is SMPTE-C [SMPTE-
170M]:
R G B White
x 0.630 0.310 0.155 0.3127
y 0.340 0.595 0.070 0.3290
The original NTSC color primaries have not been used in decades.
Although you may still find the NTSC numbers listed in standards
documents, you won't find any images that actually use them.
Scanners that produce PNG files as output should insert the filter
chromaticities into a cHRM chunk and the camera_gamma into a gAMA
chunk.
In the case of hand-drawn or digitally edited images, you have to
determine what monitor they were viewed on when being produced.
Many image editing programs allow you to specify what type of
monitor you are using. This is often because they are working in
some device-independent space internally. Such programs have
enough information to write valid cHRM and gAMA chunks, and should
do so automatically.
If the encoder is compiled as a portion of a computer image
renderer that performs full-spectral rendering, the monitor values
that were used to convert from the internal device-independent
color space to RGB should be written into the cHRM chunk. Any
colors that are outside the gamut of the chosen RGB device should
be clipped or otherwise constrained to be within the gamut; PNG
does not store out of gamut colors.
If the computer image renderer performs calculations directly in
device-dependent RGB space, a cHRM chunk should not be written
unless the scene description and rendering parameters have been
adjusted to look good on a particular monitor. In that case, the
data for that monitor (if known) should be used to construct a
cHRM chunk.
There are often cases where an image's exact origins are unknown,
particularly if it began life in some other format. A few image
formats store calibration information, which can be used to fill
in the cHRM chunk. For example, all PhotoCD images use the CCIR
709 primaries and D65 whitepoint, so these values can be written
into the cHRM chunk when converting a PhotoCD file. PhotoCD also
uses the SMPTE-170M transfer function, which is closely
approximated by a gAMA of 0.5. (PhotoCD can store colors outside
the RGB gamut, so the image data will require gamut mapping before
writing to PNG format.) TIFF 6.0 files can optionally store
calibration information, which if present should be used to
construct the cHRM chunk. GIF and most other formats do not store
any calibration information.
It is not recommended that file format converters attempt to
convert supplied images to a different RGB color space. Store the
data in the PNG file without conversion, and record the source
primary chromaticities if they are known. Color space
transformation at file conversion time is a bad idea because of
gamut mismatches and rounding errors. As with gamma conversions,
it's better to store the data losslessly and incur at most one
conversion when the image is finally displayed.
See also Recommendations for Decoders: Decoder color handling
(Section 10.6).
9.4. Alpha channel creation
The alpha channel can be regarded either as a mask that
temporarily hides transparent parts of the image, or as a means
for constructing a non-rectangular image. In the first case, the
color values of fully transparent pixels should be preserved for
future use. In the second case, the transparent pixels carry no
useful data and are simply there to fill out the rectangular image
area required by PNG. In this case, fully transparent pixels
should all be assigned the same color value for best compression.
Image authors should keep in mind the possibility that a decoder
will ignore transparency control. Hence, the colors assigned to
transparent pixels should be reasonable background colors whenever
feasible.
For applications that do not require a full alpha channel, or
cannot afford the price in compression efficiency, the tRNS
transparency chunk is also available.
If the image has a known background color, this color should be
written in the bKGD chunk. Even decoders that ignore transparency
may use the bKGD color to fill unused screen area.
If the original image has premultiplied (also called "associated")
alpha data, convert it to PNG's non-premultiplied format by
dividing each sample value by the corresponding alpha value, then
multiplying by the maximum value for the image bit depth, and
rounding to the nearest integer. In valid premultiplied data, the
sample values never exceed their corresponding alpha values, so
the result of the division should always be in the range 0 to 1.
If the alpha value is zero, output black (zeroes).
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.
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.)
For images of color type 2 (truecolor without alpha channel), it
is recommended that the palette and histogram 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).
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.
If PLTE appears without bKGD in an image of color type 6, the
circumstances under which the palette was computed are
unspecified.
9.6. Filter selection
For images of color type 3 (indexed color), filter type 0 (None)
is usually the most effective. Note that color images with 256 or
fewer colors should almost always be stored in indexed color
format; truecolor format is likely to be much larger.
Filter type 0 is also recommended for images of bit depths less
than 8. For low-bit-depth grayscale images, it may be a net win
to expand the image to 8-bit representation and apply filtering,
but this is rare.
For truecolor and grayscale images, any of the five filters may
prove the most effective. If an encoder uses a fixed filter, the
Paeth filter is most likely to be the best.
For best compression of truecolor and grayscale images, we
recommend an adaptive filtering approach in which a filter is
chosen for each scanline. The following simple heuristic has
performed well in early tests: compute the output scanline using
all five filters, and select the filter that gives the smallest
sum of absolute values of outputs. (Consider the output bytes as
signed differences for this test.) This method usually
outperforms any single fixed filter choice. However, it is likely
that much better heuristics will be found as more experience is
gained with PNG.
Filtering according to these recommendations is effective on
interlaced as well as noninterlaced images.
9.7. Text chunk processing
A nonempty keyword must be provided for each text chunk. The
generic keyword "Comment" can be used if no better description of
the text is available. If a user-supplied keyword is used, be
sure to check that it meets the restrictions on keywords.
PNG text strings are expected to use the Latin-1 character set.
Encoders should avoid storing characters that are not defined in
Latin-1, and should provide character code remapping if the local
system's character set is not Latin-1.
Encoders should discourage the creation of single lines of text
longer than 79 characters, in order to facilitate easy reading.
It is recommended that text items less than 1K (1024 bytes) in
size should be output using uncompressed tEXt chunks. In
particular, it is recommended that the basic title and author
keywords should always be output using uncompressed tEXt chunks.
Lengthy disclaimers, on the other hand, are ideal candidates for
zTXt.
Placing large tEXt and zTXt chunks after the image data (after
IDAT) can speed up image display in some situations, since the
decoder won't have to read over the text to get to the image data.
But it is recommended that small text chunks, such as the image
title, appear before IDAT.
9.8. Use of private chunks
Applications can use PNG private chunks to carry information that
need not be understood by other applications. Such chunks must be
given names with lowercase second letters, to ensure that they can
never conflict with any future public chunk definition. Note,
however, that there is no guarantee that some other application
will not use the same private chunk name. If you use a private
chunk type, it is prudent to store additional identifying
information at the beginning of the chunk data.
Use an ancillary chunk type (lowercase first letter), not a
critical chunk type, for all private chunks that store information
that is not absolutely essential to view the image. Creation of
private critical chunks is discouraged because they render PNG
files unportable. Such chunks should not be used in publicly
available software or files. If private critical chunks are
essential for your application, it is recommended that one appear
near the start of the file, so that a standard decoder need not
read very far before discovering that it cannot handle the file.
If you want others outside your organization to understand a chunk
type that you invent, contact the maintainers of the PNG
specification to submit a proposed chunk name and definition for
addition to the list of special-purpose public chunks (see
Additional chunk types, Section 4.4). Note that a proposed public
chunk name (with uppercase second letter) must not be used in
publicly available software or files until registration has been
approved.
If an ancillary chunk contains textual information that might be
of interest to a human user, you should not create a special chunk
type for it. Instead use a tEXt chunk and define a suitable
keyword. That way, the information will be available to users not
using your software.
Keywords in tEXt chunks should be reasonably self-explanatory,
since the idea is to let other users figure out what the chunk
contains. If of general usefulness, new keywords can be
registered with the maintainers of the PNG specification. But it
is permissible to use keywords without registering them first.
9.9. Private type and method codes
This specification defines the meaning of only some of the
possible values of some fields. For example, only compression
method 0 and filter types 0 through 4 are defined. Numbers
greater than 127 must be used when inventing experimental or
private definitions of values for any of these fields. Numbers
below 128 are reserved for possible future public extensions of
this specification. Note that use of private type codes may
render a file unreadable by standard decoders. Such codes are
strongly discouraged except for experimental purposes, and should
not appear in publicly available software or files.
10. Recommendations for Decoders
This chapter gives some recommendations for decoder behavior. The
only absolute requirement on a PNG decoder is that it successfully
read any file conforming to the format specified in the preceding
chapters. However, best results will usually be achieved by
following these recommendations.
10.1. Error checking
To ensure early detection of common file-transfer problems,
decoders should verify that all eight bytes of the PNG file
signature are correct. (See Rationale: PNG file signature,
Section 12.11.) A decoder can have additional confidence in the
file's integrity if the next eight bytes are an IHDR chunk header
with the correct chunk length.
Unknown chunk types must be handled as described in Chunk naming
conventions (Section 3.3). An unknown chunk type is not to be
treated as an error unless it is a critical chunk.
It is strongly recommended that decoders should verify the CRC on
each chunk.
In some situations it is desirable to check chunk headers (length
and type code) before reading the chunk data and CRC. The chunk
type can be checked for plausibility by seeing whether all four
bytes are ASCII letters (codes 65-90 and 97-122); note that this
need only be done for unrecognized type codes. If the total file
size is known (from file system information, HTTP protocol, etc),
the chunk length can be checked for plausibility as well.
If CRCs are not checked, dropped/added data bytes or an erroneous
chunk length can cause the decoder to get out of step and
misinterpret subsequent data as a chunk header. Verifying that
the chunk type contains letters is an inexpensive way of providing
early error detection in this situation.
For known-length chunks such as IHDR, decoders should treat an
unexpected chunk length as an error. Future extensions to this
specification will not add new fields to existing chunks; instead,
new chunk types will be added to carry new information.
Unexpected values in fields of known chunks (for example, an
unexpected compression method in the IHDR chunk) must be checked
for and treated as errors. However, it is recommended that
unexpected field values be treated as fatal errors only in
critical chunks. An unexpected value in an ancillary chunk can be
handled by ignoring the whole chunk as though it were an unknown
chunk type. (This recommendation assumes that the chunk's CRC has
been verified. In decoders that do not check CRCs, it is safer to
treat any unexpected value as indicating a corrupted file.)
10.2. Pixel dimensions
Non-square pixels can be represented (see the pHYs chunk), but
viewers are not required to account for them; a viewer can present
any PNG file as though its pixels are square.
Conversely, viewers running on display hardware with non-square
pixels are strongly encouraged to rescale images for proper
display.
10.3. Truecolor image handling
To achieve PNG's goal of universal interchangeability, decoders
are required to accept all types of PNG image: indexed-color,
truecolor, and grayscale. Viewers running on indexed-color
display hardware need to be able to reduce truecolor images to
indexed format for viewing. This process is usually called "color
quantization".
A simple, fast way of doing this is to reduce the image to a fixed
palette. Palettes with uniform color spacing ("color cubes") are
usually used to minimize the per-pixel computation. For
photograph-like images, dithering is recommended to avoid ugly
contours in what should be smooth gradients; however, dithering
introduces graininess that can be objectionable.
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). 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.
Numerous implementations of color quantization are available. The
PNG reference implementation, libpng, includes code for the
purpose.
10.4. Sample depth rescaling
Decoders may wish to scale PNG data to a lesser sample depth (data
precision) for display. For example, 16-bit data will need to be
reduced to 8-bit depth for use on most present-day display
hardware. Reduction of 8-bit data to 5-bit depth is also common.
The most accurate scaling is achieved by the linear equation
output = ROUND(input * MAXOUTSAMPLE / MAXINSAMPLE)
where
MAXINSAMPLE = (2^sampledepth)-1
MAXOUTSAMPLE = (2^desired_sampledepth)-1
A slightly less accurate conversion is achieved by simply shifting
right by sampledepth-desired_sampledepth places. For example, to
reduce 16-bit samples to 8-bit, one need only discard the low-
order byte. In many situations the shift method is sufficiently
accurate for display purposes, and it is certainly much faster.
(But if gamma correction is being done, sample rescaling can be
merged into the gamma correction lookup table, as is illustrated
in Decoder gamma handling, Section 10.5.)
When an sBIT chunk is present, the original pre-PNG data can be
recovered by shifting right to the sample depth specified by sBIT.
Note that linear scaling will not necessarily reproduce the
original data, because the encoder is not required to have used
linear scaling to scale the data up. However, the encoder is
required to have used a method that preserves the high-order bits,
so shifting always works. This is the only case in which shifting
might be said to be more accurate than linear scaling.
When comparing pixel values to tRNS chunk values to detect
transparent pixels, it is necessary to do the comparison exactly.
Therefore, transparent pixel detection must be done before
reducing sample precision.
10.5. Decoder gamma handling
See Gamma Tutorial (Chapter 13) if you aren't already familiar
with gamma issues.
To produce correct tone reproduction, a good image display program
should take into account the gammas of the image file and the
display device, as well as the viewing_gamma appropriate to the
lighting conditions near the display. This can be done by
calculating
gbright = insample / MAXINSAMPLE
bright = gbright ^ (1.0 / file_gamma)
vbright = bright ^ viewing_gamma
gcvideo = vbright ^ (1.0 / display_gamma)
fbval = ROUND(gcvideo * MAXFBVAL)
where MAXINSAMPLE is the maximum sample value in the file (255 for
8-bit, 65535 for 16-bit, etc), MAXFBVAL is the maximum value of a
frame buffer sample (255 for 8-bit, 31 for 5-bit, etc), insample
is the value of the sample in the PNG file, and fbval is the value
to write into the frame buffer. The first line converts from
integer samples into a normalized 0 to 1 floating point value, the
second undoes the gamma encoding of the image file to produce a
linear intensity value, the third adjusts for the viewing
conditions, the fourth corrects for the display system's gamma
value, and the fifth converts to an integer frame buffer sample.
In practice, the second through fourth lines can be merged into
gcvideo = gbright^(viewing_gamma / (file_gamma*display_gamma))
so as to perform only one power calculation. For color images, the
entire calculation is performed separately for R, G, and B values.
It is not necessary to perform transcendental math for every
pixel. Instead, compute a lookup table that gives the correct
output value for every possible sample value. This requires only
256 calculations per image (for 8-bit accuracy), not one or three
calculations per pixel. For an indexed-color image, a one-time
correction of the palette is sufficient, unless the image uses
transparency and is being displayed against a nonuniform
background.
In some cases even the cost of computing a gamma lookup table may
be a concern. In these cases, viewers are encouraged to have
precomputed gamma correction tables for file_gamma values of 1.0
and 0.5 with some reasonable choice of viewing_gamma and
display_gamma, and to use the table closest to the gamma indicated
in the file. This will produce acceptable results for the majority
of real files.
When the incoming image has unknown gamma (no gAMA chunk), choose
a likely default file_gamma value, but allow the user to select a
new one if the result proves too dark or too light.
In practice, it is often difficult to determine what value of
display_gamma should be used. In systems with no built-in gamma
correction, the display_gamma is determined entirely by the CRT.
Assuming a CRT_gamma of 2.5 is recommended, unless you have
detailed calibration measurements of this particular CRT
available.
However, many modern frame buffers have lookup tables that are
used to perform gamma correction, and on these systems the
display_gamma value should be the gamma of the lookup table and
CRT combined. You may not be able to find out what the lookup
table contains from within an image viewer application, so you may
have to ask the user what the system's gamma value is.
Unfortunately, different manufacturers use different ways of
specifying what should go into the lookup table, so interpretation
of the system gamma value is system-dependent. Gamma Tutorial
(Chapter 13) gives some examples.
The response of real displays is actually more complex than can be
described by a single number (display_gamma). If actual
measurements of the monitor's light output as a function of
voltage input are available, the fourth and fifth lines of the
computation above can be replaced by a lookup in these
measurements, to find the actual frame buffer value that most
nearly gives the desired brightness.
The value of viewing_gamma depends on lighting conditions; see
Gamma Tutorial (Chapter 13) for more detail. Ideally, a viewer
would allow the user to specify viewing_gamma, either directly
numerically, or via selecting from "bright surround", "dim
surround", and "dark surround" conditions. Viewers that don't
want to do this should just assume a value for viewing_gamma of
1.0, since most computer displays live in brightly-lit rooms.
When viewing images that are digitized from video, or that are
destined to become video frames, the user might want to set the
viewing_gamma to about 1.25 regardless of the actual level of room
lighting. This value of viewing_gamma is "built into" NTSC video
practice, and displaying an image with that viewing_gamma allows
the user to see what a TV set would show under the current room
lighting conditions. (This is not the same thing as trying to
obtain the most accurate rendition of the content of the scene,
which would require adjusting viewing_gamma to correspond to the
room lighting level.) This is another reason viewers might want
to allow users to adjust viewing_gamma directly.
10.6. Decoder color handling
See Color Tutorial (Chapter 14) if you aren't already familiar
with color issues.
In many cases, decoders will treat image data in PNG files as
dev