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
Boutell, et. al. Informational [Page 1]
RFC 2083 PNG: Portable Network Graphics March 1997
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
Boutell, et. al. Informational [Page 2]
RFC 2083 PNG: Portable Network Graphics March 1997
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
Boutell, et. al. Informational [Page 3]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 4]
RFC 2083 PNG: Portable Network Graphics March 1997
* 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).
Boutell, et. al. Informational [Page 5]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 6]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 7]
RFC 2083 PNG: Portable Network Graphics March 1997
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
Boutell, et. al. Informational [Page 8]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 9]
RFC 2083 PNG: Portable Network Graphics March 1997
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).
Boutell, et. al. Informational [Page 10]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 11]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 12]
RFC 2083 PNG: Portable Network Graphics March 1997
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.)
Boutell, et. al. Informational [Page 13]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 14]
RFC 2083 PNG: Portable Network Graphics March 1997
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
Boutell, et. al. Informational [Page 15]
RFC 2083 PNG: Portable Network Graphics March 1997
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
Boutell, et. al. Informational [Page 16]
RFC 2083 PNG: Portable Network Graphics March 1997
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
Boutell, et. al. Informational [Page 17]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 18]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 19]
RFC 2083 PNG: Portable Network Graphics March 1997
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).
Boutell, et. al. Informational [Page 20]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 21]
RFC 2083 PNG: Portable Network Graphics March 1997
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
Boutell, et. al. Informational [Page 22]
RFC 2083 PNG: Portable Network Graphics March 1997
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).
Boutell, et. al. Informational [Page 23]
RFC 2083 PNG: Portable Network Graphics March 1997
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
Boutell, et. al. Informational [Page 24]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 25]
RFC 2083 PNG: Portable Network Graphics March 1997
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).
Boutell, et. al. Informational [Page 26]
RFC 2083 PNG: Portable Network Graphics March 1997
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
Boutell, et. al. Informational [Page 27]
RFC 2083 PNG: Portable Network Graphics March 1997
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
Boutell, et. al. Informational [Page 28]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 29]
RFC 2083 PNG: Portable Network Graphics March 1997
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.
Boutell, et. al. Informational [Page 30]
RFC 2083 PNG: Portable Network Graphics March 1997
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
[COLOR-4]
Stone, M.C., W.B. Cowan, and J.C. Beatty, "Color gamut mapping and
the printing of digital images", ACM Transactions on Graphics, vol
7 no 3 (1988), pp 249-292.
[COLOR-5]
Travis, David, Effective Color Displays --- Theory and Practice.
Academic Press, London, 1991. ISBN 0-12-697690-2.
[GAMMA-FAQ]
Poynton, C., "Gamma FAQ".
Boutell, et. al. Informational [Page 97]
RFC 2083 PNG: Portable Network Graphics March 1997
[ISO-3309]
International Organization for Standardization, "Information
Processing Systems --- Data Communication High-Level Data Link
Control Procedure --- Frame Structure", IS 3309, October 1984, 3rd
Edition.
[ISO-8859]
International Organization for Standardization, "Information
Processing --- 8-bit Single-Byte Coded Graphic Character Sets ---
Part 1: Latin Alphabet No. 1", IS 8859-1, 1987.
Also see sample files at
ftp://ftp.uu.net/graphics/png/documents/iso_8859-1.*
[ITU-BT709]
International Telecommunications Union, "Basic Parameter Values
for the HDTV Standard for the Studio and for International
Programme Exchange", ITU-R Recommendation BT.709 (formerly CCIR
Rec. 709), 1990.
[ITU-V42]
International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous Conversion",
ITU-T Recommendation V.42, 1994, Rev. 1.
[PAETH]
Paeth, A.W., "Image File Compression Made Easy", in Graphics Gems
II, James Arvo, editor. Academic Press, San Diego, 1991. ISBN
0-12-064480-0.
[POSTSCRIPT]
Adobe Systems Incorporated, PostScript Language Reference Manual,
2nd edition. Addison-Wesley, Reading, 1990. ISBN 0-201-18127-4.
[PNG-EXTENSIONS]
PNG Group, "PNG Special-Purpose Public Chunks". Available in
several formats from
ftp://ftp.uu.net/graphics/png/documents/pngextensions.*
[RFC-1123]
Braden, R., Editor, "Requirements for Internet Hosts ---
Application and Support", STD 3, RFC 1123, USC/Information
Sciences Institute, October 1989.
Boutell, et. al. Informational [Page 98]
RFC 2083 PNG: Portable Network Graphics March 1997
[RFC-2045]
Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, Innosoft, First Virtual, November 1996.
[RFC-2048]
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
Innosoft, MCI, USC/Information Sciences Institute, November 1996.
[RFC-1950]
Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Aladdin Enterprises, May
1996.
[RFC-1951]
Deutsch, P., "DEFLATE Compressed Data Format Specification version
1.3", RFC 1951, Aladdin Enterprises, May 1996.
[SMPTE-170M]
Society of Motion Picture and Television Engineers, "Television
--- Composite Analog Video Signal --- NTSC for Studio
Applications", SMPTE-170M, 1994.
Boutell, et. al. Informational [Page 99]
RFC 2083 PNG: Portable Network Graphics March 1997
19. Credits
Editor
Thomas Boutell, boutell@boutell.com
Contributing Editor
Tom Lane, tgl@sss.pgh.pa.us
Authors
Authors' names are presented in alphabetical order.
* Mark Adler, madler@alumni.caltech.edu
* Thomas Boutell, boutell@boutell.com
* Christian Brunschen, cb@df.lth.se
* Adam M. Costello, amc@cs.berkeley.edu
* Lee Daniel Crocker, lee@piclab.com
* Andreas Dilger, adilger@enel.ucalgary.ca
* Oliver Fromme, fromme@rz.tu-clausthal.de
* Jean-loup Gailly, gzip@prep.ai.mit.edu
* Chris Herborth, chrish@qnx.com
* Alex Jakulin, Aleks.Jakulin@snet.fri.uni-lj.si
* Neal Kettler, kettler@cs.colostate.edu
* Tom Lane, tgl@sss.pgh.pa.us
* Alexander Lehmann, alex@hal.rhein-main.de
* Chris Lilley, chris@w3.org
* Dave Martindale, davem@cs.ubc.ca
* Owen Mortensen, 104707.650@compuserve.com
* Keith S. Pickens, ksp@swri.edu
* Robert P. Poole, lionboy@primenet.com
* Glenn Randers-Pehrson, glennrp@arl.mil or
randeg@alumni.rpi.edu
* Greg Roelofs, newt@pobox.com
* Willem van Schaik, willem@gintic.gov.sg
* Guy Schalnat
* Paul Schmidt, pschmidt@photodex.com
* Tim Wegner, 71320.675@compuserve.com
* Jeremy Wohl, jeremyw@anders.com
The authors wish to acknowledge the contributions of the Portable
Network Graphics mailing list, the readers of comp.graphics, and
the members of the World Wide Web Consortium (W3C).
Boutell, et. al. Informational [Page 100]
RFC 2083 PNG: Portable Network Graphics March 1997
The Adam7 interlacing scheme is not patented and it is not the
intention of the originator of that scheme to patent it. The
scheme may be freely used by all PNG implementations. The name
"Adam7" may be freely used to describe interlace method 1 of the
PNG specification.
Trademarks
GIF is a service mark of CompuServe Incorporated. IBM PC is a
trademark of International Business Machines Corporation.
Macintosh is a trademark of Apple Computer, Inc. Microsoft and
MS-DOS are trademarks of Microsoft Corporation. PhotoCD is a
trademark of Eastman Kodak Company. PostScript and TIFF are
trademarks of Adobe Systems Incorporated. SGI is a trademark of
Silicon Graphics, Inc. X Window System is a trademark of the
Massachusetts Institute of Technology.
COPYRIGHT NOTICE
Copyright (c) 1996 by: Massachusetts Institute of Technology (MIT)
This W3C specification is being provided by the copyright holders
under the following license. By obtaining, using and/or copying this
specification, you agree that you have read, understood, and will
comply with the following terms and conditions:
Permission to use, copy, and distribute this specification for any
purpose and without fee or royalty is hereby granted, provided that
the full text of this NOTICE appears on ALL copies of the
specification or portions thereof, including modifications, that you
make.
THIS SPECIFICATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO
REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF
EXAMPLE, BUT NOT LIMITATION, COPYRIGHT HOLDERS MAKE NO
REPRESENTATIONS OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY
PARTICULAR PURPOSE OR THAT THE USE OF THE SPECIFICATION WILL NOT
INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER
RIGHTS. COPYRIGHT HOLDERS WILL BEAR NO LIABILITY FOR ANY USE OF THIS
SPECIFICATION.
Boutell, et. al. Informational [Page 101]
RFC 2083 PNG: Portable Network Graphics March 1997
The name and trademarks of copyright holders may NOT be used in
advertising or publicity pertaining to the specification without
specific, written prior permission. Title to copyright in this
specification and any associated documentation will at all times
remain with copyright holders.
Security Considerations
Security issues are discussed in Security considerations (Section
8.5).
Author's Address
Thomas Boutell
PO Box 20837
Seattle, WA 98102
Phone: (206) 329-4969
EMail: boutell@boutell.com
Boutell, et. al. Informational [Page 102]
RFC, FYI, BCP