As per Relevance of the word represent, we have this rfc below:
Network Working Group T. Boutell, et. al
Request for Comments: 2083 Boutell.Com, Inc
Category: Informational March 1997
PNG (Portable Network Graphics)
Version 1.0
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
IESG Note
The IESG takes no position on the validity of any
Property Rights statements contained in this document
This document describes PNG (Portable Network Graphics),
extensible file format for the lossless, portable, well-
storage of raster images. PNG provides a patent-free replacement
GIF and can also replace many common uses of TIFF. Indexed-color
grayscale, and truecolor images are supported, plus an optional
channel. Sample depths range from 1 to 16 bits
PNG is designed to work well in online viewing applications, such
the World Wide Web, so it is fully streamable with a
display option. PNG is robust, providing both full file
checking and simple detection of common transmission errors. Also
PNG can store gamma and chromaticity data for improved color
on heterogeneous platforms
This specification defines the Internet Media Type image/png
Table of
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.
The PNG format provides a portable, legally unencumbered, well
compressed, well-specified standard for lossless bitmapped
files
Although the initial motivation for developing PNG was to
GIF, the design provides some useful new features not available
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,
allowing the file format to be used as a
protocol for on-the-fly generation and display of images
* Progressive display: a suitably prepared image file can
displayed as it is received over a communications link
yielding a low-resolution image very quickly followed
gradual improvement of detail
* Transparency: portions of the image can be marked
transparent, creating the effect of a non-rectangular image
* Ancillary information: textual comments and other data can
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
images with correct brightness/contrast regardless of
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
easily
* Legally unencumbered: to the best knowledge of the PNG authors
no algorithms under legal challenge are used. (
considerable effort has been spent to verify this.)
* Well compressed: both indexed-color and truecolor images
compressed as effectively as in any other widely used
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
all conforming PNG files
* Flexible: the format allows for future extensions and
add-ons, without compromising interchangeability of basic PNG
* Robust: the design supports full file integrity checking
well as simple, quick detection of common transmission errors
The main part of this specification gives the definition of the
format and recommendations for encoder and decoder behavior.
appendix gives the rationale for many design decisions. Although
rationale is not part of the formal specification, reading it
help implementors understand the design. Cross-references in
main text point to relevant parts of the rationale.
appendixes, also not part of the formal specification,
tutorials on gamma and color theory as well as other
material
In this specification, the word "must" indicates a
requirement, while "should" indicates recommended behavior
See Rationale: Why a new file format? (Section 12.1), Why
features? (Section 12.2), Why not these features? (Section 12.3),
not use format X? (Section 12.4).
PNG is pronounced "ping".
2. Data
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
All integers that require more than one byte must be in
byte order: the most significant byte comes first, then the
significant bytes in descending order of significance (MSB LSB
two-byte integers, B3 B2 B1 B0 for four-byte integers).
highest bit (value 128) of a byte is numbered bit 7; the
bit (value 1) is numbered bit 0. Values are unsigned
otherwise noted. Values explicitly noted as signed are
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
Colors can be represented by either grayscale or RGB (red, green
blue) sample data. Grayscale data represents luminance; RGB
represents calibrated color information (if the cHRM chunk
present) or uncalibrated device-dependent color (if cHRM
absent). All color values range from zero (representing black)
most intense at the maximum value for the sample depth. Note
the maximum value at a given sample depth is (2^sampledepth)-1,
not 2^sampledepth
Sample values are not necessarily linear; the gAMA chunk
the gamma characteristic of the source device, and viewers
strongly encouraged to compensate properly. See Gamma
(Section 2.7).
Source data with a precision not directly supported in PNG (
example, 5 bit/sample truecolor) must be scaled up to the
higher supported bit depth. This scaling is reversible with
loss of data, and it reduces the number of cases that
have to cope with. See Recommendations for Encoders: Sample
scaling (Section 9.1) and Recommendations for Decoders:
depth rescaling (Section 10.4).
2.3. Image
Conceptually, a PNG image is a rectangular pixel array,
pixels appearing left-to-right within each scanline, and
appearing top-to-bottom. (For progressive display purposes,
data may actually be transmitted in a different order;
Interlaced data order, Section 2.6.) The size of each pixel
determined by the bit depth, which is the number of bits
sample in the image data
Three types of pixel are supported
* An indexed-color pixel is represented by a single
that is an index into a supplied palette. The image
depth determines the maximum number of palette entries,
not the color precision within the palette
* A grayscale pixel is represented by a single sample that
a grayscale level, where zero is black and the largest
for the bit depth is white
* A truecolor pixel is represented by three samples: red (
= black, max = red) appears first, then green (zero = black
max = green), then blue (zero = black, max = blue). The
depth specifies the size of each sample, not the total
size
Boutell, et. al. Informational [Page 6]
RFC 2083 PNG: Portable Network Graphics March 1997
Optionally, grayscale and truecolor pixels can also include
alpha sample, as described in the next section
Pixels are always packed into scanlines with no wasted
between pixels. Pixels smaller than a byte never cross
boundaries; they are packed into bytes with the leftmost pixel
the high-order bits of a byte, the rightmost in the low-
bits. Permitted bit depths and pixel types are restricted so
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
byte. 16-bit samples are stored in network byte order (
first).
Scanlines always begin on byte boundaries. When pixels have
than 8 bits and the scanline width is not evenly divisible by
number of pixels per byte, the low-order bits in the last byte
each scanline are wasted. The contents of these wasted bits
unspecified
An additional "filter type" byte is added to the beginning
every scanline (see Filtering, Section 2.5). The filter type
is not considered part of the image data, but it is included
the datastream sent to the compression step
2.4. Alpha
An alpha channel, representing transparency information on a per
pixel basis, can be included in grayscale and truecolor
images
An alpha value of zero represents full transparency, and a
of (2^bitdepth)-1 represents a fully opaque pixel.
values indicate partially transparent pixels that can be
with a background image to yield a composite image. (Thus,
is really the degree of opacity of the pixel. But most
refer to alpha as providing transparency information, not
information, and we continue that custom here.)
Alpha channels can be included with images that have either 8
16 bits per sample, but not with images that have fewer than 8
bits per sample. Alpha samples are represented with the same
depth used for the image samples. The alpha sample for each
is stored immediately following the grayscale or RGB samples
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
value assigned to the pixel. This rule is sometimes
"unassociated" or "non-premultiplied" alpha. (Another
technique is to store sample values premultiplied by the
fraction; in effect, such an image is already composited against
black background. PNG does not use premultiplied alpha.)
Transparency control is also possible without the storage cost
a full alpha channel. In an indexed-color image, an alpha
can be defined for each palette entry. In grayscale and
images, a single pixel value can be identified as
"transparent". These techniques are controlled by the
ancillary chunk type
If no alpha channel nor tRNS chunk is present, all pixels in
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 (
9.4), and Recommendations for Decoders: Alpha channel
(Section 10.8).
2.5.
PNG allows the image data to be filtered before it is compressed
Filtering can improve the compressibility of the data. The
step itself does not reduce the size of the data. All PNG
are strictly lossless
PNG defines several different filter algorithms, including "None
which indicates no filtering. The filter algorithm is
for each scanline by a filter type byte that precedes the
scanline in the precompression datastream. An intelligent
can switch filters from one scanline to the next. The method
choosing which filter to employ is up to the encoder
See Filter Algorithms (Chapter 6) and Rationale:
(Section 12.9).
2.6. Interlaced data
A PNG image can be stored in interlaced order to allow
display. The purpose of this feature is to allow images to "
in" when they are being displayed on-the-fly.
slightly expands the file size on average, but it gives the user
meaningful display much more rapidly. Note that decoders
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
actually perform progressive display
With interlace method 0, pixels are stored sequentially from
to right, and scanlines sequentially from top to bottom (
interlacing).
Interlace method 1, known as Adam7 after its author, Adam M
Costello, consists of seven distinct passes over the image.
pass transmits a subset of the pixels in the image. The pass
which each pixel is transmitted is defined by replicating
following 8-by-8 pattern over the entire image, starting at
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
right within a scanline, and selected scanlines sequentially
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
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
image of the appropriate dimensions. For example, if the
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
of bytes (see Image layout, Section 2.3). Filtering is done
this reduced image in the usual way, and a filter type byte
transmitted before each of its scanlines (see Filter Algorithms
Chapter 6). Notice that the transmission order is defined so
all the scanlines transmitted in a pass will have the same
of pixels; this is necessary for proper application of some of
filters
Caution: If the image contains fewer than five columns or
than five rows, some passes will be entirely empty. Encoders
decoders must handle this case correctly. In particular,
type bytes are only associated with nonempty scanlines; no
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
Decoders: Progressive display (Section 10.9).
2.7. Gamma
PNG images can specify, via the gAMA chunk, the
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
lighting, to present the image to the viewer in a way
reproduces what the image's original author saw as closely
possible. See Gamma Tutorial (Chapter 13) if you aren't
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
data in a PNG image can be specified via the cHRM chunk,
more accurate color matching than gamma correction alone
provide. See Color Tutorial (Chapter 14) if you aren't
familiar with color representation issues
See Rationale: Why gamma? (Section 12.7), Recommendations
Encoders: Encoder gamma handling (Section 9.2),
Recommendations for Decoders: Decoder gamma handling (
10.5).
2.8. Text
A PNG file can store text associated with the image, such as
image description or copyright notice. Keywords are used
indicate what each text string represents
ISO 8859-1 (Latin-1) is the character set recommended for use
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,
they have no platform-independent meaning. If a non-Latin-1
does appear in a PNG text string, its interpretation will
across platforms and decoders. Some systems might not even
able to display all the characters in Latin-1, but most
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
A PNG file consists of a PNG signature followed by a series
chunks. This chapter defines the signature and the basic
of chunks. Individual chunk types are discussed in the next chapter
3.1. PNG file
The first eight bytes of a PNG file always contain the
(decimal) values
137 80 78 71 13 10 26 10
This signature indicates that the remainder of the file contains
single PNG image, consisting of a series of chunks beginning
an IHDR chunk and ending with an IEND chunk
See Rationale: PNG file signature (Section 12.11).
3.2. Chunk
Each chunk consists of four parts
A 4-byte unsigned integer giving the number of bytes in
chunk's data field. The length counts only the data field,
itself, the chunk type code, or the CRC. Zero is a
length. Although encoders and decoders should treat the
as unsigned, its value must not exceed (2^31)-1 bytes
Chunk
A 4-byte chunk type code. For convenience in description
in examining PNG files, type codes are restricted to consist
uppercase and lowercase ASCII letters (A-Z and a-z, or 65-90
and 97-122 decimal). However, encoders and decoders must
the codes as fixed binary values, not character strings.
example, it would not be correct to represent the type
IDAT by the EBCDIC equivalents of those letters.
naming conventions for chunk types are discussed in the
section
Chunk
The data bytes appropriate to the chunk type, if any.
field can be of zero length
Boutell, et. al. Informational [Page 11]
RFC 2083 PNG: Portable Network Graphics March 1997
A 4-byte CRC (Cyclic Redundancy Check) calculated on
preceding bytes in the chunk, including the chunk type code
chunk data fields, but not including the length field. The
is always present, even for chunks containing no data. See
algorithm (Section 3.4).
The chunk data length can be any number of bytes up to
maximum; therefore, implementors cannot assume that chunks
aligned on any boundaries larger than bytes
Chunks can appear in any order, subject to the restrictions
on each chunk type. (One notable restriction is that IHDR
appear first and IEND must appear last; thus the IEND chunk
as an end-of-file marker.) Multiple chunks of the same type
appear, but only if specifically permitted for that type
See Rationale: Chunk layout (Section 12.12).
3.3. Chunk naming
Chunk type codes are assigned so that a decoder can determine
properties of a chunk even when it does not recognize the
code. These rules are intended to allow safe, flexible
of the PNG format, by allowing a decoder to decide what to do
it encounters an unknown chunk. The naming rules are not
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
human can read off the assigned properties according to
each letter of the type code is uppercase (bit 5 is 0)
lowercase (bit 5 is 1). However, decoders should test
properties of an unknown chunk by numerically testing
specified bits; testing whether a character is uppercase
lowercase is inefficient, and even incorrect if a locale-
case definition is used
It is worth noting that the property bits are an inherent part
the chunk name, and hence are fixed for any chunk type. Thus
TEXT and Text would be unrelated chunk type codes, not the
chunk with different properties. Decoders must recognize
codes by a simple four-byte literal comparison; it is incorrect
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
0 (uppercase) = critical, 1 (lowercase) = ancillary
Chunks that are not strictly necessary in order to
display the contents of the file are known as "ancillary
chunks. A decoder encountering an unknown chunk in which
ancillary bit is 1 can safely ignore the chunk and proceed
display the image. The time chunk (tIME) is an example of
ancillary chunk
Chunks that are necessary for successful display of the file'
contents are called "critical" chunks. A decoder
an unknown chunk in which the ancillary bit is 0 must
to the user that the image contains information it
safely interpret. The image header chunk (IHDR) is an
of a critical chunk
Private bit: bit 5 of second
0 (uppercase) = public, 1 (lowercase) = private
A public chunk is one that is part of the PNG specification
is registered in the list of PNG special-purpose public
types. Applications can also define private (unregistered
chunks for their own purposes. The names of private
must have a lowercase second letter, while public chunks
always be assigned names with uppercase second letters.
that decoders do not need to test the private-chunk
bit, since it has no functional significance; it is simply
administrative convenience to ensure that public and
chunk names will not conflict. See Additional chunk
(Section 4.4) and Recommendations for Encoders: Use of
chunks (Section 9.8).
Reserved bit: bit 5 of third
Must be 0 (uppercase) in files conforming to this version
PNG
The significance of the case of the third letter of the
name is reserved for possible future expansion. At the
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
define a meaning for this bit. It is sufficient to treat
chunk with a lowercase third letter in the same way as
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
0 (uppercase) = unsafe to copy, 1 (lowercase) = safe to copy
This property bit is not of interest to pure decoders, but
is needed by PNG editors (programs that modify PNG files).
This bit defines the proper handling of unrecognized chunks
a file that is being modified
If a chunk's safe-to-copy bit is 1, the chunk may be copied
a modified PNG file whether or not the software recognizes
chunk type, and regardless of the extent of the
modifications
If a chunk's safe-to-copy bit is 0, it indicates that the
depends on the image data. If the program has made any
to critical chunks, including addition, modification, deletion
or reordering of critical chunks, then unrecognized
chunks must not be copied to the output PNG file. (Of course
if the program does recognize the chunk, it can choose
output an appropriately modified version.)
A PNG editor is always allowed to copy all unrecognized
if it has only added, deleted, modified, or reordered
chunks. This implies that it is not permissible for
chunks to depend on other ancillary chunks
PNG editors that do not recognize a critical chunk must
an error and refuse to process that PNG file at all.
safe/unsafe mechanism is intended for use with
chunks. The safe-to-copy bit will always be 0 for
chunks
Rules for PNG editors are discussed further in Chunk
Rules (Chapter 7).
For example, the hypothetical chunk type name "bLOb" has
property bits
bLOb <-- 32 bit chunk type code represented in text
||||
|||+- 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-
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
Chunk CRCs are calculated using standard CRC methods with pre
post conditioning, as defined by ISO 3309 [ISO-3309] or ITU-T V.42
[ITU-V42]. The CRC polynomial employed
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
data from each byte is processed from the least significant
(1) to the most significant bit (128). After all the data
are processed, the CRC register is inverted (its ones
is taken). This value is transmitted (stored in the file)
first. For the purpose of separating into bytes and ordering,
least significant bit of the 32-bit CRC is defined to be
coefficient of the x^31 term
Practical calculation of the CRC always employs a
table to greatly accelerate the computation. See Sample CRC
(Chapter 15).
4. Chunk
This chapter defines the standard types of PNG chunks
4.1. Critical
All implementations must understand and successfully render
standard critical chunks. A valid PNG image must contain an
chunk, one or more IDAT chunks, and an IEND chunk
4.1.1. IHDR Image
The IHDR chunk must appear FIRST. It contains
Width: 4
Height: 4
Bit depth: 1
Color type: 1
Compression method: 1
Filter method: 1
Interlace method: 1
Boutell, et. al. Informational [Page 15]
RFC 2083 PNG: Portable Network Graphics March 1997
Width and height give the image dimensions in pixels. They
4-byte integers. Zero is an invalid value. The maximum for
is (2^31)-1 in order to accommodate languages that
difficulty with unsigned 4-byte values
Bit depth is a single-byte integer giving the number of
per sample or per palette index (not per pixel). Valid
are 1, 2, 4, 8, and 16, although not all values are allowed
all color types
Color type is a single-byte integer that describes
interpretation of the image data. Color type codes
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
simplify implementations and to prohibit combinations that
not compress well. Decoders must support all
combinations of bit depth and color type. The
combinations are
Color Allowed
Type Bit
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
case of color type 3, in which the sample depth is always 8
bits
Compression method is a single-byte integer that indicates
method used to compress the image data. At present,
compression method 0 (deflate/inflate compression with a 32
sliding window) is defined. All standard PNG images must
compressed with this scheme. The compression method field
provided for possible future expansion or proprietary variants
Decoders must check this byte and report an error if it
Boutell, et. al. Informational [Page 16]
RFC 2083 PNG: Portable Network Graphics March 1997
an unrecognized code. See Deflate/Inflate Compression (
5) for details
Filter method is a single-byte integer that indicates
preprocessing method applied to the image data
compression. At present, only filter method 0 (
filtering with five basic filter types) is defined. As
the compression method field, decoders must check this byte
report an error if it holds an unrecognized code. See
Algorithms (Chapter 6) for details
Interlace method is a single-byte integer that indicates
transmission order of the image data. Two values are
defined: 0 (no interlace) or 1 (Adam7 interlace).
Interlaced data order (Section 2.6) for details
4.1.2. PLTE
The PLTE chunk contains from 1 to 256 palette entries, each
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.
chunk length not divisible by 3 is an error
This chunk must appear for color type 3, and can appear
color types 2 and 6; it must not appear for color types 0
4. If this chunk does appear, it must precede the first
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,
second by pixel value 1, etc. The number of palette
must not exceed the range that can be represented in the
bit depth (for example, 2^4 = 16 for a bit depth of 4). It
permissible to have fewer entries than the bit depth
allow. In that case, any out-of-range pixel value found in
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
suggested set of from 1 to 256 colors to which the
image can be quantized if the viewer cannot display
directly. If PLTE is not present, such a viewer will need
select colors on its own, but it is often preferable for
Boutell, et. al. Informational [Page 17]
RFC 2083 PNG: Portable Network Graphics March 1997
to be done once by the encoder. (See Recommendations
Encoders: Suggested palettes, Section 9.5.)
Note that the palette uses 8 bits (1 byte) per
regardless of the image bit depth specification.
particular, the palette is 8 bits deep even when it is
suggested quantization of a 16-bit truecolor image
There is no requirement that the palette entries all be used
the image, nor that they all be different
4.1.3. IDAT Image
The IDAT chunk contains the actual image data. To create
data
* Begin with image scanlines represented as described
Image layout (Section 2.3); the layout and total size
this raw data are determined by the fields of IHDR
* Filter the image data according to the filtering
specified by the IHDR chunk. (Note that with
method 0, the only one currently defined, this
prepending a filter type byte to each scanline.)
* Compress the filtered data using the compression
specified by the IHDR chunk
The IDAT chunk contains the output datastream of
compression algorithm
To read the image data, reverse this process
There can be multiple IDAT chunks; if so, they must
consecutively with no other intervening chunks. The
datastream is then the concatenation of the contents of all
IDAT chunks. The encoder can divide the compressed
into IDAT chunks however it wishes. (Multiple IDAT chunks
allowed so that encoders can work in a fixed amount of memory
typically the chunk size will correspond to the encoder'
buffer size.) It is important to emphasize that IDAT
boundaries have no semantic significance and can occur at
point in the compressed datastream. A PNG file in which
IDAT chunk contains only one data byte is legal,
remarkably wasteful of space. (For that matter, zero-
IDAT chunks are legal, though even more wasteful.)
See Filter Algorithms (Chapter 6) and Deflate/
Compression (Chapter 5) for details
Boutell, et. al. Informational [Page 18]
RFC 2083 PNG: Portable Network Graphics March 1997
4.1.4. IEND Image
The IEND chunk must appear LAST. It marks the end of the
datastream. The chunk's data field is empty
4.2. Ancillary
All ancillary chunks are optional, in the sense that encoders
not write them and decoders can ignore them. However,
are encouraged to write the standard ancillary chunks when
information is available, and decoders are encouraged to
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
file
4.2.1. bKGD Background
The bKGD chunk specifies a default background color to
the image against. Note that viewers are not bound to
this chunk; a viewer can choose to use a different background
For color type 3 (indexed color), the bKGD chunk contains
Palette index: 1
The value is the palette index of the color to be used
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
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
image bit depth.) This is the RGB color to be used
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 (
10.7).
4.2.2. cHRM Primary chromaticities and white
Applications that need device-independent specification
colors in a PNG file can use the cHRM chunk to specify the 1931
CIE x,y chromaticities of the red, green, and blue
used in the image, and the referenced white point. See
Tutorial (Chapter 14) for more information
The cHRM chunk contains
White Point x: 4
White Point y: 4
Red x: 4
Red y: 4
Green x: 4
Green y: 4
Blue x: 4
Blue y: 4
Each value is encoded as a 4-byte unsigned integer
representing the x or y value times 100000. For example,
value of 0.3127 would be stored as the integer 31270.
cHRM is allowed in all PNG files, although it is of
value for grayscale images
If the encoder does not know the chromaticity values, it
not write a cHRM chunk; the absence of a cHRM chunk
that the image's primary colors are device-dependent
If the cHRM chunk appears, it must precede the first
chunk, and it must also precede the PLTE chunk if present
See Recommendations for Encoders: Encoder color
(Section 9.3), and Recommendations for Decoders: Decoder
handling (Section 10.6).
Boutell, et. al. Informational [Page 20]
RFC 2083 PNG: Portable Network Graphics March 1997
4.2.3. gAMA Image
The gAMA chunk specifies the gamma of the camera (or
camera) that produced the image, and thus the gamma of
image with respect to the original scene. More precisely,
gAMA chunk encodes the file_gamma value, as defined in
Tutorial (Chapter 13).
The gAMA chunk contains
Image gamma: 4
The value is encoded as a 4-byte unsigned integer,
gamma times 100000. For example, a gamma of 0.45 would
stored as the integer 45000.
If the encoder does not know the image's gamma value, it
not write a gAMA chunk; the absence of a gAMA chunk
that the gamma is unknown
If the gAMA chunk appears, it must precede the first
chunk, and it must also precede the PLTE chunk if present
See Gamma correction (Section 2.7), Recommendations
Encoders: Encoder gamma handling (Section 9.2),
Recommendations for Decoders: Decoder gamma handling (
10.5).
4.2.4. hIST Image
The hIST chunk gives the approximate usage frequency of
color in the color palette. A histogram chunk can appear
when a palette chunk appears. If a viewer is unable to
all the colors listed in the palette, the histogram may help
decide how to choose a subset of the colors for display
The hIST chunk contains a series of 2-byte (16 bit)
integers. There must be exactly one entry for each entry
the PLTE chunk. Each entry is proportional to the fraction
pixels in the image that have that palette index; the
scale factor is chosen by the encoder
Histogram entries are approximate, with the exception that
zero entry specifies that the corresponding palette entry
not used at all in the image. It is required that a
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
image, the histogram is necessarily approximate, since
decoder may map pixels to palette entries differently than
encoder did. In this situation, zero entries should
appear
The hIST chunk, if it appears, must follow the PLTE chunk,
must precede the first IDAT chunk
See Rationale: Palette histograms (Section 12.14),
Recommendations for Decoders: Suggested-palette and
usage (Section 10.10).
4.2.5. pHYs Physical pixel
The pHYs chunk specifies the intended pixel size or
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
The following values are legal for the unit specifier
0: unit is
1: unit is the
When the unit specifier is 0, the pHYs chunk defines
aspect ratio only; the actual size of the pixels
unspecified
Conversion note: one inch is equal to exactly 0.0254 meters
If this ancillary chunk is not present, pixels are assumed
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 (
10.2).
4.2.6. sBIT Significant
To simplify decoders, PNG specifies that only certain
depths can be used, and further specifies that sample
should be scaled to the full range of possible values at
sample depth. However, the sBIT chunk is provided in order
store the original number of significant bits. This
Boutell, et. al. Informational [Page 22]
RFC 2083 PNG: Portable Network Graphics March 1997
decoders to recover the original data losslessly even if
data had a sample depth not directly supported by PNG.
recommend that an encoder emit an sBIT chunk if it
converted the data from a lower sample depth
For color type 0 (grayscale), the sBIT chunk contains a
byte, indicating the number of bits that were significant
the source data
For color type 2 (truecolor), the sBIT chunk contains
bytes, indicating the number of bits that were significant
the source data for the red, green, and blue channels
respectively
For color type 3 (indexed color), the sBIT chunk contains
bytes, indicating the number of bits that were significant
the source data for the red, green, and blue components of
palette entries, respectively
For color type 4 (grayscale with alpha channel), the sBIT
contains two bytes, indicating the number of bits that
significant in the source grayscale data and the source
data, respectively
For color type 6 (truecolor with alpha channel), the sBIT
contains four bytes, indicating the number of bits that
significant in the source data for the red, green, blue
alpha channels, respectively
Each depth specified in sBIT must be greater than zero and
than or equal to the sample depth (which is 8 for indexed-
images, and the bit depth given in IHDR for other color types).
A decoder need not pay attention to sBIT: the stored image is
valid PNG file of the sample depth indicated by IHDR. However
if the decoder wishes to recover the original data at
original precision, this can be done by right-shifting
stored samples (the stored palette entries, for an indexed
color image). The encoder must scale the data in such a
that the high-order bits match the original data
If the sBIT chunk appears, it must precede the first
chunk, and it must also precede the PLTE chunk if present
See Recommendations for Encoders: Sample depth scaling (
9.1) and Recommendations for Decoders: Sample depth
(Section 10.4).
Boutell, et. al. Informational [Page 23]
RFC 2083 PNG: Portable Network Graphics March 1997
4.2.7. tEXt Textual
Textual information that the encoder wishes to record with
image can be stored in tEXt chunks. Each tEXt chunk contains
keyword and a text string, in the format
Keyword: 1-79 bytes (character string
Null separator: 1
Text: n bytes (character string
The keyword and text string are separated by a zero byte (
character). Neither the keyword nor the text string
contain a null character. Note that the text string is
null-terminated (the length of the chunk is
information to locate the ending). The keyword must be
least one character and less than 80 characters long. The
string can be of any length from zero bytes up to the
permissible chunk size less the length of the keyword
separator
Any number of tEXt chunks can appear, and more than one
the same keyword is permissible
The keyword indicates the type of information represented
the text string. The following keywords are predefined
should be used where appropriate
Title Short (one line) title or caption for
Author Name of image's
Description Description of image (possibly long
Copyright Copyright
Creation Time Time of original image
Software Software used to create the
Disclaimer Legal
Warning Warning of nature of
Source Device used to create the
Comment Miscellaneous comment; conversion
GIF
For the Creation Time keyword, the date format defined
section 5.2.14 of RFC 1123 is suggested, but not
[RFC-1123]. Decoders should allow for free-format
associated with this or any other keyword
Other keywords may be invented for other purposes. Keywords
general interest can be registered with the maintainers of
PNG specification. However, it is also permitted to
private unregistered keywords. (Private keywords should
Boutell, et. al. Informational [Page 24]
RFC 2083 PNG: Portable Network Graphics March 1997
reasonably self-explanatory, in order to minimize the
that the same keyword will be used for incompatible purposes
different people.)
Both keyword and text are interpreted according to the
8859-1 (Latin-1) character set [ISO-8859]. The text string
contain any Latin-1 character. Newlines in the text
should be represented by a single linefeed character (
10); use of other control characters in the text
discouraged
Keywords must contain only printable Latin-1 characters
spaces; that is, only character codes 32-126 and 161-255
decimal are allowed. To reduce the chances for
misreading of a keyword, leading and trailing spaces
forbidden, as are consecutive spaces. Note also that the non
breaking space (code 160) is not permitted in keywords,
it is visually indistinguishable from an ordinary space
Keywords must be spelled exactly as registered, so
decoders can use simple literal comparisons when looking
particular keywords. In particular, keywords are
case-sensitive
See Recommendations for Encoders: Text chunk
(Section 9.7) and Recommendations for Decoders: Text
processing (Section 10.11).
4.2.8. tIME Image last-modification
The tIME chunk gives the time of the last image
(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
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-
time stamp that is updated whenever the image data is changed
It is recommended that tIME not be changed by PNG editors
do not change the image data. See also the Creation Time
keyword, which can be used for a user-supplied time
4.2.9. tRNS
The tRNS chunk specifies that the image uses
transparency: either alpha values associated with
entries (for indexed-color images) or a single
color (for grayscale and truecolor images). Although
transparency is not as elegant as the full alpha channel,
requires less storage space and is sufficient for many
cases
For color type 3 (indexed color), the tRNS chunk contains
series of one-byte alpha values, corresponding to entries
the PLTE chunk
Alpha for palette index 0: 1
Alpha for palette index 1: 1
... etc ...
Each entry indicates that pixels of the corresponding
index must be treated as having the specified alpha value
Alpha values have the same interpretation as in an 8-bit
alpha channel: 0 is fully transparent, 255 is fully opaque
regardless of image bit depth. The tRNS chunk must not
more alpha values than there are palette entries, but tRNS
contain fewer values than there are palette entries. In
case, the alpha value for all remaining palette entries
assumed to be 255. In the common case in which only
index 0 need be made transparent, only a one-byte tRNS chunk
needed
For color type 0 (grayscale), the tRNS chunk contains a
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
depth.) Pixels of the specified gray level are to be treated
transparent (equivalent to alpha value 0); all other pixels
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
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
image bit depth.) Pixels of the specified color value are to
treated as transparent (equivalent to alpha value 0); all
pixels are to be treated as fully opaque (alpha
(2^bitdepth)-1).
tRNS is prohibited for color types 4 and 6, since a full
channel is already present in those cases
Note: when dealing with 16-bit grayscale or truecolor data,
is important to compare both bytes of the sample values
determine whether a pixel is transparent. Although
may drop the low-order byte of the samples for display,
must not occur until after the data has been tested
transparency. For example, if the grayscale level 0x0001
specified to be transparent, it would be incorrect to
only the high-order byte and decide that 0x0002 is
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
The zTXt chunk contains textual data, just as tEXt does
however, zTXt takes advantage of compression. zTXt and
chunks are semantically equivalent, but zTXt is recommended
storing large blocks of text
A zTXt chunk contains
Keyword: 1-79 bytes (character string
Null separator: 1
Compression method: 1
Compressed text: n
The keyword and null separator are exactly the same as in
tEXt chunk. Note that the keyword is not compressed.
compression method byte identifies the compression method
in this zTXt chunk. The only value presently defined for it
0 (deflate/inflate compression). The compression method byte
Boutell, et. al. Informational [Page 27]
RFC 2083 PNG: Portable Network Graphics March 1997
followed by a compressed datastream that makes up the
of the chunk. For compression method 0, this
adheres to the zlib datastream format (see Deflate/
Compression, Chapter 5). Decompression of this
yields Latin-1 text that is identical to the text that would
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
predefined keywords and the recommended format of the text
See Recommendations for Encoders: Text chunk
(Section 9.7), and Recommendations for Decoders: Text
processing (Section 10.11).
4.3. Summary of standard
This table summarizes some properties of the standard chunk types
Critical chunks (must appear in this order, except
is optional):
Name Multiple Ordering
OK
IHDR No Must be
PLTE No Before
IDAT Yes Multiple IDATs must be
IEND No Must be
Ancillary chunks (need not appear in this order):
Name Multiple Ordering
OK
cHRM No Before PLTE and
gAMA No Before PLTE and
sBIT No Before PLTE and
bKGD No After PLTE; before
hIST No After PLTE; before
tRNS No After PLTE; before
pHYs No Before
tIME No
tEXt Yes
zTXt Yes
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
Author Name of image's
Description Description of image (possibly long
Copyright Copyright
Creation Time Time of original image
Software Software used to create the
Disclaimer Legal
Warning Warning of nature of
Source Device used to create the
Comment Miscellaneous comment; conversion
GIF
4.4. Additional chunk
Additional public PNG chunk types are defined in the document "
Special-Purpose Public Chunks" [PNG-EXTENSIONS]. Chunks
there are expected to be less widely supported than those
in this specification. However, application authors
encouraged to use those chunk types whenever appropriate for
applications. Additional chunk types can be proposed
inclusion in that list by contacting the PNG
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
others and do not violate the design philosophy of PNG.
registration is not automatic, although it is the intent of
authors that it be straightforward when a new chunk of
wide application is needed. Note that the creation of
critical chunk types is discouraged unless absolutely necessary
Applications can also use private chunk types to carry data
is not of interest to other applications. See Recommendations
Encoders: Use of private chunks (Section 9.8).
Decoders must be prepared to encounter unrecognized public
private chunk type codes. Unrecognized chunk types must
handled as described in Chunk naming conventions (Section 3.3).
5. Deflate/Inflate
PNG compression method 0 (the only compression method
defined for PNG) specifies deflate/inflate compression with a 32
sliding window. Deflate compression is an LZ77 derivative used
zip, gzip, pkzip and related programs. Extensive research has
done supporting its patent-free status. Portable C
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
Additional flags/check bits: 1
Compressed data blocks: n
Check value: 4
Further details on this format are given in the zlib
[RFC-1950].
For PNG compression method 0, the zlib compression method/flags
must specify method code 8 ("deflate" compression) and an LZ77
size of not more than 32K. Note that the zlib compression
number is not the same as the PNG compression method number.
additional flags must not specify a preset dictionary
The compressed data within the zlib datastream is stored as a
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
the final block identifies it as the last block, allowing the
to recognize the end of the compressed datastream. Further
on the compression algorithm and the encoding are given in
deflate specification [RFC-1951].
The check value stored at the end of the zlib datastream
calculated on the uncompressed data represented by the datastream
Note that the algorithm used is not the same as the CRC
used for PNG chunk check values. The zlib check value is
mainly as a cross-check that the deflate and inflate algorithms
implemented correctly. Verifying the chunk CRCs provides
confidence that the PNG file has been transmitted undamaged
In a PNG file, the concatenation of the contents of all the
chunks makes up a zlib datastream as specified above.
datastream decompresses to filtered image data as described
in this document
It is important to emphasize that the boundaries between IDAT
are arbitrary and can fall anywhere in the zlib datastream. There
not necessarily any correlation between IDAT chunk boundaries
deflate block boundaries or any other feature of the zlib data.
example, it is entirely possible for the terminating zlib check
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
structure of the image data (i.e., scanline boundaries) and
block boundaries or IDAT chunk boundaries. The complete image
is represented by a single zlib datastream that is stored in
number of IDAT chunks; a decoder that assumes any more than this
incorrect. (Of course, some encoder implementations may emit
in which some of these structures are indeed related. But
cannot rely on this.)
PNG also uses zlib datastreams in zTXt chunks. In a zTXt chunk,
remainder of the chunk following the compression method byte is
zlib datastream as specified above. This datastream decompresses
the user-readable text described by the chunk's keyword. Unlike
image data, such datastreams are not split across chunks; each
chunk contains an independent zlib datastream
Additional documentation and portable C code for deflate and
are available from the Info-ZIP archives
archiving/zip/>.
6. Filter
This chapter describes the filter algorithms that can be
before compression. The purpose of these filters is to prepare
image data for optimum compression
6.1. Filter
PNG filter method 0 defines five basic filter types
Type
0
1
2
3
4
(Note that filter method 0 in IHDR specifies exactly this set
five filter types. If the set of filter types is ever extended,
different filter method number will be assigned to the
set, so that decoders need not decompress the data to
that it contains unsupported filter types.)
The encoder can choose which of these filter algorithms to
on a scanline-by-scanline basis. In the image data sent to
compression step, each scanline is preceded by a filter type
that specifies the filter algorithm used for that scanline
Boutell, et. al. Informational [Page 31]
RFC 2083 PNG: Portable Network Graphics March 1997
Filtering algorithms are applied to bytes, not to pixels
regardless of the bit depth or color type of the image.
filtering algorithms work on the byte sequence formed by
scanline that has been represented as described in Image
(Section 2.3). If the image includes an alpha channel, the
data is filtered in the same way as the image data
When the image is interlaced, each pass of the interlace
is treated as an independent image for filtering purposes.
filters work on the byte sequences formed by the pixels
transmitted during a pass, and the "previous scanline" is the
previously transmitted in the same pass, not the one adjacent
the complete image. Note that the subimage transmitted in any
pass is always rectangular, but is of smaller width and/or
than the complete image. Filtering is not applied when
subimage is empty
For all filters, the bytes "to the left of" the first pixel in
scanline must be treated as being zero. For filters that refer
the prior scanline, the entire prior scanline must be treated
being zeroes for the first scanline of an image (or of a pass
an interlaced image).
To reverse the effect of a filter, the decoder must use
decoded values of the prior pixel on the same line, the
immediately above the current pixel on the prior line, and
pixel just to the left of the pixel above. This implies that
least one scanline's worth of image data will have to be stored
the decoder at all times. Even though some filter types do
refer to the prior scanline, the decoder will always need to
each scanline as it is decoded, since the next scanline might
a filter that refers to it
PNG imposes no restriction on which filter types can be applied
an image. However, the filters are not equally effective on
types of data. See Recommendations for Encoders: Filter
(Section 9.6).
See also Rationale: Filtering (Section 12.9).
6.2. Filter type 0:
With the None filter, the scanline is transmitted unmodified;
is only necessary to insert a filter type byte before the data
Boutell, et. al. Informational [Page 32]
RFC 2083 PNG: Portable Network Graphics March 1997
6.3. Filter type 1:
The Sub filter transmits the difference between each byte and
value of the corresponding byte of the prior pixel
To compute the Sub filter, apply the following formula to
byte of the scanline
Sub(x) = Raw(x) - Raw(x-bpp
where x ranges from zero to the number of bytes representing
scanline minus one, Raw(x) refers to the raw data byte at
byte position in the scanline, and bpp is defined as the number
bytes per complete pixel, rounding up to one. For example,
color type 2 with a bit depth of 16, bpp is equal to 6 (
samples, two bytes per sample); for color type 0 with a bit
of 2, bpp is equal to 1 (