%Format: LaTeX

\documentstyle[11pt,twoside]{article}

%% --- settings for paper size ---
%% Uncomment the desired section by removing the
%% percent signs (%) at the beginning of the lines,
%% and comment out the other section by preceding
%% the lines with percent signs.

%% --- us letter (8.5in x 11in) ---

%\topmargin=-0.4in
%\oddsidemargin=0.3in
%\evensidemargin=-0.3in
%\textwidth=6.48in
%\textheight=9.06in

%% --- a4 (21.0cm x 29.7cm) ---

\topmargin=-0.4in
\oddsidemargin=0.3in
\evensidemargin=-0.3in
\textwidth=6.25in
\textheight=9.75in

%% --- end of paper size settings ---

\sloppy
\parindent=0em
\parskip=1ex plus0.5ex minus0.25ex
\pagestyle{headings}
\setcounter{section}{-1}
\setcounter{tocdepth}{2}
\renewcommand{\thefootnote}{(\arabic{footnote})}
\newcommand{\bverbatim}{%
   \par\vspace{2ex plus0.5ex minus0.25ex}\begingroup\tt\frenchspacing
   \parskip=0ex\baselineskip=3ex plus0.15ex minus0.1ex
   \obeylines\obeyspaces\raggedright
}
\newcommand{\everbatim}{\endgroup\par\vspace{2ex plus0.5ex minus0.25ex}}

\begin{document}
\thispagestyle{empty}


\part*{PNG (Portable Network Graphics) Specification, Tenth Draft}

Revision date: 5 May, 1995

\begin{quote}
  Copyright 1995, Thomas Boutell.
  Permission is granted to reproduce this specification in complete
  and unaltered form. Excerpts may be printed with the
  following notice: ``excerpted from the PNG
  (Portable Network Graphics) specification, tenth draft.''
  No notice is required in software
  that follows this specification; notice is only required
  when reproducing or excerpting from the specification itself.
\end{quote}

\tableofcontents

\section{Status\label{STATUS}}

This is the tenth draft of the PNG specification. 
All future drafts will be backward-compatible with the
graphics file format described by this document.
Implementations are invited, and a reference 
implementation is under development; see below.

\subsection{Archive sites}

The latest versions of this document and related information can
always be found at the PNG FTP archive site,
{\tt ftp.uu.net:/\allowbreak{}graphics/\allowbreak{}png/\allowbreak{}}.
The maintainers of the PNG specification can be contacted by e-mail at
{\tt png-info@uunet.uu.net}.
\par 
At present, this document is available on the World Wide Web from
{\tt http:/\allowbreak{}/\allowbreak{}sunsite.unc.edu/\allowbreak{}boutell/\allowbreak{}png.html},
but this location may not be as permanent as the ones above.

\subsection{Changes since draft 9}

\begin{itemize}
\item  Extensive editing
\item  Clarified interlaced representation of very small images:
no filter bytes are present in an empty pass
\item  Chunk ordering rules clarified
\item  Limits set on {\tt tEXt} chunk keyword length
\item  {\tt cHRM} chunk description corrected: CIE x and y, not X and Y
\item  More extensive explanation of alpha and gamma processing
\item  Separate document created for extension chunk types
\item  Permanent archive site and e-mail contact point established
\end{itemize}

\subsection{Reference implementation}

It is anticipated that a reference implementation
will be available before the end of May 1995.
The reference implementation will be freely usable in all
applications, including commercial applications.
\par 
When finished, the reference implementation will be available from
the PNG FTP archive site,
{\tt ftp.uu.net:/\allowbreak{}graphics/\allowbreak{}png/\allowbreak{}}.
\par 
A set of test images will also be prepared and will be available from
the same site.

\section{Introduction\label{INTRODUCTION}}

The PNG format is intended to provide a portable, legally
unencumbered, well-compressed, well-specified standard for
lossless bitmapped image files.
\par 
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.
\par 

GIF features retained in PNG include:
\begin{itemize}
\item  Palette-mapped images of up to 256 colors.
\item  Streamability: files can be read and written strictly
serially, thus allowing the file format to be used as a communications
protocol for on-the-fly generation and display of images.
\item  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
with gradual improvement of detail thereafter.
\item  Transparency: portions of the image can be marked as transparent,
allowing the effect of a nonrectangular image area to be achieved.
\item  Ancillary information: textual comments and other data can be
stored within the image file.
\item  Complete hardware and platform independence.
\item  Effective, 100\% lossless compression.
\end{itemize}

Important new features of PNG, not available in GIF, include:
\begin{itemize}
\item  Truecolor images of up to 48 bits per pixel.
\item  Grayscale images of up to 16 bits per pixel.
\item  Full alpha channel (general transparency masks).
\item  Image gamma indication, allowing automatic brightness/\allowbreak{}contrast adjustment.
\item  Reliable, straightforward detection of file corruption.
\item  Faster initial presentation in progressive display mode.
\end{itemize}

PNG is intended to be:
\begin{itemize}
\item  Simple and portable: PNG should be widely implementable with
reasonably small effort for developers.
\item  Legally unencumbered: to the best of the knowledge of the PNG
authors, no algorithms under legal challenge are used.
\item  Well compressed: both palette-mapped and truecolor images are
compressed as effectively as in any other widely used lossless format,
and in most cases more effectively.
\item  Interchangeable: any standard-conforming PNG decoder will read
all conforming PNG files.
\item  Flexible: the format allows for future extensions and
private add-ons, without compromising interchangeability of basic PNG.
\item  Robust: the design supports full file integrity checking as well
as simple, quick detection of common transmission errors.
\end{itemize}

The main part of this specification simply gives the definition of
the file format.  An appendix gives the rationale for many design
decisions.  Although the rationale is not part of the formal
specification, reading it may help implementors to understand the design.
Cross-references in the main text point to relevant parts of the
rationale.

\par 
See Rationale:
Why a new file format? (page \pageref{R:WHY A NEW FILE FORMAT?}),
Why these features? (page \pageref{R:WHY THESE FEATURES?}),
Why not these features? (page \pageref{R:WHY NOT THESE FEATURES?}),
Why not use format XYZ? (page \pageref{R:WHY NOT USE FORMAT XYZ?}).

\subsection{Pronunciation}

PNG is pronounced ``ping''.

\section{Data Representation\label{DATAREP}}

This chapter discusses basic data representations used in PNG files,
as well as the expected representation of the image data.

\subsection{Integers and byte order\label{DR:INTEGERS AND BYTE ORDER}}

All integers that require more than one byte will be in network byte
order, which is to say 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.

\par 
See Rationale:
Byte order (page \pageref{R:BYTE ORDER}).

\subsection{Color values\label{DR:COLOR VALUES}}

All color values range from zero (representing black) to most intense
at the maximum value for the bit depth.  Color values may represent
either grayscale or RGB color data.  Note that the maximum value
at a given bit depth is not 2\^{ }bitdepth, but rather (2\^{ }bitdepth)-1.
Intensity is not necessarily linear; the {\tt gAMA} chunk specifies
the gamma characteristic of the source device, and viewers are strongly
encouraged to properly compensate.  See
Gamma correction (page \pageref{DR:GAMMA CORRECTION}), below.
\par 
Source data with a precision not directly
supported in PNG (for example, 5 bit/\allowbreak{}sample truecolor) must be scaled
up to the next higher supported bit depth.  Such scaling is reversible
and hence incurs no loss of data, while it reduces the number of cases
that decoders must cope with.
See Recommendations for Encoders:
Bitdepth scaling (page \pageref{E:BITDEPTH SCALING}).

\subsection{Image layout\label{DR:IMAGE LAYOUT}}

PNG images are laid out as 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 not actually be transmitted in this order; see
Interlaced data order (page \pageref{DR:INTERLACED DATA ORDER}).)
The size of each pixel is determined by the {\em bit depth},
which is the number of bits per stored value in the image data.
\par 
Three types of pixels are supported:
\begin{itemize}
\item  Palette-mapped pixels are represented by a single value that is
an index into a supplied palette.  The bit depth determines the
maximum number of palette entries, not the color precision within the
palette.
\item  Grayscale pixels are represented by a single value that is a
grayscale level, where zero is black and the largest value for the
bit depth is white.
\item  Truecolor pixels are represented by three-value sequences:
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 value, not the total pixel size.
\end{itemize}
\par 
Optionally, grayscale and truecolor pixels can also include an alpha
value, as described in the next section.
\par 
In all cases, pixels are packed into scanlines consecutively, without
wasted space between pixels.  (The allowable bit depths are restricted
so that the packing is simple and efficient.)  When pixels are less
than 8 bits deep, they are packed into bytes with the leftmost
pixel in the high-order bits of a byte, the rightmost in the low-order
bits.
\par 
However, scanlines always begin on byte boundaries.  When pixels are
less than 8 bits deep, if the scanline width is not evenly divisible
by the number of pixels per byte then the low-order bits in the last
byte of each scanline are wasted.  The contents of the padding bits
added to fill out the last byte of a scanline are unspecified.
\par 
An additional ``filter'' byte is added to the beginning of every scanline,
as described in detail below.  The filter byte
is not considered part of the image data, but it is included in the
data stream sent to the compression step.

\subsection{Alpha channel\label{DR:ALPHA CHANNEL}}

An alpha channel, representing transparency levels on a per-pixel
basis, may be included in grayscale and truecolor PNG images.
\par 
An alpha channel value of 0 represents full transparency, and a value
of (2\^{ }bitdepth)-1 represents a fully opaque pixel.  Intermediate values 
indicate partially transparent pixels that may be combined with a background
image to yield a composite image.
\par 
Alpha channels may 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 values are represented with the same bit depth used for
the image values.  The alpha value is stored immediately following the
grayscale or RGB values of the pixel.
\par 
The color stored for a pixel is 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
pixel values premultiplied by the alpha fraction; in effect, the image
is already composited against a black background.  PNG does
{\em not} use premultiplied alpha.)
\par 
Transparency control is also possible without the storage cost of a
full alpha channel.  In a palette image,
an alpha value may be defined for each palette entry.  In
grayscale and truecolor images, a single
pixel value may be identified as being ``transparent''.  These
techniques are controlled by the {\tt tRNS} ancillary chunk type.
\par 
If no alpha channel nor {\tt tRNS} chunk is present, all pixels in
the image are to be treated as fully opaque.
\par 
Viewers may support transparency control partially, or not at all.
\par 
See Rationale:
Non-premultiplied alpha (page \pageref{R:NON-PREMULTIPLIED ALPHA}),
Recommendations for Encoders:
Alpha channel creation (page \pageref{E:ALPHA CHANNEL CREATION}),
and Recommendations for Decoders:
Alpha channel processing (page \pageref{D:ALPHA CHANNEL PROCESSING}).

\subsection{Filtering\label{DR:FILTERING}}

PNG allows the image data to be {\em filtered} before it is
compressed.  The purpose of filtering is to improve the compressibility
of the data.  The filter step itself does not reduce the size of the
data.  All PNG filters are strictly lossless.
\par 
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 which precedes the filtered
scanline in the precompression data stream.  An intelligent encoder
may switch filters from one scanline to the next.  The method for
choosing which filter to employ is up to the encoder.
\par 
See Filter Algorithms (page \pageref{FILTERS})
and Rationale:
Filtering (page \pageref{R:FILTERING}).

\subsection{Interlaced data order\label{DR:INTERLACED DATA ORDER}}

A PNG image can be stored in interlaced order to allow progressive
display.  The purpose of this feature is to allow images to ``fade
in'' when they are being displayed on-the-fly.  Interlacing slightly
expands the file size on average, but it gives the user a meaningful
display much more rapidly. 
Note that decoders are required to be able to read interlaced images,
whether or not they actually perform progressive display.
\par 
With interlace type 0, pixels are stored sequentially from left to right,
and scanlines sequentially from top to bottom (no interlacing).
\par 
Interlace type 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:
\bverbatim 
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
\everbatim 
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.
\par 
{\bf 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 8x8 pixels, then pass 3 will
contain a single scanline containing two pixels.  When pixels are
less than 8 bits deep, each such scanline is padded to fill an
integral number of bytes (see Image layout (page \pageref{DR:IMAGE LAYOUT})).
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 (page \pageref{FILTERS})).  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.
\par 
{\bf Caution:} If the image contains fewer than five columns
or fewer than five rows, some passes will be entirely empty.  Encoder
and decoder authors must be careful to handle this case correctly.
In particular, filter bytes are only associated with nonempty
scanlines; no filter bytes are present in an empty pass.

\par 
See Rationale:
Interlacing (page \pageref{R:INTERLACING})
and Recommendations for Decoders:
Progressive display (page \pageref{D:PROGRESSIVE DISPLAY}).

\subsection{Gamma correction\label{DR:GAMMA CORRECTION}}

Gamma is a way of defining the brightness reproduction curve of a camera or
display device.  When brightness levels are expressed as fractions in
the range 0 to 1, such a device produces an output brightness level
``{\tt obright}'' from an input brightness level ``{\tt ibright}''
according to the equation
\bverbatim 
\verb|  |obright = ibright \^{ } gamma
\everbatim 
PNG images may specify 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.  To get accurate tone
reproduction, the gamma of the display device and the gamma of the
image file should be reciprocals of each other, since the overall
gamma of the system is the product of the gammas of each component.
So, for example, if an image with a gamma of 0.4 is displayed on a CRT
with a gamma of 2.5, the overall gamma of the system is 1.0.  An
overall gamma of 1.0 gives correct tone reproduction.
\par 
In practice, images of gamma around 1.0 and gamma around 0.45 are both
widely found.  PNG expects encoders to record the gamma if known, and
it expects decoders to correct the image gamma if necessary for proper
display on their display hardware.  Failure to correct for image gamma
leads to a too-dark or too-light display.
\par 
Gamma correction is not applied to the alpha channel, if any.
Alpha values always represent a linear fraction of full opacity.

\par 
See Rationale:
Why gamma encoding? (page \pageref{R:WHY GAMMA ENCODING?}),
Recommendations for Encoders:
Encoder gamma handling (page \pageref{E:ENCODER GAMMA HANDLING}),
and Recommendations for Decoders:
Decoder gamma handling (page \pageref{D:DECODER GAMMA HANDLING}).

\subsection{Text strings\label{DR: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.
\par 
ISO 8859-1 (Latin-1) is the character set recommended for use in text
strings.  This character set is a superset of 7-bit ASCII.  Files
defining the character set may be obtained from the PNG FTP archives,
{\tt ftp.uu.net:/\allowbreak{}graphics/\allowbreak{}png/\allowbreak{}}.
\par 
Character codes not defined in Latin-1 may be used, but are unlikely
to port across platforms correctly.  (For that matter, {\em any}
characters beyond 7-bit ASCII will not display correctly on all
platforms; but Latin-1 represents a set which is widely portable.)
\par 
Provision is also made for the storage of compressed text.
\par 
See Rationale:
Text strings (page \pageref{R:TEXT STRINGS}).

\section{File Structure\label{STRUCTURE}}

A PNG file consists of a PNG {\em signature} followed by a series
of {\em chunks}.  This chapter defines the signature and the basic
properties of chunks.  Individual chunk types are discussed in the
next chapter.

\subsection{PNG file signature\label{PNG FILE SIGNATURE}}

The first eight bytes of a PNG file always contain the following
(decimal) values:
\par 
{\tt 137 80 78 71 13 10 26 10}
\par 
This signature indicates that the remainder of the file contains a
single PNG image, consisting of a series of chunks beginning with
an {\tt IHDR} chunk and ending with an {\tt IEND} chunk.

\par 
See Rationale:
PNG file signature (page \pageref{R:PNG FILE SIGNATURE}).

\subsection{Chunk layout\label{CHUNK LAYOUT}}

Each chunk consists of four parts:
\begin{description}
\item[Length
]\leavevmode\par 
A 4-byte unsigned integer giving the number of bytes in the chunk's
data field. The length counts {\em only} the data field,
{\em 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 may not exceed (2\^{ }31)-1 bytes.

\item[Chunk Type
]\leavevmode\par 
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 ({\tt A}-{\tt Z},
{\tt a}-{\tt z}).  However, encoders and decoders should treat
the codes as fixed binary values, not character strings.  For example,
it would not be correct to represent the type code {\tt IDAT} by
the EBCDIC equivalents of those letters.  Additional naming
conventions for chunk types are discussed in the next section.

\item[Chunk Data
]\leavevmode\par 
The data bytes appropriate to the chunk type, if any.
This field may be of zero length.

\item[CRC
]\leavevmode\par 

A 4-byte CRC (Cyclical Redundancy Check) calculated
on the preceding bytes in that chunk, {\bf including} 
the chunk type code and chunk data fields, but {\bf not including}
the length field. The CRC is {\bf always} present, even for 
empty chunks such as {\tt IEND}. The CRC algorithm is specified below.
\end{description}

The chunk data length may be any number of bytes up to the maximum;
therefore, implementors may not assume that chunks are aligned on any
boundaries larger than bytes.
\par 
Chunks may appear in any order, subject to the restrictions placed on
each chunk type.  (One notable restriction is that {\tt IHDR} must
appear first and {\tt IEND} must appear last; thus the
{\tt IEND} chunk serves as an end-of-file marker.)  Multiple chunks
of the same type may appear, but only if specifically permitted for
that type.

\par 
See Rationale:
Chunk layout (page \pageref{R:CHUNK LAYOUT}).

\subsection{Chunk naming conventions\label{CHUNK NAMING CONVENTIONS}}

Chunk type codes are assigned in such a way that a decoder can
determine some properties of a chunk even if 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 a decoder does recognize the chunk's type.
\par 
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.
\par 
It is also worth noting that the property bits are an inherent part of
the chunk name, and hence are fixed for any chunk type.  Thus,
{\tt TEXT} and {\tt Text} are completely unrelated chunk type
codes.  Decoders should recognize codes by simple four-byte literal
comparison; it is incorrect to perform case conversion on type codes.
\par 
The semantics of the property bits are:
\begin{description}
\item[First Byte: 0 (uppercase) = critical, 1 (lowercase) = ancillary
]\leavevmode\par 
Chunks which are not strictly necessary in order to meaningfully
display the contents of the file are known as ``ancillary'' chunks.
Decoders encountering an unknown chunk in which the ancillary bit 
is 1 may safely ignore the chunk and proceed to display the image. The
time chunk ({\tt tIME}) is an example of an ancillary chunk.
\par 
Chunks which are critical to the successful display of the file's
contents are called ``critical'' chunks. Decoders encountering an
unknown chunk in which the ancillary bit is 0 must indicate to the
user that the image contains information they cannot safely interpret.
The image header chunk ({\tt IHDR}) is an example of a critical chunk.
\par 

\item[Second Byte: 0 (uppercase) = public, 1 (lowercase) = private
]\leavevmode\par 
If the chunk is public (part of this specification or a later edition
of this specification), its second letter is uppercase. If your
application requires proprietary chunks, and you have {\em no}
interest in seeing the software of other vendors recognize them, use a
lowercase second letter in the chunk name. Such names will never be
assigned in the official specification.  Note that there is no need
for software to test this property bit; it simply ensures that private
and public chunk names will not conflict.
\par 

\item[Third Byte: reserved, must be 0 (uppercase) always
]\leavevmode\par 
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.
\par 

\item[Fourth Byte: 0 (uppercase) = unsafe to copy, 1 (lowercase) =
safe to copy
]\leavevmode\par 
This property bit is not of interest to pure decoders, but it is
needed by PNG editors (programs that modify a PNG file).
\par 
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.
\par 
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 {\em any}
changes to {\em critical} chunks, including addition, modification,
deletion, or reordering of critical chunks, then unrecognized unsafe
chunks must {\bf not} be copied to the output PNG file.
(Of course, if the program {\bf does} recognize the chunk,
it may choose to output an appropriately modified version.)
\par 
A PNG editor is always allowed to copy all unrecognized chunks
if it has only added, deleted, or modified ancillary chunks.  This
implies that it is not permissible to make ancillary chunks that
depend on other ancillary chunks.
\par 
PNG editors that do not recognize a {\em critical} chunk must
report an error and refuse to process that PNG file at all. The
safe/\allowbreak{}unsafe mechanism is intended for use with ancillary chunks.
The safe-to-copy bit will always be 0 for critical chunks.
\par 
Rules for PNG editors are discussed further under
Chunk Ordering Rules (page \pageref{ORDERING}).
\end{description}
\par 
For example, the hypothetical chunk type name ``{\tt bLOb}'' has the
property bits:
\bverbatim 
\verb|    |bLOb  <-- 32 bit Chunk Name represented in ASCII form
\verb|    |||||
\verb|    ||||'- Safe to copy bit is 1 (lower case letter; bit 5 of byte is 1)
\verb|    |||'-- Reserved bit is 0     (upper case letter; bit 5 of byte is 0)
\verb|    ||'--- Private bit is 0      (upper case letter; bit 5 of byte is 0)
\verb|    |'---- Ancillary bit is 1    (lower case letter; bit 5 of byte is 1)
\everbatim 
Therefore, this name represents an ancillary, public, safe-to-copy chunk.
\par 
See Rationale:
Chunk naming conventions (page \pageref{R:CHUNK NAMING CONVENTIONS}).

\subsection{CRC algorithm\label{CRC ALGORITHM}}

Chunk CRCs are calculated using standard CRC methods with pre and post
conditioning.  The CRC polynomial employed is as follows:
\bverbatim 
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
\everbatim 
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 {\tt x\^{ }31} term.
\par 
Practical calculation of the CRC always employs a precalculated
table to greatly accelerate the computation. See
Appendix: Sample CRC Code (page \pageref{CRCAPPENDIX}).

\section{Chunk Specifications\label{CHUNKS}}

This chapter defines the standard types of PNG chunks.

\subsection{Critical Chunks\label{CRITICAL CHUNKS}}

All implementations must understand and successfully render the
standard critical chunks.  A valid PNG image must contain an
{\tt IHDR} chunk, one or more {\tt IDAT} chunks, and an
{\tt IEND} chunk.

\begin{description}
\item[ {\tt IHDR  }  Image Header
]\leavevmode\par  
This chunk must appear FIRST.  Its contents are:
\bverbatim 
Width:            4 bytes
Height:           4 bytes
Bit depth:        1 byte
Color type:       1 byte 
Compression type: 1 byte
Filter type:      1 byte
Interlace type:   1 byte
\everbatim 
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 which have difficulty with unsigned
4-byte values.
\par 
Bit depth is a single-byte integer giving the number of bits per pixel
(for palette images) or per sample (for grayscale and truecolor images).
Valid values are 1, 2, 4, 8, and 16, although not all values are
allowed for all color types.
\par 
Color type is a single-byte integer that describes the interpretation
of the image data.  Color type values represent sums of the following
values: 1 (palette used), 2 (color used), and 4 (full alpha
used). Valid values are 0, 2, 3, 4, and 6.
\par 
Bit depth restrictions for each color type are imposed both to
simplify implementations and to prohibit certain combinations that do
not compress well in practice.  Decoders must support all legal
combinations of bit depth and color type.  (Note that bit depths of 16
are easily supported on 8-bit display hardware by dropping the least
significant byte.)  The allowed combinations are:
\bverbatim 
Color    Allowed    Interpretation
Type    Bit Depths
\vspace{\baselineskip}
0       1,2,4,8,16  Each pixel value is a grayscale level.
\vspace{\baselineskip}
2       8,16        Each pixel value is an R,G,B series.
\vspace{\baselineskip}
3       1,2,4,8     Each pixel value is a palette index;
\verb|                    |a PLTE chunk must appear.
\vspace{\baselineskip}
4       8,16        Each pixel value is a grayscale level,
\verb|                    |followed by an alpha channel level.
\vspace{\baselineskip}
6       8,16        Each pixel value is an R,G,B series,
\verb|                    |followed by an alpha channel level.
\everbatim 
\par 

Compression type is a single-byte integer that indicates the method
used to compress the image data.  At present, only compression type 0
(deflate/\allowbreak{}inflate compression with a 32K sliding window) is defined.
All standard PNG images must be compressed with this scheme.  The
compression type code is provided for possible future expansion or
proprietary variants.  Decoders must check this byte and report an
error if it holds an unrecognized code.  See
Deflate/\allowbreak{}Inflate Compression (page \pageref{COMPRESSION})
for details.
\par 
Filter type is a single-byte integer that indicates the preprocessing
method applied to the image data before compression.  At present, only
filter type 0 (adaptive filtering with five basic filter types) is
defined.  As with the compression type code,
decoders must check this byte and report an error if it holds an
unrecognized code.
See Filter Algorithms (page \pageref{FILTERS}) for details.
\par 
Interlace type is a single-byte integer that indicates the
transmission order of the pixel data.  Two values are currently
defined: 0 (no interlace) or 1 (Adam7 interlace).  See
Interlaced data order (page \pageref{DR:INTERLACED DATA ORDER}) for details.
\par 

\item[ {\tt PLTE  }  Palette
]\leavevmode\par  
This chunk's contents are from 1 to 256 palette entries, each a
three-byte series of the form:
\bverbatim 
red:   1 byte (0 = black, 255 = red)
green: 1 byte (0 = black, 255 = green)
blue:  1 byte (0 = black, 255 = blue)
\everbatim 
The number of entries is determined from the chunk length.  A chunk
length not divisible by 3 is an error.
\par 
This chunk must appear for color type 3, and
may appear for color types 2 and 6. If this chunk
does appear, it must precede the first {\tt IDAT} chunk.
There cannot be more than one {\tt PLTE} chunk.
\par 
For color type 3 (palette data), the {\tt PLTE} chunk is required.
The first entry in {\tt 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 by the 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.
\par 
For color types 2 and 6 (truecolor), the {\tt PLTE} chunk is
optional.  If present, it provides a recommended set of from 1 to 256
colors to which the truecolor image may be quantized if the viewer
cannot display truecolor directly.  If {\tt PLTE} is not present,
such a viewer must select colors on its own, but it is often
preferable for this to be done once by the encoder.
\par 
Note that the palette uses 8 bits (1 byte) per value 
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.

\par 
\item[ {\tt IDAT  }  Image Data
]\leavevmode\par  
This chunk contains the actual image data.  To create this data, begin
with image scanlines represented as described under
Image layout (page \pageref{DR:IMAGE LAYOUT}); the layout and total size of
this raw data are determinable from the {\tt IHDR} fields.  Then
filter the image data according to the filtering method specified by
the {\tt IHDR} chunk.  (Note that with filter method 0, the only
one currently defined, this implies prepending a filter type byte to
each scanline.)  Finally, compress the filtered data using the
compression method specified by the {\tt IHDR} chunk.  The
{\tt IDAT} chunk contains the output datastream of the compression
algorithm.  To read the image data, reverse this process.
\par 
There may be multiple {\tt 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
{\tt IDAT} chunks.  The encoder may divide the compressed data
stream into {\tt IDAT} chunks as it wishes.
(Multiple {\tt 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 {\tt IDAT} chunk boundaries have
no semantic significance and can appear at any point in the compressed
datastream.  A PNG file in which each {\tt IDAT} chunk contains
only one data byte is legal, though remarkably wasteful of space.
(For that matter, zero-length {\tt IDAT} chunks are legal, though
even more wasteful.)
\par 
See Filter Algorithms (page \pageref{FILTERS}) and
Deflate/\allowbreak{}Inflate Compression (page \pageref{COMPRESSION})
for details.

\par 
\item[ {\tt IEND  }  Image Trailer
]\leavevmode\par  
This chunk must appear LAST.  It marks the end of the PNG data stream.
The chunk's data field is empty.
\end{description}

\subsection{Ancillary Chunks\label{ANCILLARY CHUNKS}}

All ancillary chunks are optional, in the sense that encoders need not
write them and decoders may 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.
\par 
The standard ancillary chunks are listed in alphabetical order.
This is not necessarily the order in which they would appear in
a file.

\begin{description}

\item[ {\tt bKGD  }  Background Color
]\leavevmode\par  
This chunk specifies a default background color against which the
image may be presented.  Note that viewers are not bound to honor this
chunk; a viewer may choose to use a different background color.
\par 
For color type 3 (palette), the {\tt bKGD} chunk contains:
\bverbatim 
palette index: 1 byte
\everbatim 
The value is the palette index of the color to be used as background.
\par 
For color types 0 and 4 (grayscale, with or without alpha),
{\tt bKGD} contains:
\bverbatim 
gray:  2 bytes, range 0 .. (2\^{ }bitdepth) - 1
\everbatim 
(For consistency, 2 bytes are used regardless of the image
bit depth.)  The value is the gray level to be used as background.
\par 
For color types 2 and 6 (RGB, with or without alpha), {\tt bKGD}
contains:
\bverbatim 
red:   2 bytes, range 0 .. (2\^{ }bitdepth) - 1
green: 2 bytes, range 0 .. (2\^{ }bitdepth) - 1
blue:  2 bytes, range 0 .. (2\^{ }bitdepth) - 1
\everbatim 
(For consistency, 2 bytes per sample are used regardless of the image
bit depth.)  This is the RGB color to be used as background.
\par 
When present, the {\tt bKGD} chunk must precede the first
{\tt IDAT} chunk, and must follow the {\tt PLTE} chunk, if any.
\par 
See Recommendations for Decoders:
Background color (page \pageref{D:BACKGROUND COLOR}).

\par 
\item[ {\tt cHRM  }  Primary Chromaticities and White Point
]\leavevmode\par 
Applications that need precise specification of colors in a
PNG file may use this chunk to specify the chromaticities of the
red, green, and blue primaries used in the image, and the referenced
white point. These values are based on the 1931 CIE (International
Color Committee) XYZ color space. Only the chromaticities ({\em x}
and {\em y}) are specified.  The chunk layout is:
\bverbatim 
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
\everbatim 
Each value is encoded as a 4-byte unsigned integer,
representing the {\em x} or {\em y} value times 100000.
\par 
If the {\tt cHRM} chunk appears, it must precede the first
{\tt IDAT} chunk, and it must also precede the {\tt PLTE} chunk
if present.

\par 
\item[ {\tt gAMA  }  Gamma Correction
]\leavevmode\par  
The gamma correction 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.
Note that this is {\em not} the same as the gamma of the display
device that will reproduce the image correctly.
\par 
The chunk's contents are:
\bverbatim 
Image gamma value: 4 bytes
\everbatim 
A value of 100000 represents a gamma of 1.0, a value
of 45000 a gamma of 0.45, and so on (divide by 100000.0).
Values around 1.0 and around 0.45 are common in practice.
\par 
If the encoder does not know the gamma value, it should not write a
gamma chunk; the absence of a gamma chunk indicates the gamma is
unknown.
\par 
If the {\tt gAMA} chunk appears, it must precede the first
{\tt IDAT} chunk, and it must also precede the {\tt PLTE} chunk
if present.
\par 
See Gamma correction (page \pageref{DR:GAMMA CORRECTION}),
Recommendations for Encoders:
Encoder gamma handling (page \pageref{E:ENCODER GAMMA HANDLING}),
and Recommendations for Decoders:
Decoder gamma handling (page \pageref{D:DECODER GAMMA HANDLING}).

\par 
\item[ {\tt hIST  }  Image Histogram
]\leavevmode\par  
The histogram chunk gives the approximate usage frequency of each
color in the color palette.  A histogram chunk may 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.
\par 
This chunk's contents are a series of 2-byte (16 bit) unsigned
integers.  There must be exactly one entry for each entry in the
{\tt 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.
\par 
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.
\par 
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.
\par 
The {\tt hIST} chunk, if it appears, must follow
the {\tt PLTE} chunk, and must precede the first
{\tt IDAT} chunk.
\par 
See Rationale:
Palette histograms (page \pageref{R:PALETTE HISTOGRAMS}),
and Recommendations for Decoders:
Palette histogram usage (page \pageref{D:PALETTE HISTOGRAM USAGE}).

\par 
\item[ {\tt pHYs  }  Physical Pixel Dimensions
]\leavevmode\par  
This chunk specifies the intended resolution for display of the image.
The chunk's contents are:
\bverbatim 
4 bytes: pixels per unit, X axis (unsigned integer)
4 bytes: pixels per unit, Y axis (unsigned integer)
1 byte: unit specifier
\everbatim 
The following values are legal for the unit specifier:
\bverbatim 
0: unit is unknown (pHYs defines pixel aspect ratio only)
1: unit is the meter 
\everbatim 
Conversion note: one inch is equal to exactly 0.0254 meters.
\par 
If this ancillary chunk is not present, pixels are assumed to be
square, and the physical size of each pixel is unknown.
\par 
If present, this chunk must precede the first {\tt IDAT} chunk.
\par 
See Recommendations for Decoders:
Pixel dimensions (page \pageref{D:PIXEL DIMENSIONS}).

\par 
\item[ {\tt sBIT  }  Significant Bits
]\leavevmode\par 
To simplify decoders, PNG specifies that only certain bit depth values
be used, and further specifies that pixel values must be scaled to the
full range of possible values at that bit depth.  However, the
{\tt sBIT} chunk is provided in order to store the original number
of significant bits, since this information may be of use to some
decoders.  We recommend that an encoder emit an {\tt sBIT} chunk if
it has converted the data from a different bit depth.
\par 
For color type 0 (grayscale), the {\tt sBIT} chunk contains a
single byte, indicating the number of bits which were significant in
the source data.
\par 
For color type 2 (RGB truecolor), the {\tt sBIT} chunk contains
three bytes, indicating the number of bits which were significant in
the source data for the red, green, and blue channels, respectively.
\par 
For color type 3 (palette color), the {\tt sBIT} chunk contains
three bytes, indicating the number of bits which were significant in
the source data for the red, green, and blue components of the palette
entries, respectively.
\par 
For color type 4 (grayscale with alpha channel), the {\tt sBIT}
chunk contains two bytes, indicating the number of bits which were
significant in the source grayscale data and the source alpha channel
data, respectively.
\par 
For color type 6 (RGB truecolor with alpha channel), the {\tt sBIT}
chunk contains four bytes, indicating the number of bits which were
significant in the source data for the red, green, blue and alpha
channels, respectively.
\par 
Note that {\tt sBIT} does {\em not} have any implications for
the interpretation of the stored image: the bit depth indicated by
{\tt IHDR} is the correct depth.  {\tt sBIT} is only an
indication of the history of the image.  However, an {\tt sBIT}
chunk showing a bit depth less than the {\tt IHDR} bit depth does
mean that not all possible color values occur in the image; this fact
may be of use to some decoders.
\par 
If the {\tt sBIT} chunk appears, it must precede the first
{\tt IDAT} chunk, and it must also precede the {\tt PLTE} chunk
if present.

\par 
\item[ {\tt tEXt  }  Textual Data
]\leavevmode\par  
Any textual information that the encoder wishes to record with the
image is stored in {\tt tEXt} chunks.  Each {\tt tEXt} chunk
contains a keyword and a text string, in the format:
\bverbatim 
Keyword:        n bytes (character string)
Null separator: 1 byte
Text:           n bytes (character string)
\everbatim 
The keyword and text string are separated by a zero byte (null
character).  Neither the keyword nor the text string may contain a null
character.  Note that the text string is {\em 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 may be of any length from zero bytes
up to the maximum permissible chunk size.
\par 
Any number of {\tt tEXt} chunks may appear, and more than one with
the same keyword is permissible.
\par 
The keyword indicates the type of information represented by the
text string.  The following keywords are predefined and should
be used where appropriate:
\bverbatim 
Title            Short (one line) title or caption for image
Author           Name of image's creator
Copyright        Copyright notice
Description      Description of image (possibly long)
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
\everbatim 
Other keywords, containing any sequence of printable characters in the
character set, may be invented for other purposes.  Keywords of
general interest may be registered with the maintainers of the PNG
specification.
\par 
Keywords must be spelled exactly as registered, so that decoders may
use simple literal comparisons when looking for particular keywords.
In particular, keywords are considered case-sensitive.
\par 
Both keyword and text are interpreted according to the ISO 8859-1
(Latin-1) character set.  Newlines in the text string should be
represented by a single linefeed character (decimal 10); use of other
ASCII control characters is discouraged.
\par 
See Recommendations for Encoders:
Text chunk processing (page \pageref{E:TEXT CHUNK PROCESSING})
and Recommendations for Decoders:
Text chunk processing (page \pageref{D:TEXT CHUNK PROCESSING}).

\par 
\item[ {\tt tIME  }  Image Last-Modification Time
]\leavevmode\par  
This chunk gives the time of the last image modification ({\em not}
the time of initial image creation).  The chunk contents are:
\bverbatim 
2 bytes: Year (complete; for example, 1995, {\em not} 95)
1 byte: Month (1-12)
1 byte: Day (1-31)
1 byte: Hour (0-23)
1 byte: Minute (0-59)
1 byte: Second (0-60)    (yes, 60, for leap seconds; not 61, a common error)
\everbatim 
Universal Time (UTC, also called GMT) should be specified rather than
local time.

\par 
\item[ {\tt tRNS  }  Transparency
]\leavevmode\par  
Transparency is an alternative to the full alpha channel.
Although transparency is not as elegant as the full alpha channel,
it requires less storage space and is sufficient for many common cases.
\par 
For color type 3 (palette), this chunk's contents are a series of
alpha channel bytes, corresponding to entries in the
{\tt PLTE} chunk:
\bverbatim 
Alpha for palette index 0:  1 byte
Alpha for palette index 1:  1 byte
etc.
\everbatim 
Each entry indicates that pixels of that palette index
should 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. {\em The {\tt tRNS} chunk may contain fewer alpha channel
bytes than there are palette entries.} In this case, the alpha
channel value for all remaining palette entries is assumed to be 255.
In the common case where only palette index 0 need be made
transparent, only a one-byte {\tt tRNS} chunk is needed.
The {\tt tRNS} chunk may not contain more bytes than there are
palette entries.
\par 
For color type 0 (grayscale), the {\tt tRNS} chunk contains a
single gray level value, stored in the format
\bverbatim 
gray:  2 bytes, range 0 .. (2\^{ }bitdepth) - 1
\everbatim 
(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).
\par 
For color type 2 (RGB), the {\tt tRNS} chunk contains a single RGB
color value, stored in the format
\bverbatim 
red:   2 bytes, range 0 .. (2\^{ }bitdepth) - 1
green: 2 bytes, range 0 .. (2\^{ }bitdepth) - 1
blue:  2 bytes, range 0 .. (2\^{ }bitdepth) - 1
\everbatim 
(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).
\par 
{\tt tRNS} is prohibited for color types 4 and 6, since a full
alpha channel is already present in those cases.
\par 
Note: when dealing with 16-bit grayscale or RGB 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.
\par 
When present, the {\tt tRNS} chunk must precede the first
{\tt IDAT} chunk, and must follow the {\tt PLTE} chunk, if any.

\par 
\item[ {\tt zTXt  }  Compressed Textual Data
]\leavevmode\par  
A {\tt zTXt} chunk contains textual data, just as {\tt tEXt}
does; however, {\tt zTXt} takes advantage of compression.
\par 
A {\tt zTXt} chunk begins with an uncompressed Latin-1 keyword
followed by a null (0) character, just as in the {\tt tEXt} chunk.
The next byte after the null contains a compression type byte, for
which the only presently legitimate value is zero (deflate/\allowbreak{}inflate
compression). The compression-type byte is followed by a compressed
data stream which makes up the remainder of the chunk.
Decompression of this data stream yields Latin-1 text which is
equivalent to the text stored in a {\tt tEXt} chunk.
\par 
Any number of {\tt zTXt} and {\tt tEXt} chunks may appear in the
same file.  See the preceding definition of the {\tt tEXt} chunk
for the predefined keywords and the exact format of the text.
\par 
See
Deflate/\allowbreak{}Inflate Compression (page \pageref{COMPRESSION}),
Recommendations for Encoders:
Text chunk processing (page \pageref{E:TEXT CHUNK PROCESSING}),
and Recommendations for Decoders:
Text chunk processing (page \pageref{D:TEXT CHUNK PROCESSING}).

\end{description}

\subsection{Summary of Standard Chunks\label{SUMMARY OF STANDARD CHUNKS}}

This table summarizes some properties of the standard chunk types.
\bverbatim 
Critical chunks (must appear in this order, except PLTE is optional):
\vspace{\baselineskip}
\verb|        |Name  Multiple  Ordering constraints
\verb|                |OK?
\vspace{\baselineskip}
\verb|        |IHDR    No      Must be first
\verb|        |PLTE    No      Before IDAT
\verb|        |IDAT    Yes     Multiple IDATs must be consecutive
\verb|        |IEND    No      Must be last
\vspace{\baselineskip}
Ancillary chunks (need not appear in this order):
\vspace{\baselineskip}
\verb|        |Name  Multiple  Ordering constraints
\verb|                |OK?
\vspace{\baselineskip}
\verb|        |cHRM    No      Before PLTE and IDAT
\verb|        |gAMA    No      Before PLTE and IDAT
\verb|        |sBIT    No      Before PLTE and IDAT
\verb|        |bKGD    No      After PLTE; before IDAT
\verb|        |hIST    No      After PLTE; before IDAT
\verb|        |tRNS    No      After PLTE; before IDAT
\verb|        |pHYs    No      Before IDAT
\verb|        |tIME    No      None
\verb|        |tEXt    Yes     None
\verb|        |zTXt    Yes     None
\everbatim 
\par 
Standard keywords for {\tt tEXt} and {\tt zTXt} chunks:
\par 
\bverbatim 
Title            Short (one line) title or caption for image
Author           Name of image's creator
Copyright        Copyright notice
Description      Description of image (possibly long)
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
\everbatim 

\subsection{Additional Chunk Types\label{ADDITIONAL CHUNK TYPES}}

Additional public PNG chunk types are defined in the document
``PNG Special-Purpose Public Chunks'', available by FTP from
{\tt ftp.uu.net:/\allowbreak{}graphics/\allowbreak{}png/\allowbreak{}}
or via WWW from
{\tt http:/\allowbreak{}/\allowbreak{}sunsite.unc.edu/\allowbreak{}boutell/\allowbreak{}pngextensions.html}.
\par 
Chunks described there are expected to be somewhat 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 may be proposed for
inclusion in that list by contacting the PNG specification maintainers
at
{\tt png-info@uunet.uu.net}.
\par 
Decoders must treat unrecognized chunk types as described under
Chunk naming conventions (page \pageref{CHUNK NAMING CONVENTIONS}).

\section{Deflate/\allowbreak{}Inflate Compression\label{COMPRESSION}}

PNG compression type 0 (the only compression method presently defined
for PNG) specifies deflate/\allowbreak{}inflate compression with a 32K 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.
\par 
Documentation and C code for deflate are available from the Info-Zip
archives at
{\tt ftp.uu.net:/\allowbreak{}pub/\allowbreak{}archiving/\allowbreak{}zip/\allowbreak{}}.
\par 
Deflate-compressed datastreams within PNG are stored in the ``zlib''
format, which has the structure:
\bverbatim 
Compression method/\allowbreak{}flags code: 1 byte
Additional flags/\allowbreak{}check bits:   1 byte
Compressed data blocks:        n bytes
Checksum:                      4 bytes
\everbatim 
Further details on this format may be found in the zlib specification.
At this writing, the zlib specification is at draft 3.1, and is
available from
{\tt ftp.uu.net:/\allowbreak{}pub/\allowbreak{}archiving/\allowbreak{}zip/\allowbreak{}doc/\allowbreak{}zlib-3.1.doc}.
\par 
For PNG compression type 0, the zlib compression method/\allowbreak{}flags code must
specify method code 8 (``deflate'' compression) and an LZ77 window size
of not more than 32K.
\par 
The checksum 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 checksums.  Verifying the chunk CRCs provides adequate
confidence that the PNG file has been transmitted undamaged.  The zlib
checksum is useful mainly as a crosscheck that the deflate and inflate
algorithms are implemented correctly.
\par 
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 may be found in
the deflate specification.  At this writing, the deflate specification
is at draft 1.1, and is available from
{\tt ftp.uu.net:/\allowbreak{}pub/\allowbreak{}archiving/\allowbreak{}zip/\allowbreak{}doc/\allowbreak{}deflate-1.1.doc}.
\par 
In a PNG file, the concatenation of the contents of all the
{\tt IDAT} chunks makes up a zlib datastream as specified above.
This datastream decompresses to filtered image data as described
elsewhere in this document.
\par 
It is important to emphasize that the boundaries between {\tt IDAT}
chunks are arbitrary and may fall anywhere in the zlib datastream.
There is not necessarily any correlation between {\tt 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 checksum to be split across {\tt IDAT} chunks.
\par 
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 {\tt IDAT} chunk boundaries.  The complete image data is
represented by a single zlib datastream that is stored in some number
of {\tt IDAT} chunks; a decoder that assumes any more than this is
incorrect.  (Of course, a particular encoder implementation may happen
to emit files in which some of these structures are in fact
related.  But decoders may not rely on this.)
\par 
PNG also uses zlib datastreams in {\tt zTXt} chunks.  In a
{\tt zTXt} chunk, the remainder of the chunk following the
compression type code 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 {\tt zTXt} chunk contains an
independent zlib datastream.

\section{Filter Algorithms\label{FILTERS}}

This chapter describes the pixel filtering algorithms which may be
applied in advance of compression.  The purpose of these filters is to
prepare the image data for optimum compression.
\par 
PNG defines five basic filtering algorithms, which are given numeric
codes as follows:
\bverbatim 
Code    Name
0       None
1       Sub
2       Up
3       Average
4       Paeth
\everbatim 
The encoder may choose which algorithm to apply on a
scanline-by-scanline basis.  In the image data sent to the compression
step, each scanline is preceded by a filter type byte containing the
numeric code of the filter algorithm used for that scanline.
\par 
Filtering algorithms are applied to {\em bytes}, not to pixels,
regardless of the bit depth or color type of the image.  The filtering
algorithms work on the byte sequence formed by a scanline that has
been represented as described under Image layout (page \pageref{DR:IMAGE LAYOUT}).
\par 
When the image is interlaced, each pass of the interlace pattern is
treated as an independent image for filtering purposes.  The filters
work on the byte sequences formed by the pixels actually transmitted
during a pass, and the ``previous scanline'' is the one previously
transmitted in the same pass, not the one adjacent in the complete
image.  Note that the subimage transmitted in any one pass is always
rectangular, but is of smaller width and/\allowbreak{}or height than the complete
image.  Filtering is not applied when this subimage is empty.
\par 
For all filters, the bytes ``to the left of'' the first pixel in a
scanline must be treated as being zero.  For filters that refer to the
prior scanline, the entire prior scanline must be treated as being
zeroes for the first scanline of an image (or of a pass of an
interlaced image).
\par 
To reverse the effect of a filter, the decoder must use the decoded
values of the prior pixel on the same line, the pixel immediately
above the current pixel on the prior line, and the pixel just to the
left of the pixel above.  This implies that at least one scanline's
worth of image data must be stored by the decoder at all times.
Even though some filter types do not refer to the prior
scanline, the decoder must always store each scanline as it is decoded,
since the next scanline might use a filter that refers to it.
\par 
PNG imposes no restriction on which filter types may be applied to an
image.  However, the filters are not equally effective on all types
of data.
See Recommendations for Encoders:
Filter selection (page \pageref{E:FILTER SELECTION}).
\par 
See also Rationale:
Filtering (page \pageref{R:FILTERING}).

\subsection{Filter type 0: None\label{FILTER TYPE 0: NONE}}

With the None filter, the scanline is transmitted unmodified;
it is only necessary to insert a filter type byte before the data.

\subsection{Filter type 1: Sub\label{FILTER TYPE 1: SUB}}

The Sub filter transmits the difference between each byte and the
value of the corresponding byte of the prior pixel.
\par 
To compute the Sub filter, apply the following formula to each byte of
each scanline:
\bverbatim 
\verb|  |Sub(x) = Raw(x) - Raw(x-bpp)
\everbatim 
where {\tt x} ranges from zero to the number of bytes representing
that scanline minus one, {\tt Raw(x)} refers to the raw data
byte at that byte position in the scanline, and
{\tt bpp} is defined as the number of bytes per complete pixel,
rounding up to one. For example, for color type 2 with a bit
depth of 16, bpp is equal to 6 (three channels, two bytes per
channel); for color type 0 with a bit depth of 2, bpp is equal to 1
(rounding up); for color type 4 with a bit depth of 16, bpp is equal
to 4 (two-byte grayscale value, plus two-byte alpha channel).
\par 
Note this computation is done for each {\bf byte},
regardless of bit depth.  In a 16-bit image, MSBs are differenced from
the preceding MSB and LSBs are differenced from the preceding LSB,
because of the way that {\tt bpp} is defined.
\par 
Unsigned arithmetic modulo 256 is used, so
that both the inputs and outputs fit into bytes.  The sequence of
{\tt Sub} values is transmitted as the filtered scanline.
\par 
For all x $<$ 0, assume Raw(x) = 0.
\par 
To reverse the effect of the Sub filter after decompression,
output the following value:
\bverbatim 
\verb|  |Sub(x) + Raw(x-bpp)
\everbatim 
(computed mod 256), where {\tt Raw} refers to the bytes already
decoded.

\subsection{Filter type 2: Up\label{FILTER TYPE 2: UP}}

The Up filter is just like the Sub filter except that the pixel
immediately above the current pixel, rather than just to its left,
is used as the predictor.
\par 
To compute the Up filter, apply the following formula to each byte of
each scanline:
\bverbatim 
\verb|  |Up(x) = Raw(x) - Prior(x)
\everbatim 
where {\tt x} ranges from zero to the number of bytes representing
that scanline minus one, {\tt Raw(x)} refers to the raw data
byte at that byte position in the scanline, and
{\tt Prior(x)} refers to the unfiltered bytes of the prior
scanline.
\par 
Note this is done for each {\bf byte}, regardless of bit
depth.  Unsigned arithmetic modulo 256 is used, so that both the
inputs and outputs fit into bytes.  The sequence of {\tt Up}
values is transmitted as the filtered scanline.
\par 
On the first scanline of an image (or of a
pass of an interlaced image), assume Prior(x) = 0 for all x.
\par 
To reverse the effect of the Up filter after decompression,
output the following value:
\bverbatim 
\verb|  |Up(x) + Prior(x)
\everbatim 
(computed mod 256), where {\tt Prior} refers to the decoded bytes
of the prior scanline.

\subsection{Filter type 3: Average\label{FILTER TYPE 3: AVERAGE}}

The Average filter uses the average of the two neighboring pixels
(left and above) to predict the value of a pixel.
\par 
To compute the Average filter,
apply the following formula to each byte of each scanline:
\bverbatim 
\verb|  |Average(x) = Raw(x) - floor((Raw(x-bpp)+Prior(x))/\allowbreak{}2)
\everbatim 
where {\tt x} ranges from zero to the number of bytes representing
that scanline minus one, {\tt Raw(x)} refers to the raw data
byte at that byte position in the scanline,
{\tt Prior(x)} refers to the unfiltered bytes of the prior
scanline, and {\tt bpp} is defined as for the Sub filter.
\par 
Note this is done for each {\bf byte}, regardless of bit
depth.  The sequence of {\tt Average}
values is transmitted as the filtered scanline.
\par 
The subtraction of the predicted value from the raw byte must be done
modulo 256, so that both the inputs and outputs fit into bytes.
However, the sum {\tt Raw(x-bpp)+Prior(x)} must be formed without
overflow (using at least nine-bit arithmetic).  {\tt floor()}
indicates that the result of the division is rounded to the next lower
integer if fractional; in other words, it is an integer division or
right shift operation.
\par 
For all x $<$ 0, assume Raw(x) = 0.
On the first scanline of an image (or of a
pass of an interlaced image), assume Prior(x) = 0 for all x.
\par 
To reverse the effect of the Average filter after decompression,
output the following value:
\bverbatim 
\verb|  |Average(x) + floor((Raw(x-bpp)+Prior(x))/\allowbreak{}2)
\everbatim 
where the result is computed mod 256, but the prediction is calculated
in the same way as for encoding.  {\tt Raw} refers to the bytes
already decoded, and {\tt Prior} refers to the decoded bytes of the
prior scanline.

\subsection{Filter type 4: Paeth\label{FILTER TYPE 4: PAETH}}

The Paeth filter computes a simple linear function of the three
neighboring pixels (left, above, upper left), then chooses as
predictor the neighboring pixel closest to the computed value.
This technique is taken from Alan W. Paeth's article ``Image File
Compression Made Easy'' in Graphics Gems II, James Arvo, editor,
Academic Press, 1991.
\par 
To compute the Paeth filter,
apply the following formula to each byte of each scanline:
\bverbatim 
\verb|  |Paeth(x) = Raw(x) - PaethPredictor(Raw(x-bpp),Prior(x),Prior(x-bpp))
\everbatim 
where {\tt x} ranges from zero to the number of bytes representing
that scanline minus one, {\tt Raw(x)} refers to the raw data
byte at that byte position in the scanline,
{\tt Prior(x)} refers to the unfiltered bytes of the prior
scanline, and {\tt bpp} is defined as for the Sub filter.
\par 
Note this is done for each {\bf byte}, regardless of bit
depth.  Unsigned arithmetic modulo 256 is used, so that both the
inputs and outputs fit into bytes.  The sequence of {\tt Paeth}
values is transmitted as the filtered scanline.
\par 
The PaethPredictor function is defined by the following pseudocode:
\bverbatim 
\verb|     |function PaethPredictor (a, b, c)
\verb|     |begin
\verb|          |; a = left, b = above, c = upper left
\verb|          |p := a + b - c        ; initial estimate
\verb|          |pa := abs(p - a)      ; distances to a, b, c
\verb|          |pb := abs(p - b)
\verb|          |pc := abs(p - c)
\verb|          |; return nearest of a,b,c,
\verb|          |; breaking ties in order a,b,c.
\verb|          |if pa <= pb AND pa <= pc 
\verb|          |begin
\verb|               |return a
\verb|          |end
\verb|          |if pb <= pc
\verb|          |begin
\verb|               |return b
\verb|          |end
\verb|          |return c
\verb|     |end
\everbatim 
The calculations within the PaethPredictor function must be performed
exactly, without overflow.  Arithmetic modulo 256
is to be used only for the final step of subtracting the function
result from the target pixel value.
\par 
{\bf Note that the order in which ties are broken is fixed and must
not be altered.} The tie break order is: pixel to the left,
pixel above, pixel to the upper left.  (This order differs from that
given in Paeth's article.)
\par 
For all x $<$ 0, assume Raw(x) = 0 and
Prior(x) = 0.  On the first scanline of an image (or of a
pass of an interlaced image), assume Prior(x) = 0 for all x.
\par 
To reverse the effect of the Paeth filter after decompression,
output the following value:
\bverbatim 
\verb|  |Paeth(x) + PaethPredictor(Raw(x-bpp),Prior(x),Prior(x-bpp))
\everbatim 
(computed mod 256), where {\tt Raw} and {\tt Prior} refer to
bytes already decoded.  Exactly the same PaethPredictor function is
used by both encoder and decoder.

\section{Chunk Ordering Rules\label{ORDERING}}

To allow new chunk types to be added to PNG, it is necessary to
establish rules about the ordering requirements for all chunk types.
Otherwise a PNG editing program cannot know what to do when it
encounters an unknown chunk.
\par 
We define a ``PNG editor'' as a program that modifies a PNG file, but
wishes to preserve as much as possible of the ancillary information in
the file.  Examples of PNG editors are a program that adds or modifies
text chunks, and a program that adds a suggested palette to a 24-bit
RGB PNG file.  Ordinary image editors are not PNG editors in this
sense, because they usually discard any unrecognized information while
reading in an image.  (Note: we strongly encourage programs handling PNG
files to preserve ancillary information whenever possible.)
\par 
As an example of possible problems, consider a hypothetical new
ancillary chunk type that is safe-to-copy and is required to appear
after {\tt PLTE} if {\tt PLTE} is present (presumably
{\tt PLTE} affects the meaning of the chunk in some way).  If our
program to add a suggested {\tt PLTE} to a file does not recognize
this new chunk, it may insert {\tt PLTE} in the wrong place, namely
after the new chunk.  We could prevent such problems by requiring PNG
editors to discard any unknown chunks, but that is a very unattractive
solution.
\par 
To prevent this type of problem while allowing for future extension,
we put some constraints on both the behavior of PNG editors and the
allowed ordering requirements for chunks.  The rules for PNG editors
are:
\begin{enumerate}
\item 
When copying an unknown unsafe-to-copy ancillary chunk, a PNG editor
may not move the chunk relative to any critical chunk.  It may relocate
the chunk freely relative to other ancillary chunks that occur between
the same pair of critical chunks.  (This is well defined since the
editor may not add, delete, or reorder critical chunks if it is
preserving unsafe-to-copy chunks.)
\item 
When copying an unknown safe-to-copy ancillary chunk, a PNG editor may
not move the chunk from before {\tt IDAT} to after {\tt IDAT} or
vice versa.  (This is well defined because {\tt IDAT} is always
present.)  Any other reordering is permitted.
\item 
When copying a {\em known} chunk type, an editor need only honor
the specific chunk ordering rules that exist for that chunk type.
However, it may always choose to apply the above general rules instead.
\end{enumerate}
\par 
Therefore, the actual ordering rules for any ancillary chunk type cannot
be any stricter than this:
\begin{itemize}
\item  Unsafe-to-copy chunks may have ordering requirements relative to
critical chunks.
\item  Safe-to-copy chunks may have ordering requirements relative to
{\tt IDAT}.
\end{itemize}
Note that critical chunks can have arbitrary ordering requirements,
because PNG editors are required to give up if they encounter unknown
critical chunks.  A PNG editor must always know the ordering rules for
any critical chunk type that it deals with.  For example,
{\tt IHDR} has the special ordering rule that it must always appear
first.
\par 
{\bf Decoders may not assume more about the positioning of any
ancillary chunk than is specified by the chunk ordering rules.}
In particular, it is never valid to assume that a specific ancillary
chunk type occurs with any particular positioning relative to other
ancillary chunks.  (For example, it is unsafe to assume that your
private ancillary chunk occurs immediately before {\tt IEND}.
Even if your application always writes it there, a PNG editor might
have inserted some other ancillary chunk in between.  But you can
safely assume that your chunk will remain somewhere between
{\tt IDAT} and {\tt IEND}.)
\par 
See also
Chunk naming conventions (page \pageref{CHUNK NAMING CONVENTIONS}).

\section{Multi-Image Extension\label{MULTI}}

PNG itself is strictly a single-image format.  However, it may be
necessary to store multiple images within one file; for example, this
is needed to convert some GIF files.  For this purpose, a multi-image
format will be defined in the near future.  PNG decoders will not be 
required to support the multi-image extension.

\section{Recommendations for Encoders\label{ENCODERS}}

This chapter gives some recommendations for encoder behavior.  The
only absolute requirement on a PNG encoder is that it produce files
which conform to the format specified in the preceding chapters.
However, best results will usually be achieved by following these
recommendations.

\subsection{Bitdepth scaling\label{E:BITDEPTH SCALING}}

When scaling input values that have a bit depth that cannot be directly
represented in PNG, an excellent approximation to the correct value
can be achieved by shifting the valid bits to begin in the most
significant bit and repeating the most significant bits into the open
bits.
\par 
For example, if 5 bits per channel are available in the source data,
conversion to a bitdepth of 8 can be achieved as follows:
\par 
If the value for a sample in the source data is 27 (in a range from
0-31), then the original bits are:
\bverbatim 
4 3 2 1 0
---------
1 1 0 1 1
\everbatim 
Converted to a bitdepth of 8, the best value is 222:
\bverbatim 
7 6 5 4 3  2 1 0
----------------
1 1 0 1 1  1 1 0
|=======|  |===|
\verb|    ||      Leftmost Bits Repeated to Fill Open Bits
\verb|    ||
Original Bits
\everbatim 
Note that this scaling can be reversed simply by shifting right.
\par 
Scaling by simply shifting left by three bits is incorrect, since the
resulting data would have a range less than the desired full range.
(For 5-bit input data, the maximum output would be 248 = 11111000,
which is not full brightness.)
\par 
It is recommended that the {\tt sBIT} chunk be included when
bitdepth scaling has been performed, to record the original data
depth.

\subsection{Encoder gamma handling\label{E:ENCODER GAMMA HANDLING}}

If it is possible for the encoder to determine the image gamma,
or to make a strong guess based on the hardware on which it
runs, then the encoder is strongly encouraged to output
the {\tt gAMA} chunk.
\par 
A linear brightness level, expressed as a
floating-point value in the range 0 to 1, may be converted to a
gamma-corrected pixel value by
\bverbatim 
\verb|  |gbright := bright \^{ } gamma
\verb|  |pixelval := ROUND(gbright * MAXPIXVAL)
\everbatim 
Computer graphics renderers often do not perform gamma
encoding, instead making pixel values directly proportional to
scene brightness.  This ``linear'' pixel encoding is equivalent
to gamma encoding with a gamma of 1.0, so graphics programs
that produce linear pixels should always put out a {\tt gAMA}
chunk specifying a gamma of 1.0.
\par 
If the encoder knows that the image has been displayed satisfactorily
on a display of gamma display\_gamma, then the image can be marked as
having gamma 1.0/\allowbreak{}display\_gamma.
\par 
It is {\bf not} recommended that encoders attempt to
convert supplied images to a different gamma.  Store the data in the
file without conversion, and record the source gamma.  Gamma
conversion at encode time is a bad idea because gamma adjustment of
digital pixel data is inherently lossy, due to roundoff error (8 or so
bits is not really enough accuracy).  Thus encode-time conversion
permanently degrades the image.  Worse, if the eventual decoder wants
the data with some other gamma, then two conversions occur, each
introducing roundoff error.  Better to store the data losslessly and
incur at most one conversion when the image is finally displayed.
\par 
Gamma does not apply to alpha channel values; alpha is always
represented linearly.
\par 
See Recommendations for Decoders:
Decoder gamma handling (page \pageref{D:DECODER GAMMA HANDLING})
for more details.

\subsection{Alpha channel creation\label{E:ALPHA CHANNEL CREATION}}

The alpha channel may be regarded either as a mask that temporarily
hides transparent parts of the image, or as a means for constructing a
non-rectangular image.  In the first case, the color values of fully
transparent pixels should be preserved for future use.  In the second
case, the transparent pixels carry no useful data and are simply there
to fill out the rectangular image area required by PNG.  In this case,
fully transparent pixels should all be assigned the same color value
for best compression.
\par 
Encoders should keep in mind the possibility that a viewer will ignore
transparency control.  Hence, the colors assigned to transparent pixels
should be reasonable background colors whenever feasible.
\par 
For applications that do not require a full alpha channel,
or cannot afford the price in compression efficiency,
the {\tt tRNS} transparency chunk is also available.
\par 
If the image has a known background color, this color should be
written in the {\tt bKGD} chunk.  Even viewers that ignore
transparency may use the {\tt bKGD} color to fill unused screen area.
\par 
If the original image has premultiplied (also called ``associated'')
alpha data, convert it to PNG's non-premultiplied format by dividing
each RGB value by the corresponding alpha value, then multiplying by
the maximum value for the image bit depth.  In valid premultiplied
data, the RGB values never exceed their corresponding alpha values, so
the result of the division should always be in the range 0 to 1.  If
the alpha value is zero, output black (zeroes).

\subsection{Filter selection\label{E:FILTER SELECTION}}

For images of color type 3 (palette-based color), filter type 0 (none)
is usually the most effective.
\par 
Filter type 0 is also recommended for images of bit depths less than
8.  For low-bit-depth grayscale images, it may be a net win to expand
the image to 8-bit representation and apply filtering, but this is rare.
\par 
For truecolor and grayscale images, any of the five filters may prove
the most effective.  If an encoder wishes to use a fixed filter
choice, the Paeth filter is most likely to be the best.
\par 
For best compression of truecolor and grayscale images, we recommend
an adaptive filtering approach in which a filter is chosen for each
scanline.  The following simple heuristic has performed well in early
tests: compute the output scanline using all five filters, and select
the filter which gives the smallest sum of absolute values of outputs.
(Consider the output bytes as signed differences for this test.)  This
method usually outperforms any single fixed filter choice.  However,
it is likely that much better heuristics will be found as
more experience is gained with PNG.
\par 
Filtering according to these recommendations is effective on
interlaced as well as noninterlaced images.

\subsection{Text chunk processing\label{E:TEXT CHUNK PROCESSING}}

Note that a nonempty keyword {\em must} be provided for each text
chunk.  The generic keyword ``Comment'' may be used if no better
description of the text is available.
\par 
Encoders should discourage the creation of single lines of
text longer than 79 characters, in order to facilitate easy reading.
\par 
If an encoder chooses to support output of {\tt zTXt} compressed
text chunks, it is recommended that text less than 1K (1024 bytes) in
size be output using uncompressed {\tt tEXt} chunks. In particular,
it is recommended that the basic title and author keywords always be
output using uncompressed {\tt tEXt} chunks. Lengthy disclaimers,
on the other hand, are an ideal candidate for {\tt zTXt}.
\par 
Placing large {\tt tEXt} and {\tt zTXt} chunks after the image
data (after {\tt IDAT}) may speed up image display in some
situations, since the decoder won't have to read over the text to get
to the image data.  But it is recommended that small text chunks, such
as the image title, appear before {\tt IDAT}.

\subsection{Registering proprietary chunks\label{E:REGISTERING PROPRIETARY CHUNKS}}

If you want others outside your organization to understand a chunk
type that you invent, contact the maintainers of the PNG specification
to submit a proposed chunk name and definition for addition to the
list of special-purpose public chunks
(see Additional Chunk Types (page \pageref{ADDITIONAL CHUNK TYPES})).
\par 
New public chunks will be 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.
\par 
If you do not desire that others outside your organization understand
the chunk type, you may use a private chunk name by specifying a
lowercase letter for the second character. Such chunk types need not
be registered.  But note that others may use the same private chunk
name, so it is prudent to store additional identifying information at
the beginning of the chunk data.
\par 
Please note that if you want to use a private chunk for information
that is not essential to view the image, and have any desire
whatsoever that others not using your own viewer software be able
to view the image, you should use an ancillary chunk type (first
character is lowercase) rather than a critical chunk type (first
character uppercase).
\par 
If an ancillary chunk is to contain textual information that might be
of interest to a human user, it is recommended that a special chunk
type {\bf not} be used.  Instead use a {\tt tEXt} chunk
and define a suitable keyword.  In this way, the information will be
available to users not using your software.
\par 
If of general usefulness, new keywords for {\tt tEXt} chunks may be
registered with the maintainers of the PNG specification.  Keywords
should be chosen to be reasonably self-explanatory, since the idea is
to let other users figure out what the chunk contains.

\section{Recommendations for Decoders\label{DECODERS}}

This chapter gives some recommendations for decoder behavior.  The
only absolute requirement on a PNG decoder is that it successfully
read any file conforming to the format specified in the preceding
chapters.  However, best results will usually be achieved by following
these recommendations.

\subsection{Chunk error checking\label{D:CHUNK ERROR CHECKING}}

Unknown chunk types must be handled as described under
Chunk naming conventions (page \pageref{CHUNK NAMING CONVENTIONS}).
\par 
It is strongly recommended that decoders verify the CRC on each chunk.
\par 
For known-length chunks such as {\tt IHDR}, decoders should treat
an unexpected chunk length as an error.  Future extensions to this
specification will not add new fields to existing chunks; instead, new
chunk types will be added to carry any new information.
\par 
Unexpected values in fields of known chunks (for example, an
unexpected compression type in the {\tt IHDR} chunk) should be
checked for and treated as errors.

\subsection{Pixel dimensions\label{D:PIXEL DIMENSIONS}}

Non-square pixels can be represented (see the {\tt pHYs} chunk),
but viewers are not required to account for them; a viewer may present
any PNG file as though its pixels are square.
\par 
Conversely, viewers running on display hardware with non-square pixels
are strongly encouraged to rescale images for proper display.

\subsection{Truecolor image handling\label{D:TRUECOLOR IMAGE HANDLING}}

To achieve PNG's goal of universal interchangeability, decoders are
required to accept all types of PNG image: palette, truecolor, and
grayscale.  Viewers running on palette-mapped display hardware need to
be able to reduce truecolor images to palette form for viewing.  This
process is usually called ``color quantization''.
\par 
A simple, fast way of doing this is to reduce the image to a fixed
palette.  Palettes with uniform color spacing (``color cubes'') are
usually used to minimize the per-pixel computation.  For
photograph-like images, dithering is recommended to avoid ugly contours
in what should be smooth gradients; however, dithering introduces
graininess which may be objectionable.
\par 
The quality of rendering can be improved substantially by using a
palette chosen specifically for the image, since a color cube usually
has numerous entries that are unused in any particular image.  This
approach requires more work, first in choosing the palette, and second
in mapping individual pixels to the closest available color.  PNG
allows the encoder to supply a suggested palette in a {\tt PLTE}
chunk, but not all encoders will do so, and the suggested palette may
be unsuitable in any case (it may have too many or too few colors).
High-quality viewers will therefore need to have a palette selection
routine at hand.  A large lookup table is usually the most feasible
way of mapping individual pixels to palette entries with adequate speed.
\par 
Numerous implementations of color quantization are available.  The PNG
reference implementation will include code for the purpose.

\subsection{Decoder gamma handling\label{D:DECODER GAMMA HANDLING}}

To produce correct tone reproduction, a good image display
program must take into account the gammas of both the image
file and the display device.  This can be done by calculating
\bverbatim 
\verb|  |gbright := pixelval /\allowbreak{} MAXPIXVAL
\verb|  |bright := gbright \^{ } (1.0 /\allowbreak{} file\_gamma)
\verb|  |gcvideo := bright \^{ } (1.0 /\allowbreak{} display\_gamma)
\verb|  |fbval := ROUND(gcvideo * MAXFBVAL)
\everbatim 
where {\tt MAXPIXVAL} is the maximum pixel value in the file (255
for 8-bit, 65535 for 16-bit, etc), {\tt MAXFBVAL} is the maximum
value of a frame buffer pixel (255 for 8-bit, 31 for 5-bit, etc),
{\tt pixelval} is the value of the pixel in the PNG file, and
{\tt fbval} is the value to write into the frame buffer.  The first
line converts from pixel code into a normalized 0 to 1 floating point
value, the second undoes the encoding of the image file to produce a
linear brightness value, the third line pre-corrects for the monitor's
gamma response, and the fourth converts
to an integer frame buffer pixel.  In practice the second and third
lines can be merged into
\bverbatim 
\verb|  |gcvideo := gbright \^{ } (1.0 /\allowbreak{} (file\_gamma * display\_gamma))
\everbatim 
so as to perform only one power calculation.  For color images,
the entire calculation is performed separately for R, G, and B values.
\par 
It is {\em not} necessary to perform transcendental math for every
pixel!  Instead, compute a lookup table that gives the correct output
value for every pixel value.  This requires only 256 calculations 
per image (for 8-bit accuracy), not one calculation per pixel.
For palette-based images, a one-time correction of the palette
is sufficient.
\par 
In some cases even computing a gamma lookup table may be a
concern. In these cases, viewers are encouraged to have precomputed
gamma correction tables for file\_gamma values of 1.0 and 0.45 and some
reasonable single display\_gamma value, and to use the table closest to
the gamma indicated in the file.  This will produce acceptable results
for the majority of real files.
\par 
When the incoming image has unknown gamma (no {\tt gAMA} chunk),
choose a likely default file\_gamma value, but allow the user to select
a new one if the result proves too dark or too light.
\par 
In practice, it is often difficult to determine what value of
display\_gamma should be used.  In systems with no built-in gamma
correction, the display\_gamma is determined entirely by the CRT.
Assuming a value of 2.2 is recommended, unless you have detailed
calibration measurements of this particular CRT available.
\par 
However, many modern frame buffers have lookup tables that are used to
perform gamma correction, and on these systems the display\_gamma value
should be the gamma of the lookup table and CRT combined.  You may not
be able to find out what the lookup table contains from within an
image viewer application, so you may have to ask the user what the
system's gamma value is.  Unfortunately, different manufacturers use
different ways of specifying what should go into the lookup table, so
interpretation of the system gamma value is system-dependent.
\par 
Here are examples of how to deal with some known systems:
\begin{itemize}
\item  
On many Macintosh systems, there is a ``gamma'' control panel
that lets you select one of a small set of gamma values
(1.0, 1.4, 1.8, 2.2).  These numbers are the combined gamma
of the hardware table and the CRT, and so they are exactly
the value that the decoder needs to use as display\_gamma.
With the ``gamma'' control panel turned off, or not present at
all, the default Macintosh system gamma is 1.8.
\item 
On recent SGI systems, there is a hardware gamma-correction
table whose contents are controlled by the (privileged) ``gamma''
program.  The gamma of the table is actually the reciprocal of
the number that ``gamma'' prints, and does not include the CRT
gamma.  To obtain the display\_gamma, you need to find the
SGI system gamma (either by looking in a file, or asking the
user) and then calculating
\bverbatim 
\verb|  |display\_gamma = 2.2 /\allowbreak{} SGI\_system\_gamma
\everbatim 
You will find SGI systems with the system gamma set to 1.0 and 2.2 (or
higher), but the default when machines are shipped is 1.7.
\item 
On frame buffers that have hardware gamma correction tables,
and which are calibrated to display linear pixels correctly,
display\_gamma is 1.0.
\item 
Many workstations and Xterms and PC displays lack gamma correction
hardware.  Here, assume that display\_gamma is 2.2.
\end{itemize}
\par 
We should point out that there is a fudge factor built into the
use of the magic value ``2.2'' as the assumed CRT gamma in the
calculations above.  Real CRTs usually have a higher gamma than this,
around 2.8 in fact.  By doing the display gamma correction for a CRT
gamma of only 2.2, we get an image on screen that is slightly higher
in contrast than the original scene.  This is normal TV and film
practice, and we are continuing it here.  Generally, writers of
display programs are best to assume that CRT gamma is 2.2 rather than
using actual measurements.
\par 
If you have carefully measured the gamma of your CRT, you might want
to set display\_gamma to your\_CRT\_gamma/\allowbreak{}1.25, in order to preserve this
intentional contrast boost.
\par 
Finally, note that the response of real displays is actually
more complex than can be described by a single number
(display\_gamma). If actual measurements of the monitor's light
output as a function of voltage input are available, the third
and fourth lines of the computation above may be replaced by a
lookup in these measurements, to find the actual frame buffer
value that most nearly gives the desired brightness.

\subsection{Background color\label{D:BACKGROUND COLOR}}

Viewers which have a specific background against which to present the
image will ignore the {\tt bKGD} chunk, but viewers with no preset
background color may choose to honor it.  The background color will
typically be used to fill unused screen space around the image, as
well as any transparent pixels within the image.  (Thus, {\tt bKGD}
is valid and useful even when the image does not use transparency.)
If no {\tt bKGD} chunk is present, the viewer must make its own
decision about a suitable background color.

\subsection{Alpha channel processing\label{D:ALPHA CHANNEL PROCESSING}}

In the most general case, the alpha channel can be used to composite a
foreground image against a background image; the PNG file defines the
foreground image and the transparency mask, but not the background
image.  Decoders are {\em not} required to support this most
general case.  It is expected that most will be able to support
compositing against a single background color, however.
\par 
The equation for computing a composited pixel value is
\bverbatim 
\verb|  |output := alpha * foreground + (1-alpha) * background
\everbatim 
where alpha and the input and output sample values are expressed as
fractions in the range 0 to 1.  This computation should be performed
with linear (non-gamma-corrected) sample values.  For color images,
the computation is done separately for R, G, and B samples.
\par 
The following code illustrates the general case of compositing a
foreground image over a background image.  It assumes that you have
the original pixel data available for the background image, and that
output is to a frame buffer for display.  Other variants are possible;
see the comments below the code.  The code allows the bit depths and
gamma values of foreground image, background image, and frame
buffer/\allowbreak{}CRT to all be different.  Don't assume they are the same
without checking!
\par 
There are line numbers for referencing code in the comments below.
Other than that, this is standard C.
\bverbatim 
01  int foreground[4];      /\allowbreak{}* file pixel: R, G, B, A */\allowbreak{}
02  int background[3];      /\allowbreak{}* file background color: R, G, B */\allowbreak{}
03  int fbpix[3];           /\allowbreak{}* frame buffer pixel */\allowbreak{}
04  int fg\_maxpixval;       /\allowbreak{}* foreground max pixel */\allowbreak{}
05  int bg\_maxpixval;       /\allowbreak{}* background max pixel */\allowbreak{}
06  int fb\_maxpixval;       /\allowbreak{}* frame buffer max pixel */\allowbreak{}
07  int ialpha;
08  float alpha, compalpha;
09  float gamfg, linfg, gambg, linbg, comppix, gcvideo;
\vspace{\baselineskip}
\verb|    |/\allowbreak{}* Get max pixel value in files and frame buffer */\allowbreak{}
10  fg\_maxpixval = (1 << fg\_bit\_depth) - 1;
11  bg\_maxpixval = (1 << bg\_bit\_depth) - 1;
12  fb\_maxpixval = (1 << frame\_buffer\_bit\_depth) - 1;
\verb|    |/\allowbreak{}*
\verb|     |* Get integer version of alpha.
\verb|     |* Check for opaque and transparent special cases;
\verb|     |* no compositing needed if so.
\verb|     |*
\verb|     |* We show the whole gamma decode/\allowbreak{}correct process in
\verb|     |* floating point, but it would more likely be done
\verb|     |* with lookup tables.
\verb|     |*/\allowbreak{}
13  ialpha = foreground[3];
14  if (ialpha == 0) \{
\verb|        |/\allowbreak{}*
\verb|         |* Foreground image is transparent here.
\verb|         |* If the background image is already in the frame
\verb|         |* buffer, there is nothing to do.
\verb|         |*/\allowbreak{}
15      ;
16  \} else if (ialpha == fg\_maxpixval) \{
17      for (i = 0; i < 3; i++ \{
18          gamfg = (float) foreground[i] /\allowbreak{} fg\_maxpixval;
19          linfg = pow(gamfg, 1.0/\allowbreak{}fg\_gamma);
20          comppix = linfg;
21          gcvideo = pow(comppix, 1.0/\allowbreak{}display\_gamma);
22          fbpix[i] = (int) (gcvideo * fb\_maxpixval + 0.5);
23      \}
24  \} else \{
\verb|        |/\allowbreak{}*
\verb|         |* Compositing is necessary.
\verb|         |* Get floating-point alpha and its complement.
\verb|         |* Note: alpha is always linear; gamma does not
\verb|         |* affect it.
\verb|         |*/\allowbreak{}
25      alpha = (float) ialpha /\allowbreak{} fg\_maxpixval;
26      compalpha = 1.0 - alpha;
\vspace{\baselineskip}
27      for (i = 0; i < 3; i++ \{
\verb|            |/\allowbreak{}*
\verb|             |* Convert foreground and background to floating point,
\verb|             |* then linearize (undo gamma encoding).
\verb|             |*/\allowbreak{}
28          gamfg = (float) foreground[i] /\allowbreak{} fg\_maxpixval;
29          linfg = pow(gamfg, 1.0/\allowbreak{}fg\_gamma);
30          gambg = (float) background[i] /\allowbreak{} bg\_maxpixval;
31          linbg = pow(gambg, 1.0/\allowbreak{}bg\_gamma);
\verb|            |/\allowbreak{}*
\verb|             |* Composite.
\verb|             |*/\allowbreak{}
32          comppix = linfg * alpha + linbg * compalpha;
\verb|            |/\allowbreak{}*
\verb|             |* Gamma correct for display.
\verb|             |* Convert to integer frame buffer pixel.
\verb|             |*/\allowbreak{}
33          gcvideo = pow(comppix, 1.0/\allowbreak{}display\_gamma);
34          fbpix[i] = (int) (gcvideo * fb\_maxpixval + 0.5);
35      \}
36  \}
\everbatim 
Variations:
\begin{enumerate}
\item  
If output is to another PNG image file instead of a frame buffer,
lines 21, 22, 33, and 34 should be changed to be something like:
\bverbatim 
\verb|        |/\allowbreak{}*
\verb|         |* Gamma encode for storage in output file.
\verb|         |* Convert to integer pixel value.
\verb|         |*/\allowbreak{}
\verb|        |gamout = pow(comppix, outfile\_gamma);
\verb|        |outpix[i] = (int) (gamout * out\_maxpixval + 0.5);
\everbatim 
Also, it becomes necessary to process background pixels when alpha
is zero, rather than just skipping pixels.  Thus, line 15 must be
replaced by copies of lines 18-22, but processing background instead
of foreground pixel values.
\item 
If the bit depth of the output file, foreground file, and
background file are all the same, and the three gamma values also match,
then the no-compositing code in lines 14-23 reduces to nothing more than
copying pixel values from the input file to the output file if alpha is
one, or copying pixel values from background to output file if alpha is
zero.  Since alpha is typically either zero or one for the
vast majority of pixels in an image, this is a great savings.
No gamma computations are needed for most pixels.
\item 
When the bit depths and gamma values all match, it may appear
attractive to skip the gamma decorrection and correction (lines 28-31,
33-34) and just perform line 32 using gamma-encoded sample values.
Although this doesn't hurt image quality too badly, the time savings
are small if alpha values of zero and one are special-cased
as recommended here.
\item 
If the original pixel values of the background image are no longer
available, only processed frame buffer pixels left by display of the
background image, then lines 30 and 31 must extract intensity from
the frame buffer pixel values using code like:
\bverbatim 
\verb|        |/\allowbreak{}*
\verb|         |* Decode frame buffer value back into linear space.
\verb|         |*/\allowbreak{}
\verb|        |gcvideo = (float) (fbpix[i] /\allowbreak{} fb\_maxpixval);
\verb|        |linbg = pow(gcvideo, display\_gamma);
\everbatim 
However, some roundoff error can result, so it is better to have the
original background pixels available if at all possible.
\item 
Note that lines 18-22 are performing exactly the same gamma computation
that is done when no alpha channel is present.  So, if you handle the
no-alpha case with a lookup table, you can use the same lookup table here.
Lines 28-31 and 33-34 can also be done with lookup tables.
\item  
Of course, everything here can be done in integer arithmetic.  Just
be careful to maintain sufficient precision all the way through.
\end{enumerate}
\par 
Note: in floating point, no overflow or underflow checks are needed, because
the input pixel values are guaranteed to be between 0 and 1, and compositing
always yields a result that is in between the input values (inclusive).
With integer arithmetic, some roundoff-error analysis might be needed
to guarantee no overflow or underflow.
\par 
When displaying a PNG image with full alpha channel, it is important
to be able to composite the image against some background, even if
it's only black.  Ignoring the alpha channel will cause PNG images
that have been converted from an associated-alpha representation to
look wrong.  (Of course, if the alpha channel is a separate
transparency mask, then ignoring alpha is a useful option: it allows
the hidden parts of the image to be recovered.)
\par 
When dealing with PNG images that have a {\tt tRNS} chunk, it is
reasonable to assume that the transparency information is a mask
rather than associated-alpha coverage data.  In this case, it is an
acceptable shortcut to interpret all nonzero alpha values as fully
opaque (no background).  This approach is simple to implement:
transparent pixels are replaced by the background color, others are
unchanged.  A viewer with no particular background color preference
may even choose to ignore the {\tt tRNS} chunk; but if a
{\tt bKGD} chunk is provided, it is better to use the specified
background color.

\subsection{Progressive display\label{D:PROGRESSIVE DISPLAY}}

When receiving images over slow transmission links, decoders can
improve perceived performance by displaying interlaced images
progressively.  This means that as each pass is received, an
approximation to the complete image is displayed based on the data
received so far.  One simple yet pleasing effect can be obtained by
expanding each received pixel to fill a rectangle covering the
yet-to-be-transmitted pixel positions below and to the right of the
received pixel.  This process can be described by the following
pseudocode:

\bverbatim 
Starting\_Row [1..7] =  \{ 0, 0, 4, 0, 2, 0, 1 \}
Starting\_Col [1..7] =  \{ 0, 4, 0, 2, 0, 1, 0 \}
Row\_Increment [1..7] = \{ 8, 8, 8, 4, 4, 2, 2 \}
Col\_Increment [1..7] = \{ 8, 8, 4, 4, 2, 2, 1 \}
Block\_Height [1..7] =  \{ 8, 8, 4, 4, 2, 2, 1 \}
Block\_Width [1..7] =   \{ 8, 4, 4, 2, 2, 1, 1 \}
\vspace{\baselineskip}
pass := 1
while pass <= 7
begin
\verb|    |row := Starting\_Row[pass]
\vspace{\baselineskip}
\verb|    |while row < height
\verb|    |begin
\verb|        |col := Starting\_Col[pass]
\vspace{\baselineskip}
\verb|        |while col < width
\verb|        |begin
\verb|            |visit (row, col,
\verb|                   |min (Block\_Height[pass], height - row),
\verb|                   |min (Block\_Width[pass], width - col))
\verb|            |col := col + Col\_Increment[pass]
\verb|        |end
\verb|        |row := row + Row\_Increment[pass]
\verb|    |end
\vspace{\baselineskip}
\verb|    |pass := pass + 1
end
\everbatim 
Here, the function ``visit(row,column,height,width)'' obtains the next
transmitted pixel and paints a rectangle of the specified height and
width, whose upper-left corner is at the specified row and column,
using the color indicated by the pixel.
Note that row and column are measured from 0,0 at the upper left corner.
\par 
If the decoder is merging the received image with a background image,
it may be more convenient just to paint the received pixel positions;
that is, the ``visit()'' function sets only the pixel at the specified
row and column, not the whole rectangle.  This produces a ``fade-in''
effect as the new image gradually replaces the old.  An advantage of
this approach is that proper alpha or transparency processing can be
done as each pixel is replaced.  Painting a rectangle as described
above will overwrite background-image pixels that may be needed later,
if the pixels eventually received for those positions turn out to be
wholly or partially transparent.  Of course, this is only a problem if
the background image is not stored anywhere offscreen.

\subsection{Palette histogram usage\label{D:PALETTE HISTOGRAM USAGE}}

If the viewer is only short a few colors, it is usually adequate to
drop the least-used colors from the palette.  To reduce the number of
colors substantially, it's best to choose entirely new representative
colors, rather than trying to use a subset of the existing palette.
This amounts to performing a new color quantization step; however, the
existing palette and histogram can be used as the input data, thus
avoiding a scan of the image data.
\par 
If no histogram chunk is provided, a decoder can of course develop its
own, at the cost of an extra pass over the image data.

\subsection{Text chunk processing\label{D:TEXT CHUNK PROCESSING}}

If practical, decoders should have a way to display to the user all
{\tt tEXt} and {\tt zTXt} chunks found in the file.  Even if the 
decoder does not recognize a particular text keyword, the user may well 
be able to understand it.
\par 
Decoders should be prepared to display text chunks which contain any
number of printing characters between newline characters, even though
encoders are encouraged to avoid creating lines in excess of 79
characters.

\section{Appendix: Rationale\label{RATIONALE}}

(This appendix is not part of the formal PNG specification.)
\par 
This appendix gives the reasoning behind some of the design decisions
in PNG.  Many of these decisions were the subject of considerable
debate.  The authors freely admit that another group might have made
different decisions; however, we believe that our choices are
defensible and consistent.

\subsection{Why a new file format?\label{R:WHY A NEW FILE FORMAT?}}

Does the world really need yet another graphics format?  We believe
so.  GIF is no longer freely usable, but no other commonly used format
can directly replace it, as is discussed in more detail below.  We
might have used an adaptation of an existing format, for example GIF
with an unpatented compression scheme.  But this would require new
code anyway; it would not be all that much easier to implement than a
whole new file format.  (PNG is designed to be
simple to implement, with the exception of the compression
engine, which would be needed in any case.)  We feel that this is an
excellent opportunity to design a new format that fixes some of the
known limitations of GIF.

\subsection{Why these features?\label{R:WHY THESE FEATURES?}}

The features chosen for PNG are intended to address the needs of
applications that previously used the special strengths of GIF.
In particular, GIF is well adapted for on-line communications
because of its streamability and progressive display capability.
PNG shares those attributes.
\par 
We have also addressed some of the widely known shortcomings of GIF.
In particular, PNG supports truecolor images.  We know of no widely
used image format that losslessly compresses truecolor images as
effectively as PNG does.  We hope that PNG will make use of
truecolor images more practical and widespread.
\par 
Some form of transparency control is desirable for applications
in which images are displayed against a background or together with
other images.  GIF provided a simple transparent-color specification
for this purpose.  PNG supports a full alpha channel as well as
transparent-color specifications.  This allows both highly flexible
transparency and compression efficiency.
\par 
Robustness against transmission errors has been an important
consideration.  For example, images transferred across Internet are
often mistakenly processed as text, leading to file corruption.  PNG
is designed so that such errors can be detected quickly and reliably.
\par 
PNG has been expressly designed not to be completely
dependent on a single compression technique. Although
inflate/\allowbreak{}deflate compression is mentioned in this
document, PNG would still exist without it.

\subsection{Why not these features?\label{R:WHY NOT THESE FEATURES?}}

Some features have been deliberately omitted from PNG.  These choices
were made to simplify implementation of PNG, promote portability and
interchangeability, and make the format as simple and foolproof as
possible for users.  In particular:
\begin{itemize}
\item  
There is no uncompressed variant of PNG.  It is possible to store
uncompressed data by using only uncompressed deflate blocks (a feature
normally used to guarantee that deflate does not make incompressible
data much larger).  However, any software that does not support full
deflate/\allowbreak{}inflate will not be considered compliant with the PNG
standard. The two most important features of PNG---portability and
compression---are absolute requirements for online applications, and
users demand them. Failure to support full deflate/\allowbreak{}inflate compromises
both of these objectives.
\item  
There is no lossy compression in PNG.  Existing formats such as JFIF
already handle lossy compression well.  Furthermore, available lossy
compression methods (e.g., JPEG) are far from foolproof to use --- a
poor choice of quality level can ruin an image.  To avoid user
confusion and unintentional loss of information, we feel it is best to
keep lossy and lossless formats strictly separate.  Also, lossy compression
is complex to implement.  Adding JPEG support to a PNG decoder
might increase its size by an order of magnitude.  This would
certainly cause some decoders to omit support for the feature, which
would destroy our goal of interchangeability.
\item  
There is no support for CMYK or other unusual color spaces.
Again, this is in the name of promoting portability.  CMYK, in
particular, is far too device-dependent to be useful as a portable
image representation.
\item 
There is no standard chunk for thumbnail views of images.  In
discussions with software vendors who use thumbnails in their
products, it has become clear that most would not use a ``standard''
thumbnail chunk. This is partly because every vendor has a distinct
idea of what the dimensions and characteristics of a thumbnail should
be, and partly because vendors who keep thumbnails in separate files
to accommodate varied image formats are not going to stop doing that
simply because of a thumbnail chunk in one new format.  Proprietary
chunks containing vendor-specific thumbnails appear to be more
practical than a common thumbnail format.
\end{itemize}
It is worth noting that private extensions to PNG could easily add
these features.  We will not, however, include them as part of the
basic PNG standard.
\par 
Basic PNG also does not support multiple images in one file.
This restriction is a reflection of the reality that many applications
do not need and will not support multiple images per file.  (While the
GIF standard nominally allows multiple images per file, few
applications actually support it.)  In any case, single images are a
fundamentally different sort of object from sequences of images.
Rather than make false promises of
interchangeability, we have drawn a clear distinction between
single-image and multi-image formats.  PNG is a single-image format.

\subsection{Why not use format XYZ?\label{R:WHY NOT USE FORMAT XYZ?}}

Numerous existing formats were considered before deciding
to develop PNG.  None could meet the requirements we felt
were important for PNG.
\par 
GIF is no longer suitable as a universal standard because of legal
entanglements.  Although just replacing GIF's compression method would
avoid that problem, GIF does not support truecolor images, alpha
channels, or gamma correction.  The spec has more subtle problems too.
Only a small subset of the GIF89 spec is actually portable across a
variety of implementations, but there is no codification of the most
portable part of the spec.
\par 
TIFF is far too complex to meet our goals of simplicity and
interchangeability.  Defining a TIFF subset would meet that objection,
but would frustrate users making the reasonable assumption that a file
saved as TIFF from Software XYZ would load into a program supporting
our flavor of TIFF.  Furthermore, TIFF is not designed for stream
processing, has no provision for progressive display, and does not
currently provide any good, legally unencumbered, lossless compression
method.
\par 
IFF has also been suggested, but is not suitable in detail: available
image representations are too machine-specific or not adequately
compressed.  The overall chunk structure of IFF is a useful concept
which PNG has liberally borrowed from, but we did not attempt to be
bit-for-bit compatible with IFF chunk structure.  Again this is due to
detailed issues, notably the fact that IFF FORMs are not designed to
be serially writable.
\par 
Lossless JPEG is not suitable because it does not provide for the
storage of palette-color images.  Furthermore, its lossless truecolor
compression is often inferior to that of PNG.

\subsection{Byte order\label{R:BYTE ORDER}}

It has been asked why PNG uses network byte order.
We have selected one byte ordering and used it
consistently. Which order in particular is
of little relevance, but network byte order
has the advantage that routines to convert
to and from it are already available on any
platform that supports TCP/\allowbreak{}IP networking,
{\bf including} all PC platforms.
The functions are trivial and will be included
in the reference implementation.

\subsection{Interlacing\label{R:INTERLACING}}

PNG's two-dimensional interlacing scheme is more complex
to implement than GIF's line-wise interlacing.  It also costs a
little more in file size.  However, it yields an initial image
{\em eight times} faster than GIF (the first pass transmits
only 1/\allowbreak{}64th of the pixels, compared to 1/\allowbreak{}8th for GIF).  Although
this initial image is coarse, it is useful in many situations.
For example, if the image is a World Wide Web imagemap that the
user has seen before, PNG's first pass is enough to determine where to
click.  The PNG scheme also looks better than GIF's, because
horizontal and vertical resolution never differ by more than a factor
of two; this avoids the odd ``stretched'' look seen when interlaced
GIFs are filled in by replicating scanlines.

\subsection{Why gamma encoding?\label{R:WHY GAMMA ENCODING?}}

Although gamma 1.0 (linear brightness response) might seem a natural
standard, it is common for images to have a gamma of less than 1.
There are two good reasons for this:
\begin{itemize}
\item  
CRT hardware typically has a gamma between 2 and 3.  Hence,
``gamma correction'' is a standard part of all video signals.
The transmitted image usually has a gamma of 0.45 (NTSC) or 0.36
(PAL/\allowbreak{}SECAM), so images obtained by frame-grabbing video
already have this value of gamma.
\item  
An image gamma less than 1 allocates more of the available pixel codes
or voltage range to darker areas of the image.  This allows
photographic-quality images to be stored in only 24 bits/\allowbreak{}pixel without
banding artifacts in the darker areas (in most cases).  This makes
``gamma encoding'' a much better way of storing digital images than the
simpler linear encoding.
\end{itemize}
In practice, image gamma values around 1.0 and around 0.45 are
both widely found.  Older image standards such as GIF often do not
account for this fact, leading to
widespread problems with images coming out ``too dark'' or ``too light''.
\par 
PNG expects viewers to compensate for image gamma at the time that the
image is displayed.  Another possible approach is to expect encoders
to convert all images to a uniform gamma at encoding time.  While that
method would speed viewers slightly, it has fundamental flaws:
\begin{itemize}
\item  Gamma correction is inherently lossy due to roundoff error.
Requiring conversion at encoding time thus causes irreversible loss.
Since PNG is intended to be a lossless storage format, this is
undesirable; we should store unmodified source data.
\item  The encoder might not know the image gamma.  If the decoder does
gamma correction at viewing time, it can adjust the gamma (correct the
displayed brightness) in response to feedback from a human user.  The
encoder has no such option.
\item  Whatever ``standard'' gamma we settled on would be wrong for some
displays.  Hence viewers would still need gamma correction
capability.
\end{itemize}
Since there will always be images with no gamma or an incorrect
recorded gamma, good viewers will need to incorporate gamma
correction logic anyway.  Gamma correction at viewing time is thus the
right way to go.

\subsection{Non-premultiplied alpha\label{R:NON-PREMULTIPLIED ALPHA}}

PNG uses ``unassociated'' or ``non-premultiplied'' alpha so that
images with separate transparency masks can be stored losslessly.
Another common technique, ``premultiplied alpha'', stores pixel values
premultiplied by the alpha fraction; in effect, the image is already
composited against a black background.  Any image data hidden by the
transparency mask is irretrievably lost by that method, since
multiplying by a zero alpha value always produces zero.
\par 
Some image rendering techniques generate images with premultiplied
alpha (the alpha value actually represents how much of the pixel is
covered by the image).  This representation can be converted to PNG by
dividing the RGB values by alpha, except where alpha is zero.  The
result will look good if displayed by a viewer that handles alpha
properly, but will not look very good if the viewer ignores the alpha
channel.
\par 
Although each form of alpha storage has its advantages, we did not
want to require all PNG viewers to handle both forms.  We standardized
on non-premultiplied alpha as being the more general case.

\subsection{Filtering\label{R:FILTERING}}

PNG includes filtering capability because filtering can significantly
reduce the compressed size of truecolor and grayscale images.
Filtering is also sometimes of value on palette images, although this
is less common.
\par 
The filter algorithms are defined to operate on bytes, rather than
pixels; this gains simplicity and speed with very little cost in
compression performance.  Tests have shown that filtering is
usually ineffective for images with fewer than 8 bits per pixel, so
providing pixelwise filtering for such images would be pointless.
For 16 bit/\allowbreak{}pixel data, bytewise filtering is nearly as effective as
pixelwise filtering, because MSBs are predicted from adjacent MSBs,
and LSBs are predicted from adjacent LSBs.
\par 
The encoder is allowed to change filters for each new scanline.
This creates no additional complexity for decoders, since a decoder is
required to contain unfiltering logic for every filter type anyway.
The only cost is an extra byte per scanline in the pre-compression
data stream.  Our tests showed that when the same filter is selected
for all scanlines, this extra byte compresses away to almost nothing,
so there is little storage cost compared to a fixed filter specified
for the whole image.  And the potential benefits of adaptive filtering
are too great to ignore.  Even with the simplistic filter-choice
heuristics so far discovered, adaptive filtering usually outperforms
fixed filters.  In particular, an adaptive filter can change behavior
for successive passes of an interlaced image; a fixed filter cannot.
\par 
The basic filters offered by PNG have been chosen on both
theoretical and experimental grounds.  In particular, it is worth
noting that all the filters (except ``none'' and ``average'') operate by encoding 
the difference between a pixel and one of its neighboring pixels.
This is usually superior to conventional linear prediction equations because
the prediction is certain to be one of the possible pixel values.
When the source data is not full depth (such as 5-bit data scaled up
to 8-bit depth), this restriction ensures that the number of prediction
delta values is no more than the number of distinct pixel values
present in the source data.  A linear equation can produce
intermediate values not actually present in the source data, and thus
reduce compression efficiency.

\subsection{Text strings\label{R:TEXT STRINGS}}

Most graphics file formats include the ability to store some textual
information along with the image.  But many applications need more
than that: they want to be able to store several identifiable pieces
of text.  For example, a database using PNG files to store medical
X-rays would likely want to include patient's name, doctor's name,
etc.  A simple way to do this in PNG would be to invent new
proprietary chunks holding text.  The disadvantage of such an approach
is that other applications would have no idea what was in those
chunks, and would simply ignore them.  Instead, we recommend that text
information be stored in standard {\tt tEXt} chunks with suitable
keywords.  Use of {\tt tEXt} tells any PNG viewer that the chunk
contains text that may be of interest to a human user.  Thus, a person
looking at the file with another viewer will still be able to see the
text, and even understand what it is if the keywords are reasonably
self-explanatory.  (To this end, we recommend spelled-out keywords,
not abbreviations that will be hard for a person to understand.
Saving a few bytes on a keyword is false economy.)
\par 
The ISO 8859-1 (Latin-1) character set was chosen as a compromise
between functionality and portability.  Some platforms cannot
display anything more than 7-bit ASCII characters, while others
can handle characters beyond the Latin-1 set.  We felt that Latin-1
represents a widely useful and reasonably portable character set.
Latin-1 is a direct subset of character sets commonly used on
popular platforms such as Microsoft Windows and X Windows.  It can
also be handled on Macintosh systems with a simple remapping of
characters.
\par 
There is at present no provision for text employing character
sets other than the Latin-1 character set. It is
recognized that the need for other character sets will increase.
However, PNG already requires that programmers implement a
number of new and unfamiliar features, and text representation 
is not PNG's primary purpose. Since PNG provides for the creation
and public registration of new ancillary chunks of general interest,
it is expected that text chunks for other character sets, such
as Unicode, eventually will be registered and increase gradually in
popularity.

\subsection{PNG file signature\label{R:PNG FILE SIGNATURE}}

The first eight bytes of a PNG file always contain the following
values:
\par 
\bverbatim 
(decimal)              137  80  78  71  13  10  26  10
(hex)                   89  50  4e  47  0d  0a  1a  0a
(ASCII C notation)    {\tt\symbol{92}}211   P   N   G  {\tt\symbol{92}}r  {\tt\symbol{92}}n {\tt\symbol{92}}032 {\tt\symbol{92}}n
\everbatim 
\par 
This signature both identifies the file as a PNG file and provides for
immediate detection of common file-transfer problems.
The first two bytes distinguish PNG files on systems that expect the
first two bytes to identify the file type uniquely.  The first byte is
chosen as a non-ASCII value to reduce the probability that a text file
may be misrecognized as a PNG file; also, it catches bad file
transfers that clear bit 7.  Bytes two through four name the format.
The CR-LF sequence catches bad file transfers that alter newline
sequences.  The control-Z character stops file display under MS-DOS.
The final line feed checks for the inverse of the CR-LF translation
problem.
\par 
Additional confidence in correct file transfer can be had by checking
that the next eight bytes are an {\tt IHDR} chunk header with the
correct chunk length.
\par 
Note that there is no version number in the signature, nor indeed
anywhere in the file.  This is intentional: the chunk mechanism
provides a better, more flexible way to handle format extensions, as
is described below.

\subsection{Chunk layout\label{R:CHUNK LAYOUT}}

The chunk design allows decoders to skip unrecognized or uninteresting
chunks: it is simply necessary to skip the appropriate number of
bytes, as determined from the length field.
\par 
Limiting chunk length to (2\^{ }31)-1 bytes avoids possible problems for
implementations that cannot conveniently handle 4-byte unsigned values.
In practice, chunks will usually be much shorter than that anyway.
\par 
A separate CRC is provided for each chunk in order to detect
badly-transferred images as quickly as possible.  In particular,
critical data such as the image dimensions can be validated before
being used.  The chunk length is excluded in order to permit CRC
calculation while data is generated (possibly before the length is
known, in the case of variable-length chunks); this may avoid an extra
pass over the data.  Excluding the length from the CRC does not create
any extra risk of failing to discover file corruption, since if the
length is wrong, the CRC check will fail (the CRC will be computed on
the wrong bytes and then tested against the wrong value from the
file).

\subsection{Chunk naming conventions\label{R:CHUNK NAMING CONVENTIONS}}

The chunk naming conventions allow safe, flexible extension of the PNG
format.  This mechanism is much better than a format version number,
because it works on a feature-by-feature basis rather than being an
overall indicator.  Decoders can process newer files if and only if
the files use no unknown critical features (as indicated by finding
unknown critical chunks).  Unknown ancillary chunks can be safely
ignored.  Experience has shown that format version numbers hurt
portability as much as they help.  Version numbers tend to be set
unnecessarily high, leading to older decoders rejecting files that
they could have processed (this was a serious problem for several
years after the GIF89 spec came out, for example).  Furthermore,
private extensions can be made either critical or ancillary, and
standard decoders will react appropriately; overall version numbers
are no help for private extensions.
\par 
A hypothetical chunk for vector graphics would be a critical chunk,
since if ignored, important parts of the intended image would be
missing.  A chunk carrying the Mandelbrot set coordinates for a
fractal image would be ancillary, since other applications could
display the image without understanding what it was.
In general, a chunk type should be made
critical only if it is impossible to display a reasonable
representation of the intended image without interpreting that chunk.
\par 
The public/\allowbreak{}private property bit ensures that any newly defined public
chunk type name cannot conflict with proprietary chunks that may be
in use somewhere.  However, this does not protect users of private
chunk names from the possibility that someone else may re-use the same
chunk name for a different purpose.  It is a good idea to put
additional identifying information at the start of the data for any
private chunk type.
\par 
When a PNG file is modified, certain ancillary chunks may need to be
changed to reflect changes in other chunks. For example, a histogram
chunk needs to be changed if the image data changes.  If the encoder
does not recognize histogram chunks, copying them blindly to a new
output file is incorrect; such chunks should be dropped.  The
safe/\allowbreak{}unsafe property bit allows ancillary chunks to be marked
appropriately.
\par 
Not all possible modification scenarios are covered by the safe/\allowbreak{}unsafe
semantics.  In particular, chunks that are dependent on the total file
contents are not supported.  (An example of such a chunk is an index
of {\tt IDAT} chunk locations within the file: adding a comment
chunk would inadvertently break the index.)  Definition of such chunks is
discouraged.  If absolutely necessary for a particular application,
such chunks may be made critical chunks, with consequent loss of
portability to other applications.  In general, ancillary chunks may
depend on critical chunks but not on other ancillary chunks.  It is
expected that mutually dependent information should be put into a
single chunk.
\par 
In some situations it may be unavoidable to make one ancillary chunk
dependent on another.  Although the chunk property bits do not allow
this case to be represented, a simple solution is available: in the
dependent chunk, record the CRC of the chunk depended on.  It can
then be determined whether that chunk has been changed by some other
program.
\par 
The same technique may be useful for other purposes.  For example, if
a program relies on the palette being in a particular order, it may
store a private chunk containing the CRC of the {\tt PLTE} chunk.
If this value matches when the file is again read in, then it provides
high confidence that the palette has not been tampered with.  Note
that it is not necessary to mark the private chunk unsafe-to-copy
when this technique is used; thus, such a private chunk can survive
other editing of the file.

\subsection{Palette histograms\label{R:PALETTE HISTOGRAMS}}

A viewer may not be able to provide as many colors as are listed in
the image's palette.  (For example, some colors may be reserved by a
window system.)  To produce the best results in this situation, it is
helpful to have information on the frequency with which each palette
index actually appears, in order to choose the best palette for
dithering or drop the least-used colors.  Since images are often
created once and viewed many times, it makes sense to calculate this
information in the encoder, although it is not mandatory for the
encoder to provide it.
\par 
The same rationale holds good for palettes which are suggested
quantizations of truecolor images.  In this situation, it is
recommended that the histogram values represent ``nearest neighbor''
counts, that is, the approximate usage of each palette entry if no
dithering is applied.  (These counts will often be available for free
as a consequence of developing the suggested palette.)
\par 
Other image formats have usually addressed this problem by specifying
that the palette entries should appear in order of frequency of use.
That is an inferior solution, because it doesn't give the viewer
nearly as much information: the viewer can't determine how much damage
will be done by dropping the last few colors.  Nor does a sorted
palette give enough information to choose a target palette for
dithering, in the case that the viewer must reduce the number of
colors substantially.  A palette histogram provides the information
needed to choose such a target palette without making a pass over the
image data.

\section{Appendix: Sample CRC Code\label{CRCAPPENDIX}}

The following sample code represents a practical implementation
of the CRC (Cyclic Redundancy Check) employed in PNG chunks.
\par 
The sample code provided is in the C programming language.
(See also ISO 3309 and ITU-T V.42 for a formal specification.)
\bverbatim 
/\allowbreak{}* table of crc's of all 8-bit messages */\allowbreak{}
unsigned long crc\_table[256];
\vspace{\baselineskip}
/\allowbreak{}* Flag: has the table been computed? Initially false. */\allowbreak{}
int crc\_table\_computed = 0; 
\vspace{\baselineskip}
/\allowbreak{}* make the table for a fast crc */\allowbreak{}
void make\_crc\_table(void)
\{
\verb|  |unsigned long c;
\verb|  |int n, k;
\verb| |
\verb|  |for (n = 0; n < 256; n++) \{
\verb|    |c = (unsigned long) n;
\verb|    |for (k = 0; k < 8; k++)
\verb|      |c = (c \& 1) ? (0xedb88320L \^{ } (c >> 1)) : (c >> 1);
\verb|    |crc\_table[n] = c;
\verb|  |\}
\verb|  |crc\_table\_computed = 1;
\}
\vspace{\baselineskip}
/\allowbreak{}* update a running crc with the bytes buf[0..len-1]--the crc should be
\verb|   |initialized to all 1's, and the transmitted value is the 1's complement
\verb|   |of the final running crc (see the crc() routine below)). */\allowbreak{}
\vspace{\baselineskip}
unsigned long update\_crc(unsigned long crc, unsigned char *buf, int len)
\{
\verb|  |unsigned long c = crc;
\verb|  |unsigned char *p = buf;
\verb|  |int n = len;
\vspace{\baselineskip}
\verb|  |if (!crc\_table\_computed)
\verb|    |make\_crc\_table();
\verb|  |if (n > 0) do \{
\verb|    |c = crc\_table[(c \^{ } (*p++)) \& 0xff] \^{ } (c >> 8);
\verb|  |\} while (--n);
\verb|  |return c;
\}
\vspace{\baselineskip}
/\allowbreak{}* return the crc of the bytes buf[0..len-1] */\allowbreak{}
unsigned long crc(unsigned char *buf, int len)
\{
\verb|  |if (!crc\_table\_computed)
\verb|    |make\_crc\_table();
\verb|  |return update\_crc(0xffffffffL, buf, len) \^{ } 0xffffffffL;
\}
\everbatim 

\section{Credits\label{CREDITS}}

\subsection{Editor}
Thomas Boutell\footnote{{\tt<http://sunsite.unc.edu/boutell/index.html>}}, boutell@netcom.com

\subsection{Contributing Editor}
Tom Lane, tgl@sss.pgh.pa.us

\subsection{Authors}
{\em Authors' names are presented in alphabetical order.}
\begin{itemize}
\item Mark Adler, madler@cco.caltech.edu
\item Thomas Boutell, boutell@netcom.com
\item Adam M. Costello, amc@cs.wustl.edu
\item Lee Daniel Crocker, lee@piclab.com
\item Oliver Fromme, fromme@rz.tu-clausthal.de
\item Jean-Loup Gailly, jloup@chorus.fr
\item Alex Jakulin, alex@hermes.si
\item Neal Kettler, kettler@cs.colostate.edu
\item Tom Lane, tgl@sss.pgh.pa.us
\item Dave Martindale, davem@cs.ubc.ca
\item Owen Mortensen, ojm@csi.compuserve.com
\item Glenn Randers-Pehrson, glennrp@arl.mil
\item Greg Roelofs\footnote{{\tt<http://quest.jpl.nasa.gov/Info-ZIP/people/greg/>}}, newt@uchicago.edu
\item Paul Schmidt, photodex@netcom.com
\item Tim Wegner, 71320.675@compuserve.com
\item Jeremy Wohl, jeremy@cs.sunysb.edu
\end{itemize}
\par 
The authors wish to acknowledge the contributions of the Portable
Network Graphics mailing list and the readers of comp.graphics.

\subsection{Trademarks}

GIF is a service mark of CompuServe Incorporated.
Macintosh is a trademark of Apple Computer, Inc.
Microsoft and MS-DOS are trademarks of Microsoft Corporation.
SGI is a trademark of Silicon Graphics, Inc.
X Window System is a trademark of the Massachusetts Institute of
Technology.

\par 
{\em End of PNG Specification}


\end{document}
