PNG: formato del file e compressione Abstract

This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. PNG pro ides a patent-free replacement for G!" and can also replace man# common uses of T!"". !ndexed-color, gra#scale, and truecolor images are supported, plus an optional alpha channel. $ample depths range from % to %& bits. PNG is designed to work well in online iewing applications, such as the 'orld 'ide 'eb, so it is full# streamable with a progressi e displa# option. PNG is robust, pro iding both full file integrit# checking and simple detection of common transmission errors. (lso, PNG can store gamma and chromaticit# data for impro ed color matching on heterogeneous platforms. This specification defines an !nternet )edia T#pe image*png.

Introduction
The design goals for this !nternational $tandard were+

a. Portabilit#+ encoding, decoding, and transmission should be software and hardware platform independent. b. ,ompleteness+ it should be possible to represent truecolour, indexed-colour, and gre#scale images, in each case with the option of transparenc#, colour space information, and ancillar# information such as textual comments. c. $erial encode and decode+ it should be possible for datastreams to be generated seriall# and read seriall#, allowing the datastream format to be used for on-the-fl# generation and displa# of images across a serial communication channel. d. Progressi e presentation+ it should be possible to transmit datastreams so that an approximation of the whole image can be presented initiall#, and progressi el# enhanced as the datastream is recei ed. e. -obustness to transmission errors+ it should be possible to detect datastream transmission errors reliabl#. f. .osslessness+ filtering and compression should preser e all information. g. Performance+ an# filtering, compression, and progressi e image presentation should be aimed at efficient decoding and presentation. "ast encoding is a less important goal than fast decoding. /ecoding speed ma# be achie ed at the expense of encoding speed. h. ,ompression+ images should be compressed effecti el#, consistent with the other design goals. i. $implicit#+ de elopers should be able to implement the standard easil#. j. !nterchangeabilit#+ an# standard-conforming PNG decoder shall be capable of reading all conforming PNG datastreams. k. "lexibilit#+ future extensions and pri ate additions should be allowed for without compromising the interchangeabilit# of standard PNG datastreams. l. "reedom from legal restrictions+ no algorithms should be used that are not freel# a ailable.

1 Scope
This !nternational $tandard specifies a datastream and an associated file format, Portable Network Graphics (PNG, pronounced 0ping0), for a lossless, portable, compressed indi idual computer graphics image transmitted across the !nternet. !ndexed-colour, gre#scale, and truecolour images are supported, with optional transparenc#. $ample depths range from % to %& bits. PNG is full# streamable with a progressi e displa# option. !t is robust, pro iding both full file integrit# checking and simple detection of common transmission errors. PNG can store gamma and chromaticit# data as well as a full !,, colour profile for

accurate colour matching on heterogenous platforms. This $tandard defines the !nternet )edia t#pe 0image*png0. The datastream and associated file format ha e alue outside of the main design goal.

3 Terms, definitions, and abbreviated terms

3.1 Definitions
"or the purposes of this !nternational $tandard the following definitions appl#.

3.1.1 alpha a alue representing a pixel's degree of opacit#. The more opa1ue a pixel, the more it hides the background against which the image is presented. 2ero alpha represents a completel# transparent pixel, maximum alpha represents a completel# opa1ue pixel. 3.1.2 alpha compaction an implicit representation of transparent pixels. !f e er# pixel with a specific colour or greyscale alue is full# transparent and all other pixels are full# opa1ue, the alpha channel ma# be represented implicitl#. 3.1.3 alpha separation separating an alpha channel in which e er# pixel is full# opa1ue3 all alpha alues are the maximum alue. The fact that all pixels are full# opa1ue is represented implicitl#. 3.1.4 alpha table indexed table of alpha sample alues, which in an indexed-colour image defines the alpha sample alues of the reference image. The alpha table has the same number of entries as the palette. 3.1.5 ancillary chunk class of chunk that pro ides additional information. ( PNG decoder, without processing an ancillar# chunk, can still produce a meaningful image, though not necessaril# the best possible image. 3.1.6 bit depth for indexed-colour images, the number of bits per palette index. "or other images, the number of bits per sample in the image. This is the alue that appears in the IHDR chunk. 3.1.7 byte 4 bits3 also called an octet. The highest bit ( alue %54) of a b#te is numbered bit 63 the lowest bit ( alue %) is numbered bit 7. 3.1.8 byte order ordering of bytes for multi-b#te data alues within a PNG file or PNG datastream. PNG uses network byte order. 3.1.9 channel arra# of all per-pixel information of a particular kind within a reference image. There are fi e kinds of information+ red, green, blue, greyscale, and alpha. "or example the alpha channel is the arra# of alpha alues within a reference image. 3.1.10 chromaticity ( !"# pair of alues x,y that precisel# specif# a colour, except for the brightness information. 3.1.11 chunk section of a PNG datastream. 8ach chunk has a chunk t#pe. )ost chunks also include data. The format and meaning of the data within the chunk are determined b# the chunk t#pe. 8ach chunk is either a critical chunk or anancillary chunk. 3.1.12 colour type alue denoting how colour and alpha are specified in the PNG image. ,olour t#pes are sums of the following alues+ % ( palette used), 5 (truecolour used), 9 (alpha used). The permitted alues of colour t#pe are 7, 5, :, 9, and &. 3.1.13 composite ($erb#

to form an image b# merging a foreground image and a background image, using transparenc# information to determine where and to what extent the background should be isible. The foreground image is said to be 0composited against0 the background. 3.1.14 critical chunk chunk that shall be understood and processed b# the decoder in order to produce a meaningful image from a PNG datastream. 3.1.15 datastream se1uence of bytes. This term is used rather than 0file0 to describe a b#te se1uence that ma# be onl# a portion of a file. !t is also used to emphasi;e that the se1uence of b#tes might be generated and consumed 0on the fl#0, ne er appearing in a stored file at all. 3.1.16 de%late name of a particular compression algorithm. This algorithm is used, in compression mode 7, in conforming PNG datastreams. /eflate is a member of the LZ famil# of compression methods. !t is defined in <-",-%=>%?. 3.1.17 deli$ered ima&e image constructed from a decoded PNG datastream. 3.1.18 %ilter transformation applied to an arra# of scanlines with the aim of impro ing their compressibilit#. PNG uses onl# lossless (re ersible) filter algorithms. 3.1.19 %rame bu%%er the final digital storage area for the image shown b# most t#pes of computer displa#. $oftware causes an image to appear on screen b# loading the image into the frame buffer. 3.1.20 &amma exponent that describes approximations to certain non-linear transfer functions encountered in image capture and reproduction. 'ithin this !nternational $tandard, gamma is the exponent in the transfer function from display_output to image_sample
image_sample = display_outputgamma where both display_output and image_sample

are scaled to the range 7 to %. 3.1.21 &reyscale image representation in which each pixel is defined b# a single sample of colour information, representing o erall luminance (on a scale from black to white), and optionall# an alpha sample (in which case it is called gre#scale with alpha). 3.1.22 ima&e data %-dimensional arra# of scanlines within an image. 3.1.23 inde'ed(colour image representation in which each pixel of the original image is represented b# a single index into a palette. The selected palette entr# defines the actual colour of the pixel. 3.1.24 inde'in& representing an image b# a palette, an alpha table, and an arra# of indices pointing to entries in the palette and alpha table. 3.1.25 interlaced )*+ ima&e se1uence of reduced images generated from the PNG image b# pass extraction. 3.1.26 lossless compression method of data compression that permits reconstruction of the original data exactl#, bit-forbit. 3.1.27 lossy compression method of data compression that permits reconstruction of the original data approximatel#, rather than exactl#. 3.1.28 luminance

formal definition of luminance is in <,!8-%>.5?. !nformall# it is the percei ed brightness, or greyscale le el, of a colour. .uminance and chromaticity together full# define a percei ed colour. 3.1.29 ,-77 data compression algorithm described b# 2i and .empel in their %=66 paper <2.?. 3.1.30 net.ork byte order byte order in which the most significant b#te comes first, then the less significant b#tes in descending order of significance (!"# L"# for two-b#te integers, !"# @5 @% L"# for four-b#te integers). 3.1.31 palette indexed table of three 4-bit sample alues, red, green, and blue, which with an indexedcolour image defines the red, green, and blue sample alues of the reference image. !n other cases, the palette ma# be a suggested palette that iewers ma# use to present the image on indexed-colour displa# hardware. $lpha samples ma# be defined for palette entries ia the alpha table and ma# be used to reconstruct the alpha sample alues of the reference image. 3.1.32 pass e'traction organi;ing a PNG image as a se1uence of reduced images to change the order of transmission and enable progressi e displa#. 3.1.33 pi'el information stored for a single grid point in an image. ( pixel consists of (or points to) a se1uence of samples from all channels. The complete image is a rectangular arra# of pixels. 3.1.34 )*+ datastream result of encoding a PNG image. ( PNG datastream consists of a PNG signature followed b# a se1uence of chunks. 3.1.35 )*+ decoder process or de ice which reconstructs the reference image from a PNG datastream and generates a corresponding deli ered image. 3.1.36 )*+ editor process or de ice which creates a modification of an existing PNG datastream, preser ing unmodified ancillar# information where er possible, and obe#ing the chunk ordering rules, e en for unknown chunk t#pes. 3.1.37 )*+ encoder process or de ice which constructs a reference image from a source image, and generates a PNG datastream representing the reference image. 3.1.38 )*+ %ile PNG datastream stored as a file. 3.1.39 )*+ %our(byte si&ned inte&er a four-b#te signed integer limited to the range -(5 :%-%) to 5:%-%. The restriction is imposed in order to accommodate languages that ha e difficult# with the alue -5 :%. 3.1.40 )*+ %our(byte unsi&ned inte&er a four-b#te unsigned integer limited to the range 7 to 5 :%-%. The restriction is imposed in order to accommodate languages that ha e difficult# with unsigned four-b#te alues. 3.1.41 )*+ ima&e result of transformations applied b# a PNG encoder to a reference image, in preparation for encoding as a PNG datastream, and the result of decoding a PNG datastream. 3.1.42 )*+ si&nature se1uence of bytes appearing at the start of e er# PNG datastream. !t differentiates a PNG datastream from other t#pes of datastream and allows earl# detection of some transmission errors.

3.1.43 reduced ima&e pass of the interlaced PNG image extracted from the PNG image b# pass extraction. 3.1.44 re%erence ima&e rectangular arra# of rectangular pixels, each ha ing the same number of samples, either three (red, green, blue) or four (red, green, blue, alpha). 8 er# reference image can be represented exactl# b# a PNG datastream and e er# PNG datastream can be con erted into a reference image. 8ach channel has a sample depth in the range % to %&. (ll samples in the same channel ha e the same sample depth. /ifferent channels ma# ha e different sample depths. 3.1.45 /+0 mer&in& con erting an image in which the red, green, and blue samples for each pixel ha e the same alue, and the same sample depth, into an image with a single greyscale channel. 3.1.46 sample intersection of a channel and a pixel in an image. 3.1.47 sample depth number of bits used to represent a sample alue. !n an indexed-colour PNG image, samples are stored in the palette and thus the sample depth is alwa#s 4 b# definition of the palette. !n other t#pes of PNG image it is the same as the bit depth. 3.1.48 sample depth scalin& mapping of a range of sample alues onto the full range of a sample depth allowed in a PNG image. 3.1.49 scanline row of pixels within an image or interlaced PNG image. 3.1.50 source ima&e image which is presented to a PNG encoder. 3.1.51 truecolour image representation in which each pixel is defined b# samples, representing red, green, and blue intensities and optionall# an alpha sample (in which case it is referred to as truecolour with alpha). 3.1.52 .hite point chromaticity of a computer displa#As nominal white alue. 3.1.53 1lib particular format for data that ha e been compressed using deflate-st#le compression. (lso the name of a librar# containing a sample implementation of this method. The format is defined in <-",-%=>7?.

3.2 Abbreviated terms

3.2.1 / ,#clic -edundanc# ,ode. ( ,-, is a t#pe of check alue designed to detect most transmission errors. ( decoder calculates the ,-, for the recei ed data and checks b# comparing it to the ,-, calculated b# the encoder and appended to the data. ( mismatch indicates that the data or the ,-, were corrupted in transit. 3.2.2 /2 ,athode -a# Tube+ a common t#pe of computer displa# hardware. 3.2.2 ,30 .east $ignificant @#te of a multi-byte alue. 3.2.3 ,42 .ook Bp Table. !n frame buffer hardware, a .BT can be used to map indexedcolour pixels into a selected set of truecolour alues, or to perform gamma correction. !n software, a .BT can often be used as a fast wa# of implementing an# mathematical function of a single integer ariable. 3.2.4 530

)ost $ignificant @#te of a multi-byte alue.

4 Concepts
4.1 Images
This !nternational $tandard specifies the PNG datastream, and places some re1uirements on PNG encoders, which generate PNG datastreams, PNG decoders, which interpret PNG datastreams, and PNG editors, which transform one PNG datastream into another. !t does not specif# the interface between an application and either a PNG encoder, decoder, or editor. The precise form in which an image is presented to an encoder or deli ered b# a decoder is not specified. "our kinds of image are distinguished.

a. The source image is the image presented to a PNG encoder. b. The reference image, which onl# exists conceptuall#, is a rectangular arra# of rectangular pixels, all ha ing the same width and height, and all containing the same number of unsigned integer samples, either three (red, green, blue) or four (red, green, blue, alpha). The arra# of all samples of a particular kind (red, green, blue, or alpha) is called a channel. 8ach channel has a sample depth in the range % to %&, which is the number of bits used b# e er# sample in the channel. /ifferent channels ma# ha e different sample depths. The red, green, and blue samples determine the intensities of the red, green, and blue components of the pixelAs colour3 if the# are all ;ero, the pixel is black, and if the# all ha e their maximum alues (5sampledepth-%), the pixel is white. The alpha sample determines a pixelAs degree of opacit#, where ;ero means full# transparent and the maximum alue means full# opa1ue. !n a three-channel reference image all pixels are full# opa1ue. (!t is also possible for a four-channel reference image to ha e all pixels full# opa1ue3 the difference is that the latter has a specific alpha sample depth, whereas the former does not.) 8ach hori;ontal row of pixels is called a scanline. Pixels are ordered from left to right within each scanline, and scanlines are ordered from top to bottom. ( PNG encoder ma# transform the source image directl# into a PNG image, but conceptuall# it first transforms the source image into a reference image, then transforms the reference image into a PNG image. /epending on the t#pe of source image, the transformation from the source image to a reference image ma# re1uire the loss of information. That transformation is be#ond the scope of this !nternational $tandard. The reference image, howe er, can alwa#s be reco ered exactl# from a PNG datastream. c. The PNG image is obtained from the reference image b# a series of transformations+ alpha separation, indexing, -G@ merging, alpha compaction, and sample depth scaling. "i e t#pes of PNG image are defined (see &.%+ ,olour t#pes and alues). (!f the PNG encoder actuall# transforms the source image directl# into the PNG image, and the source image format is alread# similar to the PNG image format, the encoder ma# be able to a oid doing some of these transformations.) (lthough not all sample depths in the range % to %& bits are explicitl# supported in the PNG image, the number of significant bits in each channel of the reference image ma# be recorded. (ll channels in the PNG image ha e the same sample depth. ( PNG encoder generates a PNG datastream from the PNG image. ( PNG decoder takes the PNG datastream and recreates the PNG image. d. The deli%ered image is constructed from the PNG image obtained b# decoding a PNG datastream. No specific format is specified for the deli ered image. ( iewer presents an image to the user as close to the appearance of the original source image as it can achie e.
The relationships between the four kinds of image are illustrated in figure 9.%.

The relationships between samples, channels, pixels, and sample depth are illustrated in figure 9.5.

4.2 Colour spaces

The -G@ colour space in which colour samples are situated ma# be specified in one of three wa#s+ a. b# an !,, profile3

b. b# specif#ing explicitl# that the colour space is s-G@ when the samples conform to this colour
space3 c. b# specif#ing the alue of gamma and the %=:% ,!8 x,y chromaticities of the red, green, and blue primaries used in the image and the reference white point. "or high-end applications the first method pro ides the most flexibilit# and control. The second method enables one particular colour space to be indicated. The third method enables the exact chromaticities of the -G@ data to be specified, along with the gamma correction (the power function relating the desired displa# output with the image samples) to be applied (see (nnex ,+ Gamma and chromaticit#). !t is recommended that explicit gamma information also be pro ided when either the first or second method is used, for use b# PNG decoders that do not support full !,, profiles or the s-G@ colour space. $uch PNG decoders can still make sensible use of gamma information. PNG decoders are strongl# encouraged to use this information, plus information about the displa# s#stem, in order to present the image to the iewer in a wa# that reproduces as closel# as possible what the imageAs original author saw .

Gamma correction is not applied to the alpha channel, if present. (lpha samples alwa#s represent a linear fraction of full opacit#.

4.3 Reference image to PNG image transformation

4.3.1 Introduction
( number of transformations are applied to the reference image to create the PNG image to be encoded (see figure 9.:). The transformations are applied in the following se1uence, where s1uare brackets mean the transformation is optional+ [alpha separation] indexing or ( [RGB merging] [alpha compaction] ) sample depth scaling 'hen e er# pixel is either full# transparent or full# opa1ue, the alpha separation, alpha compaction, and indexing transformations can cause the reco ered reference image to ha e an alpha sample depth different from the original reference image, or to ha e no alpha channel. This has no effect on the degree of opacit# of an# pixel. The two reference images are considered e1ui alent, and the transformations are considered lossless. 8ncoders that ne ertheless wish to preser e the alpha sample depth ma# elect not to perform transformations that would alter the alpha sample depth.

4.3.2 Alpha separation

!f all alpha samples in a reference image ha e the maximum alue, then the alpha channel ma# be omitted, resulting in an e1ui alent image that can be encoded more compactl#.

4.3.3 Indexing
!f the number of distinct pixel alues is 5>& or less, and the -G@ sample depths are not greater than 4, and the alpha channel is absent or exactl# 4 bits deep or e er# pixel is either full# transparent or full# opa1ue, then an alternati e representation called indexed-colour ma# be more efficient for encoding. 8ach pixel is replaced b# an index into a palette. The palette is a list of entries each containing three 4-bit samples (red, green, blue). !f an alpha channel is present, there is also a parallel table of 4-bit alpha samples.

( suggested palette or palettes ma# be constructed e en when the PNG image is not indexed-colour in order to assist iewers that are capable of displa#ing onl# a limited number of colours. "or indexed-colour images, encoders can rearrange the palette so that the table entries with the maximum alpha alue are grouped at the end. !n this case the table can be encoded in a shortened form that does not include these entries.

4.3.4 RGB merging

!f the red, green, and blue channels ha e the same sample depth, and for each pixel the alues of the red, green, and blue samples are e1ual, then these three channels ma# be merged into a single gre#scale channel.

4.3.5 Alpha compaction

"or non-indexed images, if there exists an -G@ (or gre#scale) alue such that all pixels with that alue are full# transparent while all other pixels are full# opa1ue, then the alpha channel can be represented more compactl# b# merel# identif#ing the -G@ (or gre#scale) alue that is transparent.

4.3.6 Sample depth scaling

!n the PNG image, not all sample depths are supported (see &.%+ ,olour t#pes and alues), and all channels shall ha e the same sample depth. (ll channels of the PNG image use the smallest allowable sample depth that is not less than an# sample depth in the reference image, and the possible sample alues in the reference image are linearl# mapped into the next allowable range for the PNG image. "igure 9.> shows how samples of depth : might be mapped into samples of depth 9.

(llowing onl# a few sample depths reduces the number of cases that decoders ha e to cope with. $ample depth scaling is re ersible with no loss of data, because the reference image sample depths can be recorded in the PNG datastream. !n the absence of recorded sample depths, the reference image sample depth e1uals the PNG image sample depth. $ee %5.>+ $ample depth scaling and %:.%5+ $ample depth rescaling.

4.4 PNG image

The transformation of the reference image results in one of fi e t#pes of PNG image (see figure 9.&) +

a. Truecolour with alpha+ each pixel consists of four samples+ red, green, blue, and alpha. b. Gre#scale with alpha+ each pixel consists of two samples+ gre# and alpha. c. Truecolour+ each pixel consists of three samples+ red, green, and blue. The alpha channel ma# be represented b# a single pixel alue. )atching pixels are full# transparent, and all others are full# opa1ue. !f the alpha channel is not represented in this wa#, all pixels are full# opa1ue. d. Gre#scale+ each pixel consists of a single sample+ gre#. The alpha channel ma# be represented b# a single pixel alue as in the pre ious case. !f the alpha channel is not represented in this wa#, all pixels are full# opa1ue. e. !ndexed-colour+ each pixel consists of an index into a palette (and into an associated table of alpha alues, if present).
The format of each pixel depends on the PNG image t#pe and the bit depth. "or PNG image t#pes other than indexed-colour, the bit depth specifies the number of bits per sample, not the total number of bits per pixel. "or indexed-colour images, the bit depth specifies the number of bits in each palette index, not the sample depth of the colours in the palette or alpha table. 'ithin the pixel the samples appear in the following order, depending on the PNG image t#pe.

a. b. c. d. e.

Truecolour with alpha+ red, green, blue, alpha. Gre#scale with alpha+ gre#, alpha. Truecolour+ red, green, blue. Gre#scale+ gre#. !ndexed-colour+ palette index.

4.5 Encoding the PNG image

4.5.1 Introduction
( conceptual model of the process of encoding a PNG image is gi en in figure 9.6. The steps refer to the operations on the arra# of pixels or indices in the PNG image. The palette and alpha table are not encoded in this wa#.

a. Pass extraction+ to allow for progressi e displa#, the PNG image pixels can be rearranged to form se eral smaller images called reduced images or passes. b. $canline seriali;ation+ the image is seriali;ed a scanline at a time. Pixels are ordered left to right in a scanline and scanlines are ordered top to bottom. c. "iltering+ each scanline is transformed into a filtered scanline using one of the defined filter t#pes to prepare the scanline for image compression. d. ,ompression+ occurs on all the filtered scanlines in the image. e. ,hunking+ the compressed image is di ided into con enientl# si;ed chunks. (n error detection code is added to each chunk. f. /atastream construction+ the chunks are inserted into the datastream. 4.5.2 Pass extraction
Pass extraction (see figure 9.4) splits a PNG image into a se1uence of reduced images where the first image defines a coarse iew and subse1uent images enhance this coarse iew until the last image completes the PNG image. The set of reduced images is also called an interlaced PNG image. Two interlace methods are defined in this !nternational $tandard. The first method is a null method3 pixels are stored se1uentiall# from left to right and scanlines from top to bottom. The second method makes multiple scans o er the image to produce a se1uence of se en reduced images. The se en passes for a sample image are illustrated in figure 9.4. $ee clause 4+ !nterlacing and pass extraction.

4.5.3 Scanline serialization

8ach row of pixels, called a scanline, is represented as a se1uence of b#tes.

4.5.4 Filtering
PNG standardi;es one filter method and se eral filter t#pes that ma# be used to prepare image data for compression. !t transforms the b#te se1uence in a scanline to an e1ual length se1uence of b#tes preceded b# a filter t#pe b#te (see figure 9.= for an example). The filter t#pe b#te defines the specific filtering to be applied to a specific scanline. The encoder shall use onl# a single filter method for an interlaced PNG image, but ma# use different filter t#pes for each scanline in a reduced image. $ee clause =+ "iltering.

4.5.5 Compression
The se1uence of filtered scanlines in the pass or passes of the PNG image is compressed (see figure 9.%7) b# one of the defined compression methods. The concatenated filtered scanlines form the input to the compression stage. The output from the compression stage is a single compressed datastream. $ee clause %7+ ,ompression.

4.5.6 Chunking
,hunking pro ides a con enient breakdown of the compressed datastream into manageable chunks (see figure 9.%7). 8ach chunk has its own redundanc# check. $ee clause %%+ ,hunk specifications.

4.6 Additional information

(ncillar# information ma# be associated with an image. /ecoders ma# ignore all or some of the ancillar# information. The t#pes of ancillar# information pro ided are described in Table 9.%.

2able 4.1 6 2ypes o% ancillary in%ormation Type of information Description

@ackground colour $olid background colour to be used when presenting the image if no better option is a ailable. Gamma and chromaticit# !,, profile !mage histogram Ph#sical pixel dimensions $ignificant bits s-G@ colour space Gamma characteristic of the image with respect to the desired output intensit#, and chromaticit# characteristics of the -G@ alues used in the image. /escription of the colour space (in the form of an !nternational ,olor ,onsortium (!,,) profile) to which the samples in the image conform. 8stimates of how fre1uentl# the image uses each palette entr#. !ntended pixel si;e and aspect ratio to be used in presenting the PNG image. The number of bits that are significant in the samples. ( rendering intent (as defined b# the !nternational ,olor ,onsortium) and an indication that the image samples conform to this colour space.

$uggested palette ( reduced palette that ma# be used when the displa# de ice is not capable of displa#ing the full range of colours in the image.

Textual data Time Transparenc#

Textual information (which ma# be compressed) associated with the image. The time when the PNG image was last modified. (lpha information that allows the reference image to be reconstructed when the alpha channel is not retained in the PNG image.

4.7 PNG datastream

4.7.1 Chunks
The PNG datastream consists of a PNG signature (see >.5+ PNG signature) followed b# a se1uence of chunks (see clause %%+ ,hunk specifications). 8ach chunk has a chunk t#pe which specifies its function.

4.7.2 Chunk types

There are %4 chunk t#pes defined in this !nternational $tandard. ,hunk t#pes are four-b#te se1uences chosen so that the# correspond to readable labels when interpreted in the !$C &9&.!-D+%==% character set. The first four are termed critical chunks, which shall be understood and correctl# interpreted according to the pro isions of this !nternational $tandard. These are+

a. b. c. d.

IHDR+ image header, which is the first chunk in a PNG datastream. PLTE+ palette table associated with indexed PNG images. IDAT+ image data chunks. IEND+ image trailer, which is the last chunk in a PNG datastream.

The remaining %9 chunk t#pes are termed ancillar# chunk t#pes, which encoders ma# generate and decoders ma# interpret.

a. Transparenc# information+ tRNS (see %%.:.5+ Transparenc# information). b. ,olour space information+ cHRM, gAMA, iCCP, sBIT, sRGB (see %%.:.:+ ,olour space information). c. Textual information+ iTXt, tEXt, zTXt (see %%.:.9+ Textual information). d. )iscellaneous information+ bKGD, hIST, pHYs, sPLT (see %%.:.>+ )iscellaneous information). e. Time information+ tIME (see %%.:.&+ Time stamp information).

4.8 Error handling

8rrors in a PNG datastream fall into two general classes+

a. transmission errors or damage to a computer file s#stem, which tend to corrupt much or all of the datastream3 b. s#ntax errors, which appear as in alid alues in chunks, or as missing or misplaced chunks. $#ntax errors can be caused not onl# b# encoding mistakes, but also b# the use of registered or pri ate alues, if those alues are unknown to the decoder.
PNG decoders should detect errors as earl# as possible, reco er from errors whene er possible, and fail gracefull# otherwise. The error handling philosoph# is described in detail in %:.5+ 8rror handling.

4.9 Extension and registration

"or some facilities in PNG, there are a number of alternati es defined, and this !nternational $tandard allows other alternati es to be defined b# registration. (ccording to the rules for the designation and operation of registration authorities in the !$C*!8, /irecti es, the !$C and !8, ,ouncils ha e designated the following as the registration authorit#+ The World-Wide Web Consortium Host at ERCIM The Registration Authority for PNG INRIA- Sophia Antipolis BP 93

06902 Sophia Antipolis Cedex FRANCE Email:png-group@w3.org To ensure timel# processing the -egistration (uthorit# should be contacted b# email. The following entities ma# be registered+

a. chunk t#pe3 b. text ke#word.

The following entities are reser ed for future standardi;ation+

a. b. c. d. e.

undefined field alues less than %543 filter method3 filter t#pe3 interlace method3 compression method.

5 Datastream structure
5.1 Introduction
This clause defines the PNG signature and the basic properties of chunks. !ndi idual chunk t#pes are discussed in clause %%+ ,hunk specifications.

5.2 PNG signature

The first eight b#tes of a PNG datastream alwa#s contain the following (decimal) alues+ 137 80 78 71 13 10 26 10 This signature indicates that the remainder of the datastream contains a single PNG image, consisting of a series of chunks beginning with an IHDR chunk and ending with an IEND chunk.

5.3 Chunk layout

8ach chunk consists of three or four fields (see figure >.%). The meaning of the fields is described in Table >.%. The chunk data field ma# be empt#.

2able 5.1 6

hunk %ields

.ength ( four-b#te unsigned integer gi ing the number of b#tes in the chunkAs data field. The length counts onl# the data field, not itself, the chunk t#pe, or the ,-,. 2ero is a alid length. (lthough encoders and decoders should treat the length as unsigned, its alue shall not exceed 5:%-% b#tes. ,hunk T#pe ( se1uence of four b#tes defining the chunk t#pe. 8ach b#te of a chunk t#pe is restricted to the decimal alues &> to =7 and =6 to %55. These correspond to the uppercase and lowercase !$C &9& letters (A-Z and a-z) respecti el# for con enience in description and examination of PNG datastreams. 8ncoders and decoders shall treat the chunk t#pes as fixed binar# alues, not character strings.

"or example, it would not be correct to represent the chunk t#pe IDAT b# the e1ui alents of those letters in the B,$ 5 character set. (dditional naming con entions for chunk t#pes are discussed in >.9+ ,hunk naming con entions. ,hunk /ata ,-, The data b#tes appropriate to the chunk t#pe, if an#. This field can be of ;ero length. ( four-b#te ,-, (,#clic -edundanc# ,ode) calculated on the preceding b#tes in the chunk, including the chunk t#pe field and chunk data fields, but not including the length field. The ,-, can be used to check for corruption of the data. The ,-, is alwa#s present, e en for chunks containing no data. $ee >.>+ ,#clic -edundanc# ,ode algorithm.

The chunk data length ma# be an# number of b#tes up to the maximum3 therefore, implementors cannot assume that chunks are aligned on an# boundaries larger than b#tes.

5.4 Chunk naming conventions

,hunk t#pes are chosen to be meaningful names when the b#tes of the chunk t#pe are interpreted as !$C &9& letters. ,hunk t#pes are assigned so that a decoder can determine some properties of a chunk e en when the t#pe is not recogni;ed. These rules allow safe, flexible extension of the PNG format, b# allowing a PNG decoder to decide what to do when it encounters an unknown chunk. (The chunk t#pes standardi;ed in this !nternational $tandard are defined in clause %%+ ,hunk specifications, and the wa# to add non-standard chunks is defined in clause %9+ 8ditors and extensions.) The naming rules are normall# of interest onl# when the decoder does not recogni;e the chunkAs t#pe. "our bits of the chunk t#pe, the propert# bits, namel# bit > ( alue :5) of each b#te, are used to con e# chunk properties. This choice means that a human can read off the assigned properties according to whether the letter corresponding to each b#te of the chunk t#pe is uppercase (bit > is 7) or lowercase (bit > is %). Eowe er, decoders should test the properties of an unknown chunk t#pe b# numericall# testing the specified bits3 testing whether a character is uppercase or lowercase is inefficient, and e en incorrect if a localespecific case definition is used. The propert# bits are an inherent part of the chunk t#pe, and hence are fixed for an# chunk t#pe. Thus, CHNK and cHNk would be unrelated chunk t#pes, not the same chunk with different properties. The semantics of the propert# bits are defined in Table >.5.

2able 5.2 6 3emantics o% property bits (ncillar# bit+ 7 (uppercase) F first b#te critical, % (lowercase) F ancillar#. ,ritical chunks are necessar# for successful displa# of the contents of the datastream, for example the image header chunk (IHDR). ( decoder tr#ing to extract the image, upon encountering an unknown chunk t#pe in which the ancillar# bit is 7, shall indicate to the user that the image contains information it cannot safel# interpret. (ncillar# chunks are not strictl# necessar# in order to meaningfull# displa# the contents of the datastream, for example the time chunk (tIME). ( decoder encountering an unknown chunk t#pe in which the ancillar# bit is % can safel# ignore the chunk and proceed to displa# the image. ( public chunk is one that is defined in this !nternational $tandard or is registered in the list of PNG specialpurpose public chunk t#pes maintained b# the -egistration (uthorit# (see 9.= 8xtension and registration). (pplications can also define pri ate (unregistered) chunk t#pes for their own purposes. The names of pri ate chunks ha e a lowercase second letter, while public chunks will alwa#s be assigned

Pri ate bit+ 7 (uppercase) F second b#te public, % (lowercase) F pri ate.

names with uppercase second letters. /ecoders do not need to test the pri ate-chunk propert# bit, since it has no functional significance3 it is simpl# an administrati e con enience to ensure that public and pri ate chunk names will not conflict. $ee clause %9+ 8ditors and extensions and %5.%7.5+ Bse of pri ate chunks. -eser ed bit+ third b#te 7 (uppercase) in this ersion of PNG. !f the reser ed bit is %, the datastream does not conform to this ersion of PNG. The significance of the case of the third letter of the chunk name is reser ed for possible future extension. !n this !nternational $tandard, all chunk names shall ha e uppercase third letters.

$afe-to7 (uppercase) F cop# bit+ unsafe to cop#, fourth b#te % (lowercase) F safe to cop#.

This propert# bit is not of interest to pure decoders, but it is needed b# PNG editors. This bit defines the proper handling of unrecogni;ed chunks in a datastream that is being modified. -ules for PNG editors are discussed further in %9.5+ @eha iour of PNG editors.

8G()P.8 The h#pothetical chunk t#pe 0cHNk0 has the propert# bits+ cHNk <-- 32 bit chunk type represented in text form |||| |||+Safe-to-copy bit is 1 (lower case letter; bit 5 is 1) ||+-- Reserved bit is 0 (upper case letter; bit 5 is 0) |+--- Private bit is 0 (upper case letter; bit 5 is 0) +---- Ancillary bit is 1 (lower case letter; bit 5 is 1) Therefore, this name represents an ancillar#, public, safe-to-cop# chunk.

5.5 Cyclic Redundancy Code algorithm

,-, fields are calculated using standardi;ed ,-, methods with pre and post conditioning, as defined b# !$C ::7= <!$C-::7=? and !TB-T D.95 <!TB-T-D95?. The ,-, pol#nomial emplo#ed is x:5 H x5& H x5: H x55 H x%& H x%5 H x%% H x%7 H x4 H x6 H x> H x9 H x5 H x H % !n PNG, the :5-bit ,-, is initiali;ed to all %As, and then the data from each b#te is processed from the least significant bit (%) to the most significant bit (%54). (fter all the data b#tes are processed, the ,-, is in erted (its ones complement is taken). This alue is transmitted (stored in the datastream) )$@ first. "or the purpose of separating into b#tes and ordering, the least significant bit of the :5-bit ,-, is defined to be the coefficient of the x31 term. Practical calculation of the ,-, often emplo#s a precalculated table to accelerate the computation. $ee (nnex /+ $ample ,#clic -edundanc# ,ode implementation.

5.6 Chunk ordering

The constraints on the positioning of the indi idual chunks are listed in Table >.: and illustrated diagrammaticall# in figure >.5 and figure >.:. These lattice diagrams represent the constraints on positioning imposed b# this !nternational $tandard. The lines in the diagrams define partial ordering relationships. ,hunks higher up shall appear before chunks lower down. ,hunks which are hori;ontall# aligned and appear between two other chunk t#pes (higher and lower than the hori;ontall# aligned chunks) ma# appear in an# order between the two higher and lower chunk t#pes to which the# are connected. The superscript associated with the chunk t#pe is defined in Table >.9. !t indicates whether the chunk is mandator#, optional, or ma# appear more than once. ( ertical bar between two chunk t#pes indicates alternati es.

2able 5.3 6

hunk orderin& rules

Critical chunks (shall appear in this order, except PLTE is optional) Chunk name Multiple allowed Ordering constraints

IHDR PLTE IDAT IEND

No No Ies No

$hall be first @efore first IDAT )ultiple IDAT chunks shall be consecuti e $hall be last Ancillary chunks (need not appear in this order)

Chunk name cHRM gAMA iCCP sBIT sRGB bKGD hIST tRNS pHYs sPLT tIME iTXt tEXt zTXt No No No No No No No No No

Multiple allowed

Ordering constraints @efore PLTE and IDAT @efore PLTE and IDAT @efore PLTE and IDAT. !f the iCCP chunk is present, the sRGB chunk should not be present. @efore PLTE and IDAT @efore PLTE and IDAT. !f the sRGB chunk is present, the iCCP chunk should not be present. (fter PLTE3 before IDAT (fter PLTE3 before IDAT (fter PLTE3 before IDAT @efore IDAT @efore IDAT None None None None Meaning Cne or more Cnl# one 2ero or one 2ero or more (lternati e

Ies No Ies Ies Ies Symbol

2able 5.4 6 5eanin& o% symbols used in lattice dia&rams H % J K L

6 Reference image to PNG image transformation

6.1 Colour types and values
(s explained in 9.9+ PNG image there are fi e t#pes of PNG image. ,orresponding to each t#pe is a colour t#pe, which is the sum of the following alues+ % (palette used), 5 (truecolour used) and 9 (alpha used). Gre#scale and truecolour images ma# ha e an explicit alpha channel. The PNG image t#pes and corresponding colour t#pes are listed in Table &.%.

2able 6.1 6 )*+ ima&e types and colour types PNG image type Gre#scale Truecolour !ndexed-colour Gre#scale with alpha Truecolour with alpha 7 5 : 9 & Colour type

The allowed bit depths and sample depths for each PNG image t#pe are listed in %%.5.5+ IHDR !mage header. Gre#scale samples represent luminance if the transfer cur e is indicated (b# gAMA, sRGB, or iCCP) or de ice-dependent gre#scale if not. -G@ samples represent calibrated colour information if the colour space is indicated (b# gAMAand cHRM, or sRGB, or iCCP) or uncalibrated de ice-dependent colour if not. $ample alues are not necessaril# proportional to light intensit#3 the gAMA chunk specifies the relationship between sample alues and displa# output intensit#. Diewers are strongl# encouraged to compensate properl#. $ee 9.5+ ,olour spaces, %:.%:+ /ecoder gamma handling and (nnex ,+ Gamma and chromaticit#.

6.2 Alpha representation

!n a PNG datastream transparenc# ma# be represented in one of four wa#s, depending on the PNG image t#pe (see 9.:.5+ (lpha separation and 9.:.>+ (lpha compaction).

a. Truecolour with alpha, gre#scale with alpha+ an alpha channel is part of the image arra#. b. Truecolour, gre#scale+ ( tRNS chunk contains a single pixel alue distinguishing the full# transparent pixels from the full# opa1ue pixels. c. !ndexed-colour+ ( tRNS chunk contains the alpha table that associates an alpha sample with each palette entr#. d. Truecolour, gre#scale, indexed-colour+ there is no tRNS chunk present and all pixels are full# opa1ue.
(n alpha channel included in the image arra# has 4-bit or %&-bit samples, the same si;e as the other samples. The alpha sample for each pixel is stored immediatel# following the gre#scale or -G@ samples of the pixel. (n alpha alue of ;ero represents full transparenc#, and a alue of 5 sampledepth - % represents full opacit#. !ntermediate alues indicate partiall# transparent pixels that can be composited against a background image to #ield the deli ered image. The colour alues in a pixel are not premultiplied b# the alpha alue assigned to the pixel. This rule is sometimes called 0unassociated0 or 0non-premultiplied0 alpha. ((nother common techni1ue is to store sample alues premultiplied b# the alpha alue3 in effect, such an image is alread# composited against a black background. PNG does not use premultiplied alpha. !n conse1uence an image editor can take a PNG image and easil# change its transparenc#.) $ee %5.9+ (lpha channel creation and %:.%&+ (lpha channel processing.

7 Encoding the PNG image as a PNG datastream

7.1 Integers and byte order
(ll integers that re1uire more than one b#te shall be in network b#te order (as illustrated in figure 6.%)+ the most significant b#te comes first, then the less significant b#tes in descending order of significance ()$@

.$@ for two-b#te integers, )$@ @5 @% .$@ for four-b#te integers). The highest bit ( alue %54) of a b#te is numbered bit 63 the lowest bit ( alue %) is numbered bit 7. Dalues are unsigned unless otherwise noted. Dalues explicitl# noted as signed are represented in twoAs complement notation. PNG four-b#te unsigned integers are limited to the range 7 to 5 :%-% to accommodate languages that ha e difficult# with unsigned four-b#te alues. $imilarl# PNG four-b#te signed integers are limited to the range (5:%-%) to 5:%-% to accommodate languages that ha e difficult# with the alue -5:%.

7.2 Scanlines
( PNG image (or pass, see clause 4+ !nterlacing and pass extraction) is a rectangular pixel arra#, with pixels appearing left-to-right within each scanline, and scanlines appearing top-to-bottom. The si;e of each pixel is determined b# the number of bits per pixel. Pixels within a scanline are alwa#s packed into a se1uence of b#tes with no wasted bits between pixels. $canlines alwa#s begin on b#te boundaries. Permitted bit depths and colour t#pes are restricted so that in all cases the packing is simple and efficient. !n PNG images of colour t#pe 7 (gre#scale) each pixel is a single sample, which ma# ha e precision less than a b#te (%, 5, or 9 bits). These samples are packed into b#tes with the leftmost sample in the high-order bits of a b#te followed b# the other samples for the scanline. !n PNG images of colour t#pe : (indexed-colour) each pixel is a single palette index. These indices are packed into b#tes in the same wa# as the samples for colour t#pe 7. 'hen there are multiple pixels per b#te, some low-order bits of the last b#te of a scanline ma# go unused. The contents of these unused bits are not specified. PNG images that are not indexed-colour images ma# ha e sample alues with a bit depth of %&. $uch sample alues are in network b#te order ()$@ first, .$@ second). PNG permits multi-sample pixels onl# with 4 and %&-bit samples, so multiple samples of a single pixel are ne er packed into one b#te.

7.3 Filtering
PNG allows the scanline data to be filtered before it is compressed. "iltering can impro e the compressibilit# of the data. The filter step itself results in a se1uence of b#tes of the same si;e as the incoming se1uence, but in a different representation, preceded b# a filter t#pe b#te. "iltering does not reduce the si;e of the actual scanline data. (ll PNG filters are strictl# lossless. /ifferent filter t#pes can be used for different scanlines, and the filter algorithm is specified for each scanline b# a filter t#pe b#te. The filter t#pe b#te is not considered part of the image data, but it is included in the datastream sent to the compression step. (n intelligent encoder can switch filters from one scanline to the next. The method for choosing which filter to emplo# is left to the encoder. $ee clause =+ "iltering.

8 Interlacing and pass extraction

8.1 Introduction

Pass extraction (see figure 9.4) splits a PNG image into a se1uence of reduced images (the interlaced PNG image) where the first image defines a coarse iew and subse1uent images enhance this coarse iew until the last image completes the PNG image. This allows progressi e displa# of the interlaced PNG image b# the decoder and allows images to 0fade in0 when the# are being displa#ed on-the-fl#. Cn a erage, interlacing slightl# expands the datastream si;e, but it can gi e the user a meaningful displa# much more rapidl#.

8.2 Interlace methods

Two interlace methods are defined in this !nternational $tandard, methods 7 and %. Cther alues of interlace method are reser ed for future standardi;ation (see 9.=+ 8xtension and registration). 'ith interlace method 7, the null method, pixels are extracted se1uentiall# from left to right, and scanlines se1uentiall# from top to bottom. The interlaced PNG image is a single reduced image. !nterlace method %, known as (dam6, defines se en distinct passes o er the image. 8ach pass transmits a subset of the pixels in the reference image. The pass in which each pixel is transmitted (numbered from % to 6) is defined b# replicating the following 4-b#-4 pattern o er the entire image, starting at the upper left corner+

"igure 9.4 shows the se en passes of interlace method %. 'ithin each pass, the selected pixels are transmitted left to right within a scanline, and selected scanlines se1uentiall# from top to bottom. "or example, pass 5 contains pixels 9, %5, 57, etc. of scanlines 7, 4, %&, etc. (where scanline 7, pixel 7 is the upper left corner). The last pass contains all of scanlines %, :, >, etc. The transmission order is defined so that all the scanlines transmitted in a pass will ha e the same number of pixels3 this is necessar# for proper application of some of the filters. The interlaced PNG image consists of a se1uence of se en reduced images. "or example, if the PNG image is %& b# %& pixels, then the third pass will be a reduced image of two scanlines, each containing four pixels (see figure 9.4). $canlines that do not completel# fill an integral number of b#tes are padded as defined in 6.5+ $canlines.

9 Filtering
9.1 Filter methods and filter types
"iltering transforms the PNG image with the goal of impro ing compression. PNG allows for a number of filter methods. (ll the reduced images in an interlaced image shall use a single filter method. Cnl# filter method 7 is defined b# this !nternational $tandard. Cther filter methods are reser ed for future standardi;ation (see 9.= 8xtension and registration). "ilter method 7 pro ides a set of fi e filter t#pes, and indi idual scanlines in each reduced image ma# use different filter t#pes. PNG imposes no additional restriction on which filter t#pes can be applied to an interlaced PNG image. Eowe er, the filter t#pes are not e1uall# effecti e on all t#pes of data. $ee %5.4+ "ilter selection. "iltering transforms the b#te se1uence in a scanline to an e1ual length se1uence of b#tes preceded b# the filter t#pe. "ilter t#pe b#tes are associated onl# with non-empt# scanlines. No filter t#pe b#tes are present in an empt# pass. $ee %:.4+ !nterlacing and progressi e displa#.

9.2 Filter types for filter method 0

"ilters are applied to b#tes, not to pixels, regardless of the bit depth or colour t#pe of the image. The filters operate on the b#te se1uence formed b# a scanline that has been represented as described in

6.5+ $canlines. !f the image includes an alpha channel, the alpha data is filtered in the same wa# as the image data. "ilters ma# use the original alues of the following b#tes to generate the new b#te alue+ x a

the b#te being filtered3 the b#te corresponding to x in the pixel immediatel# before the pixel containing x (or the b#te immediatel# before x, when the bit depth is less than 4)3 the b#te corresponding to x in the pre ious scanline3 the b#te corresponding to b in the pixel immediatel# before the pixel containing b (or the b#te immediatel# before b, when the bit depth is less than 4).

b c

"igure =.% shows the relati e positions of the b#tes x, a, b, and c. PNG filter method 7 defines fi e basic filter t#pes as listed in Table =.%. Orig(y) denotes the orginal (unfiltered) alue of b#te y. Filt(y) denotes the alue after a filter has been applied. Recon(y) denotes the alue after the corresponding reconstruction function has been applied. The filter function for the Paeth t#pe PaethPredictor is defined below. "ilter method 7 specifies exactl# this set of fi e filter t#pes and this shall not be extended. This ensures that decoders need not decompress the data to determine whether it contains unsupported filter t#pes+ it is sufficient to check the filter method in IHDR.

2able 9.1 6 7ilter types Type Name 7 % 5 : 9 None $ub Bp Filter Function
Filt(x) = Orig(x) Filt(x) = Orig(x) - Orig(a) Filt(x) = Orig(x) - Orig(b) floor((Orig(a) + Orig(b)) / 2)

Reconstruction Function
Recon(x) = Filt(x) Recon(x) = Filt(x) + Recon(a) Recon(x) = Filt(x) + Recon(b) Recon(x) = Filt(x) + floor((Recon(a) + Recon(b)) / 2)

( erage Filt(x) = Orig(x) Paeth

Filt(x) = Orig(x) Recon(x) = Filt(x) + PaethPredictor(Orig(a), Orig(b), PaethPredictor(Recon(a), Recon(b), Orig(c)) Recon(c))

"or all filters, the b#tes 0to the left of0 the first pixel in a scanline shall be treated as being ;ero. "or filters that refer to the prior scanline, the entire prior scanline and b#tes 0to the left of0 the first pixel in the prior scanline shall be treated as being ;eroes for the first scanline of a reduced image. To re erse the effect of a filter re1uires the decoded alues of the prior pixel on the same scanline, the pixel immediatel# abo e the current pixel on the prior scanline, and the pixel Must to the left of the pixel abo e. Bnsigned arithmetic modulo 5>& is used, so that both the inputs and outputs fit into b#tes. "ilters are applied to each b#te regardless of bit depth. The se1uence of Filt alues is transmitted as the filtered scanline.

9.3 Filter type 3: Average

The sum Orig(a) + Orig(b) shall be performed without o erflow (using at least nine-bit arithmetic). floor() indicates that the result of the di ision is rounded to the next lower integer if fractional3 in other words, it is an integer di ision or right shift operation.

9.4 Filter type 4: Paeth

The Paeth filter function computes a simple linear function of the three neighbouring pixels (left, abo e, upper left), then chooses as predictor the neighbouring pixel closest to the computed alue. The algorithm used in this !nternational $tandard is an adaptation of the techni1ue due to (lan '. Paeth <P(8TE?. The PaethPredictor function is defined in the code below. The logic of the function and the locations of the b#tes a, b, c, and x are shown in figure =.%. Pr is the predictor for b#te x.

The calculations within the PaethPredictor function shall be performed exactl#, without o erflow. The order in which the comparisons are performed is critical and shall not be altered. The function tries to establish in which of the three directions ( ertical, hori;ontal, or diagonal) the gradient of the image is smallest. 8xactl# the same PaethPredictor function is used b# both encoder and decoder.

10 Compression
10.1 Compression method 0
Cnl# PNG compression method 7 is defined b# this !nternational $tandard. Cther alues of compression method are reser ed for future standardi;ation (see 9.=+ 8xtension and registration). PNG compression method 7 is deflate*inflate compression with a sliding window (which is an upper bound on the distances appearing in the deflate stream) of at most :56&4 b#tes. /eflate compression is an .266 deri ati e <2.?. /eflate-compressed datastreams within PNG are stored in the 0;lib0 format, which has the structure+

;lib compression method*flags code % b#te (dditional flags*check bits ,ompressed data blocks ,heck alue % b#te n b#tes 9 b#tes

"urther details on this format are gi en in the ;lib specification <-",-%=>7?. "or PNG compression method 7, the ;lib compression method*flags code shall specif# method code 4 (deflate compression) and an .266 window si;e of not more than :56&4 b#tes. The ;lib compression method number is not the same as the PNG compression method number in the IHDR chunk (see %%.5.5 IHDR !mage header). The additional flags shall not specif# a preset dictionar#. !f the data to be compressed contain %&:49 b#tes or fewer, the PNG encoder ma# set the window si;e b# rounding up to a power of 5 (5>& minimum). This decreases the memor# re1uired for both encoding and decoding, without ad ersel# affecting the compression ratio. The compressed data within the ;lib datastream are stored as a series of blocks, each of which can represent raw (uncompressed) data, .266-compressed data encoded with fixed Euffman codes, or .266compressed data encoded with custom Euffman codes. ( marker bit in the final block identifies it as the last

block, allowing the decoder to recogni;e the end of the compressed datastream. "urther details on the compression algorithm and the encoding are gi en in the deflate specification <-",-%=>%?. The check alue stored at the end of the ;lib datastream is calculated on the uncompressed data represented b# the datastream. The algorithm used to calculate this is not the same as the ,-, calculation used for PNG chunk ,-, field alues. The ;lib check alue is useful mainl# as a cross-check that the deflate and inflate algorithms are implemented correctl#. Derif#ing the indi idual PNG chunk ,-,s pro ides confidence that the PNG datastream has been transmitted undamaged.

10.2 Compression of the sequence of filtered scanlines

The se1uence of filtered scanlines is compressed and the resulting data stream is split into IDAT chunks. The concatenation of the contents of all the IDAT chunks makes up a ;lib datastream. This datastream decompresses to filtered image data. !t is important to emphasi;e that the boundaries between IDAT chunks are arbitrar# and can fall an#where in the ;lib datastream. There is not necessaril# an# correlation between IDAT chunk boundaries and deflate block boundaries or an# other feature of the ;lib data. "or example, it is entirel# possible for the terminating ;lib check alue to be split across IDAT chunks. $imilarl#, there is no re1uired correlation between the structure of the image data (i.e., scanline boundaries) and deflate block boundaries or IDAT chunk boundaries. The complete filtered PNG image is represented b# a single ;lib datastream that is stored in a number of IDAT chunks.

10.3 Other uses of compression

PNG also uses compression method 7 in iTXt, iCCP, and zTXt chunks. Bnlike the image data, such datastreams are not split across chunks3 each such chunk contains an independent ;lib datastream (see %7.%+ ,ompression method 7).

11 Chunk specifications
11.1 Introduction
The PNG datastream consists of a PNG signature (see >.5+ PNG signature) followed b# a se1uence of chunks. 8ach chunk has a chunk t#pe which specifies its function. This clause defines the PNG chunk t#pes standardi;ed in this !nternational $tandard. The PNG datastream structure is defined in clause >+ /atastream structure. This also defines the order in which chunks ma# appear. "or details specific to encoders see %5.%%+ ,hunking. "or details specific to decoders see %:.>+ ,hunking.

11.2 Critical chunks

11.2.1 General
,ritical chunks are those chunks that are absolutel# re1uired in order to successfull# decode a PNG image from a PNG datastream. 8xtension chunks ma# be defined as critical chunks (see clause %9+ 8ditors and extensions), though this practice is strongl# discouraged. ( alid PNG datastream shall begin with a PNG signature, immediatel# followed b# an IHDR chunk, then one or more IDAT chunks, and shall end with an IEND chunk. Cnl# one IHDR chunk and one IEND chunk are allowed in a PNG datastream.

11.2.2 IHDR Image header

The four-b#te chunk t#pe field contains the decimal alues 73 72 68 82 The IHDR chunk shall be the first chunk in the PNG datastream. !t contains+

'idth Eeight @it depth ,olour t#pe

9 b#tes 9 b#tes % b#te % b#te

,ompression method % b#te "ilter method !nterlace method % b#te % b#te

'idth and height gi e the image dimensions in pixels. The# are PNG four-b#te unsigned integers. 2ero is an in alid alue. @it depth is a single-b#te integer gi ing the number of bits per sample or per palette index (not per pixel). Dalid alues are %, 5, 9, 4, and %&, although not all alues are allowed for all colour t#pes. $ee &.%+ ,olour t#pes and alues. ,olour t#pe is a single-b#te integer that defines the PNG image t#pe. Dalid alues are 7, 5, :, 9, and &. @it depth restrictions for each colour t#pe are imposed to simplif# implementations and to prohibit combinations that do not compress well. The allowed combinations are defined in Table %%.%.

2able 11.1 6 8llo.ed combinations o% colour type and bit depth PNG image type Gre#scale Truecolour !ndexed-colour Gre#scale with alpha Truecolour with alpha Colour type 7 5 : 9 & Allowed bit depths %, 5, 9, 4, %& 4, %& %, 5, 9, 4 4, %& 4, %& Interpretation 8ach pixel is a gre#scale sample 8ach pixel is an -,G,@ triple 8ach pixel is a palette index3 a PLTE chunk shall appear. 8ach pixel is a gre#scale sample followed b# an alpha sample. 8ach pixel is an -,G,@ triple followed b# an alpha sample.

The sample depth is the same as the bit depth except in the case of indexed-colour PNG images (colour t#pe :), in which the sample depth is alwa#s 4 bits (see 9.9+ PNG image). ,ompression method is a single-b#te integer that indicates the method used to compress the image data. Cnl# compression method 7 (deflate*inflate compression with a sliding window of at most :56&4 b#tes) is defined in this !nternational $tandard. (ll conforming PNG images shall be compressed with this scheme. "ilter method is a single-b#te integer that indicates the preprocessing method applied to the image data before compression. Cnl# filter method 7 (adapti e filtering with fi e basic filter t#pes) is defined in this !nternational $tandard. $ee clause =+ "iltering for details. !nterlace method is a single-b#te integer that indicates the transmission order of the image data. Two alues are defined in this !nternational $tandard+ 7 (no interlace) or % ((dam6 interlace). $ee clause 4+ !nterlacing and pass extraction for details.

11.2.3 PLTE Palette

The four-b#te chunk t#pe field contains the decimal alues 80 76 84 69 The PLTE chunk contains from % to 5>& palette entries, each a three-b#te series of the form+

-ed @lue

% b#te % b#te

Green % b#te
The number of entries is determined from the chunk length. ( chunk length not di isible b# : is an error. This chunk shall appear for colour t#pe :, and ma# appear for colour t#pes 5 and &3 it shall not appear for colour t#pes 7 and 9. There shall not be more than one PLTE chunk. "or colour t#pe : (indexed-colour), the PLTE chunk is re1uired. The first entr# in PLTE is referenced b# pixel alue 7, the second b# pixel alue %, etc. The number of palette entries shall not exceed the range that can be represented in the image bit depth (for example, 5 9 F %& for a bit depth of 9). !t is permissible to ha e

fewer entries than the bit depth would allow. !n that case, an# out-of-range pixel alue found in the image data is an error. "or colour t#pes 5 and & (truecolour and truecolour with alpha), the PLTE chunk is optional. !f present, it pro ides a suggested set of colours (from % to 5>&) to which the truecolour image can be 1uanti;ed if it cannot be displa#ed directl#. !t is, howe er, recommended that the sPLT chunk be used for this purpose, rather than the PLTE chunk. !f neither PLTE nor sPLT chunks are present and the image cannot be displa#ed directl#, 1uanti;ation has to be done b# the iewing s#stem. Eowe er, it is often preferable for the selection of colours to be done once b# the PNG encoder. ($ee %5.&+ $uggested palettes.) Note that the palette uses 4 bits (% b#te) per sample regardless of the image bit depth. !n particular, the palette is 4 bits deep e en when it is a suggested 1uanti;ation of a %&-bit truecolour image. There is no re1uirement that the palette entries all be used b# the image, nor that the# all be different.

11.2.4 IDAT Image data

The four-b#te chunk t#pe field contains the decimal alues 73 68 65 84 The IDAT chunk contains the actual image data which is the output stream of the compression algorithm. $ee clause =+ "iltering and clause %7+ ,ompression for details. There ma# be multiple IDAT chunks3 if so, the# shall appear consecuti el# with no other inter ening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the IDAT chunks.

11.2.5 IEND Image trailer

The four-b#te chunk t#pe field contains the decimal alues 73 69 78 68 The IEND chunk marks the end of the PNG datastream. The chunkAs data field is empt#.

11.3 Ancillary chunks

11.3.1 General
The ancillar# chunks defined in this !nternational $tandard are listed in the order in 9.6.5+ ,hunk t#pes. This is not the order in which the# appear in a PNG datastream. (ncillar# chunks ma# be ignored b# a decoder. "or each ancillar# chunk, the actions described are under the assumption that the decoder is not ignoring the chunk.

11.3.2 Transparency information

11.3.2.1 tRNS Transparency The four-b#te chunk t#pe field contains the decimal alues 116 82 78 83 The tRNS chunk specifies either alpha alues that are associated with palette entries (for indexed-colour images) or a single transparent colour (for gre#scale and truecolour images). The tRNS chunk contains+

Colour type 0 Gre# sample alue Colour type 2 -ed sample alue @lue sample alue Green sample alue Colour type 3 (lpha for palette index 7 % b#te (lpha for palette index % % b#te ...etc... % b#te 5 b#tes 5 b#tes 5 b#tes 5 b#tes

"or colour t#pe : (indexed-colour), the tRNS chunk contains a series of one-b#te alpha alues, corresponding to entries in the PLTE chunk. 8ach entr# indicates that pixels of the corresponding palette index shall be treated as ha ing the specified alpha alue. (lpha alues ha e the same interpretation as in an 4-bit full alpha channel+ 7 is full# transparent, 5>> is full# opa1ue, regardless of image bit depth. The tRNS chunk shall not contain more alpha alues than there are palette entries, but a tRNS chunk ma# contain fewer alues than there are palette entries. !n this case, the alpha alue for all remaining palette entries is assumed to be 5>>. !n the common case in which onl# palette index 7 need be made transparent, onl# a one-b#te tRNS chunk is needed, and when all palette indices are opa1ue, the tRNS chunk ma# be omitted. "or colour t#pes 7 or 5, two b#tes per sample are used regardless of the image bit depth (see 6.%+ !ntegers and b#te order). Pixels of the specified gre# sample alue or -G@ sample alues are treated as transparent (e1ui alent to alpha alue 7)3 all other pixels are to be treated as full# opa1ue (alpha alue 5 bitdepth-%). !f the image bit depth is less than %&, the least significant bits are used and the others are 7. ( tRNS chunk shall not appear for colour t#pes 9 and &, since a full alpha channel is alread# present in those cases. NCT8 "or %&-bit gre#scale or truecolour data, onl# pixels matching the entire %&-bit alues in tRNS chunks are transparent. /ecoders
ha e to postpone an# sample depth rescaling until after the pixels ha e been tested for transparenc#.

11.3.3 Colour space information

11.3.3.1 cHRM Primary chromaticities and white point The four-b#te chunk t#pe field contains the decimal alues 99 72 82 77 The cHRM chunk ma# be used to specif# the %=:% ,!8 x,y chromaticities of the red, green, and blue displa# primaries used in the image, and the referenced white point. $ee (nnex ,+ Gamma and chromaticit# for more information. The iCCP and sRGB chunks pro ide more sophisticated support for colour management and control. The cHRM chunk contains+

'hite point x 9 b#tes 'hite point # 9 b#tes -ed x -ed # Green x Green # @lue x @lue # 9 b#tes 9 b#tes 9 b#tes 9 b#tes 9 b#tes 9 b#tes

8ach alue is encoded as a four-b#te PNG unsigned integer, representing the x or y alue times %77777. 8G()P.8 ( alue of 7.:%56 would be stored as the integer :%567. The cHRM chunk is allowed in all PNG datastreams, although it is of little alue for gre#scale images. (n sRGB chunk or iCCP chunk, when present and recogni;ed, o errides the cHRM chunk. 11.3.3.2 gAMA Image gamma The four-b#te chunk t#pe field contains the decimal alues 103 65 77 65 The gAMA chunk specifies the relationship between the image samples and the desired displa# output intensit#. Gamma is defined in :.%.57+ gamma. !n fact specif#ing the desired displa# output intensit# is insufficient. !t is also necessar# to specif# the iewing conditions under which the output is desired. "or gAMA these are the reference iewing conditions of the s-G@ specification <!8, &%=&&-5-%?, which are based on !$C :&&9 <!$C-:&&9?. (dMustment for different iewing conditions is normall# handled b# a ,olour )anagement $#stem. !f the adMustment is not performed, the error is usuall# small. (pplications desiring high colour fidelit# ma# wish to use an sRGB chunk or iCCP chunk. The gAMA chunk contains+

!mage gamma 9 b#tes

The alue is encoded as a four-b#te PNG unsigned integer, representing gamma times %77777. 8G()P.8 ( gamma of %*5.5 would be stored as the integer 9>9>>. $ee %5.5+ 8ncoder gamma handling and %:.%:+ /ecoder gamma handling for more information. (n sRGB chunk or iCCP chunk, when present and recogni;ed, o errides the gAMA chunk. 11.3.3.3 iCCP Embedded ICC profile The four-b#te chunk t#pe field contains the decimal alues 105 67 67 80 The iCCP chunk contains+

Profile name Null separator ,ompressed profile

%-6= b#tes (character string) % b#te (null character) n b#tes

,ompression method % b#te

The profile name ma# be an# con enient name for referring to the profile. !t is case-sensiti e. Profile names shall contain onl# printable .atin-% characters and spaces (onl# character codes :5-%5& and %&%-5>> decimal are allowed). .eading, trailing, and consecuti e spaces are not permitted. The onl# compression method defined in this !nternational $tandard is method 7 (;lib datastream with deflate compression, see %7.:+ Cther uses of compression). The compression method entr# is followed b# a compressed profile that makes up the remainder of the chunk. /ecompression of this datastream #ields the embedded !,, profile. !f the iCCP chunk is present, the image samples conform to the colour space represented b# the embedded !,, profile as defined b# the !nternational ,olor ,onsortium <!,,?. The colour space of the !,, profile shall be an -G@ colour space for colour images (PNG colour t#pes 5, :, and &), or a gre#scale colour space for gre#scale images (PNG colour t#pes 7 and 9). ( PNG encoder that writes the iCCP chunk is encouraged to also write gAMA and cHRM chunks that approximate the !,, profile, to pro ide compatibilit# with applications that do not use the iCCP chunk. 'hen the iCCP chunk is present, PNG decoders that recogni;e it and are capable of colour management <!,,? shall ignore the gAMA and cHRM chunks and use the iCCP chunk instead and interpret it according to <!,,-%? and <!,,-%(?. PNG decoders that are used in an en ironment that is incapable of full-fledged colour management should use the gAMAand cHRM chunks if present. ( PNG datastream should contain at most one embedded profile, whether specified explicitl# with an iCCP chunk or implicitl# with an sRGB chunk. 11.3.3.4 sBIT Significant bits The four-b#te chunk t#pe field contains the decimal alues 115 66 73 84 To simplif# decoders, PNG specifies that onl# certain sample depths ma# be used, and further specifies that sample alues should be scaled to the full range of possible alues at the sample depth. The sBIT chunk defines the original number of significant bits (which can be less than or e1ual to the sample depth). This allows PNG decoders to reco er the original data losslessl# e en if the data had a sample depth not directl# supported b# PNG. The sBIT chunk contains+

Colour type 0 significant gre#scale bits % b#te Colour types 2 and 3 significant red bits significant green bits significant blue bits Colour type 4 significant gre#scale bits % b#te % b#te % b#te % b#te

significant alpha bits Colour type 6 significant red bits significant green bits significant blue bits significant alpha bits

% b#te % b#te % b#te % b#te % b#te

8ach depth specified in sBIT shall be greater than ;ero and less than or e1ual to the sample depth (which is 4 for indexed-colour images, and the bit depth gi en in IHDR for other colour t#pes). Note that sBIT does not pro ide a sample depth for the alpha channel that is implied b# a tRNS chunk3 in that case, all of the sample bits of the alpha channel are to be treated as significant. !f the sBIT chunk is not present, then all of the sample bits of all channels are to be treated as significant. 11.3.3.5 sRGB Standard RGB colour space The four-b#te chunk t#pe field contains the decimal alues 115 82 71 66 !f the sRGB chunk is present, the image samples conform to the s-G@ colour space <!8, &%=&&-5-%? and should be displa#ed using the specified rendering intent defined b# the !nternational ,olor ,onsortium <!,,%? and <!,,-%(?. The sRGB chunk contains+

-endering intent % b#te

The following alues are defined for rendering intent+

7 Perceptual % -elati e colorimetric 5 $aturation : (bsolute colorimetric

for images preferring good adaptation to the output de ice gamut at the expense of colorimetric accurac#, such as photographs. for images re1uiring colour appearance matching (relati e to the output de ice white point), such as logos. for images preferring preser ation of saturation at the expense of hue and lightness, such as charts and graphs. for images re1uiring preser ation of absolute colorimetr#, such as pre iews of images destined for a different output de ice (proofs).

!t is recommended that a PNG encoder that writes the sRGB chunk also write a gAMA chunk (and optionall# a cHRM chunk) for compatibilit# with decoders that do not use the sRGB chunk. Cnl# the following alues shall be used.

gAMA Gamma cHRM 'hite point x :%567 'hite point # :5=77 -ed x -ed # Green x Green # @lue x &9777 ::777 :7777 &7777 %>777 9>9>>

@lue #

&777

'hen the sRGB chunk is present, it is recommended that decoders that recogni;e it and are capable of colour management <!,,? ignore the gAMA and cHRM chunks and use the sRGB chunk instead. /ecoders that recogni;e the sRGBchunk but are not capable of colour management <!,,? are recommended to ignore the gAMA and cHRM chunks, and use the alues gi en abo e as if the# had appeared in gAMA and cHRM chunks. !t is recommended that the sRGB and iCCP chunks do not both appear in a PNG datastream.

11.3.4 Textual information

11.3.4.1 Introduction PNG pro ides the tEXt, iTXt, and zTXt chunks for storing text strings associated with the image, such as an image description or cop#right notice. Ne#words are used to indicate what each text string represents. (n# number of such text chunks ma# appear, and more than one with the same ke#word is permitted. 11.3.4.2 Keywords and text strings The following ke#words are predefined and should be used where appropriate.

Title (uthor /escription ,op#right $oftware /isclaimer 'arning $ource ,omment

$hort (one line) title or caption for image Name of imageAs creator /escription of image (possibl# long) ,op#right notice $oftware used to create the image .egal disclaimer 'arning of nature of content /e ice used to create the image )iscellaneous comment

,reation Time Time of original image creation

Cther ke#words ma# be defined for other purposes. Ne#words of general interest can be registered with the PNG -egistration (uthorit# (see 9.= 8xtension and registration). !t is also permitted to use pri ate unregistered ke#words. (Pri ate ke#words should be reasonabl# self-explanator#, in order to minimi;e the chance that the same ke#word is used for incompatible purposes b# different people.) Ne#words shall contain onl# printable .atin-% <!$C-44>=-%? characters and spaces3 that is, onl# character codes :5-%5& and %&%-5>> decimal are allowed. To reduce the chances for human misreading of a ke#word, leading spaces, trailing spaces, and consecuti e spaces are not permitted in ke#words, nor is the nonbreaking space (code %&7) since it is isuall# indistinguishable from an ordinar# space. Ne#words shall be spelled exactl# as registered, so that decoders can use simple literal comparisons when looking for particular ke#words. !n particular, ke#words are considered case-sensiti e. Ne#words are restricted to % to 6= b#tes in length. "or the ,reation Time ke#word, the date format defined in section >.5.%9 of -", %%5: is suggested, but not re1uired <-",-%%5:?. !n the tEXt and zTXt chunks, the text string associated with a ke#word is restricted to the .atin-% character set plus the linefeed character. Text strings in zTXt are compressed into ;lib datastreams using deflate compression (see %7.:+ Cther uses of compression). The iTXt chunk can be used to con e# characters outside the .atin-% set. !t uses the BT"-4 encoding of B,$ <!$C*!8, %7&9&-%? . There is an option to compress text strings in the iTXt chunk. 11.3.4.3 tEXt Textual data The four-b#te chunk t#pe field contains the decimal alues 116 69 88 116 8ach tEXt chunk contains a ke#word and a text string, in the format+

Ne#word Text string

%-6= b#tes (character string) 7 or more b#tes (character string)

Null separator % b#te (null character)

The ke#word and text string are separated b# a ;ero b#te (null character). Neither the ke#word nor the text string ma# contain a null character. The text string is not null-terminated (the length of the chunk defines the ending). The text string ma# be of an# length from ;ero b#tes up to the maximum permissible chunk si;e less the length of the ke#word and null character separator. The ke#word indicates the t#pe of information represented b# the text string as described in %%.:.9.5+ Ne#words and text strings. Text is interpreted according to the .atin-% character set <!$C-44>=-%?. The text string ma# contain an# .atin% character. Newlines in the text string should be represented b# a single linefeed character (decimal %7). ,haracters other than those defined in .atin-% plus the linefeed character ha e no defined meaning in tEXt chunks. Text containing characters outside the repertoire of !$C*!8, 44>=-% should be encoded using the iTXt chunk. 11.3.4.4 zTXt Compressed textual data The four-b#te chunk t#pe field contains the decimal alues 122 84 88 116 The zTXt and tEXt chunks are semanticall# e1ui alent, but the zTXt chunk is recommended for storing large blocks of text. ( zTXt chunk contains+

Ne#word Null separator ,ompression method

%-6= b#tes (character string) % b#te (null character) % b#te

,ompressed text datastream n b#tes

The ke#word and null character are the same as in the tEXt chunk (see %%.:.9.:+ tEXt Textual data). The ke#word is not compressed. The compression method entr# defines the compression method used. The onl# alue defined in this !nternational $tandard is 7 (deflate*inflate compression). Cther alues are reser ed for future standardi;ation (see 9.= 8xtension and registration). The compression method entr# is followed b# the compressed text datastream that makes up the remainder of the chunk. "or compression method 7, this datastream is a ;lib datastream with deflate compression (see %7.:+ Cther uses of compression). /ecompression of this datastream #ields .atin-% text that is identical to the text that would be stored in an e1ui alent tEXt chunk. 11.3.4.5 iTXt International textual data The four-b#te chunk t#pe field contains the decimal alues 105 84 88 116 (n iTXt chunk contains+

Ne#word Null separator ,ompression flag .anguage tag Null separator Translated ke#word Null separator Text

%-6= b#tes (character string) % b#te (null character) % b#te 7 or more b#tes (character string) % b#te (null character) 7 or more b#tes % b#te (null character) 7 or more b#tes

,ompression method % b#te

The ke#word is described in %%.:.9.5+ Ne#words and text strings. The compression flag is 7 for uncompressed text, % for compressed text. Cnl# the text field ma# be compressed. The compression method entr# defines the compression method used. The onl# compression method defined in this !nternational $tandard is 7 (;lib datastream with deflate compression, see %7.:+ Cther uses of compression). "or uncompressed text, encoders shall set the compression method to 7, and decoders shall ignore it. The language tag defined in <-",-:7&&? indicates the human language used b# the translated ke#word and the text. Bnlike the ke#word, the language tag is case-insensiti e. !t is an !$C &9&.!-D+%==% <!$C &9&? string consisting of h#phen-separated words of %-4 alphanumeric characters each (for example cn, en-uk, no-bok, x-klingon, x-Nl!nGoN). !f the first word is two or three letters long, it is an !$C language code <!$C-&:=?. !f the language tag is empt#, the language is unspecified. The translated ke#word and text both use the BT"-4 encoding of B,$ <!$C*!8, %7&9&-%?, and neither shall contain a ;ero b#te (null character). The text, unlike other textual data in this chunk, is not null-terminated3 its length is deri ed from the chunk length. .ine breaks should not appear in the translated ke#word. !n the text, a newline should be represented b# a single linefeed character (decimal %7). The remaining control characters (%-=, %%-:%, %56-%>=) are discouraged in both the translated ke#word and text. !n BT"-4 there is a difference between the characters %54-%>= (which are discouraged) and the b#tes %54-%>= (which are often necessar#). The translated ke#word, if not empt#, should contain a translation of the ke#word into the language indicated b# the language tag, and applications displa#ing the ke#word should displa# the translated ke#word in addition.

11.3.5 Miscellaneous information

11.3.5.1 bKGD Background colour The four-b#te chunk t#pe field contains the decimal alues 98 75 71 68 The bKGD chunk specifies a default background colour to present the image against. !f there is an# other preferred background, either user-specified or part of a larger page (as in a browser), the bKGD chunk should be ignored. ThebKGD chunk contains+

Colour types 0 and 4 Gre#scale -ed Green @lue 5 b#tes 5 b#tes 5 b#tes 5 b#tes

Colour types 2 and 6

Colour type 3 Palette index % b#te

"or colour t#pe : (indexed-colour), the alue is the palette index of the colour to be used as background. "or colour t#pes 7 and 9 (gre#scale, gre#scale with alpha), the alue is the gre# le el to be used as background in the range 7 to (5 bitdepth)-%. "or colour t#pes 5 and & (truecolour, truecolour with alpha), the alues are the colour to be used as background, gi en as -G@ samples in the range 7 to (5 bitdepth)-%. !n each case, for consistenc#, two b#tes per sample are used regardless of the image bit depth. !f the image bit depth is less than %&, the least significant bits are used and the others are 7. 11.3.5.2 hIST Image histogram The four-b#te chunk t#pe field contains the decimal alues 104 73 83 84 The hIST chunk contains a series of two-b#te (%&-bit) unsigned integers+

"re1uenc# 5 b#tes (unsigned integer) ...etc...

The hIST chunk gi es the approximate usage fre1uenc# of each colour in the palette. ( histogram chunk can appear onl# when a PLTE chunk appears. !f a iewer is unable to pro ide all the colours listed in the palette, the histogram ma# help it decide how to choose a subset of the colours for displa#. There shall be exactl# one entr# for each entr# in the PLTE chunk. 8ach entr# is proportional to the fraction of pixels in the image that ha e that palette index3 the exact scale factor is chosen b# the encoder. Eistogram entries are approximate, with the exception that a ;ero entr# specifies that the corresponding palette entr# is not used at all in the image. ( histogram entr# shall be non;ero if there are an# pixels of that colour.
NCT8 'hen the palette is a suggested 1uanti;ation of a truecolour image, the histogram is necessaril# approximate, since a decoder ma# map pixels to palette entries differentl# than the encoder did. !n this situation, ;ero entries should not normall# appear, because an# entr# might be used.

11.3.5.3 pHYs Physical pixel dimensions The four-b#te chunk t#pe field contains the decimal alues 112 72 89 115 The pHYs chunk specifies the intended pixel si;e or aspect ratio for displa# of the image. !t contains+

Pixels per unit, G axis 9 b#tes (PNG unsigned integer) Pixels per unit, I axis 9 b#tes (PNG unsigned integer) Bnit specifier 7 unit is unknown % unit is the metre
'hen the unit specifier is 7, the pHYs chunk defines pixel aspect ratio onl#3 the actual si;e of the pixels remains unspecified. !f the pHYs chunk is not present, pixels are assumed to be s1uare, and the ph#sical si;e of each pixel is unspecified. 11.3.5.4 sPLT Suggested palette The four-b#te chunk t#pe field contains the decimal alues 115 80 76 84 The sPLT chunk contains+

% b#te

The following alues are defined for the unit specifier+

Palette name %-6= b#tes (character string) Null separator % b#te (null character) $ample depth % b#te -ed Green @lue (lpha "re1uenc# ...etc...
8ach palette entr# is six b#tes or ten b#tes containing fi e unsigned integers (red, blue, green, alpha, and fre1uenc#). There ma# be an# number of entries. ( PNG decoder determines the number of entries from the length of the chunk remaining after the sample depth b#te. This shall be di isible b# & if the sPLT sample depth is 4, or b# %7 if the sPLTsample depth is %&. 8ntries shall appear in decreasing order of fre1uenc#. There is no re1uirement that the entries all be used b# the image, nor that the# all be different. The palette name can be an# con enient name for referring to the palette (for example 05>& colour including )acintosh default0, 05>& colour including 'indows-:.% default0, 0Cptimal >%50). The palette name ma# aid the choice of the appropriate suggested palette when more than one appears in a PNG datastream.

% or 5 b#tes % or 5 b#tes % or 5 b#tes % or 5 b#tes 5 b#tes

The palette name is case-sensiti e, and subMect to the same restrictions as the ke#word parameter for the tEXt chunk. Palette names shall contain onl# printable .atin-% characters and spaces (onl# character codes :5-%5& and %&%-5>> decimal are allowed). .eading, trailing, and consecuti e spaces are not permitted. The sPLT sample depth shall be 4 or %&. The red, green, blue, and alpha samples are either one or two b#tes each, depending on the sPLT sample depth, regardless of the image bit depth. The colour samples are not premultiplied b# alpha, nor are the# precomposited against an# background. (n alpha alue of 7 means full# transparent. (n alpha alue of 5>> (when the sPLT sample depth is 4) or &>>:> (when the sPLT sample depth is %&) means full# opa1ue. The sPLT chunk ma# appear for an# PNG colour t#pe. 8ntries in sPLT use the same gamma and chromaticit# alues as the PNG image, but ma# fall outside the range of alues used in the colour space of the PNG image3 for example, in a gre#scale PNG image, each sPLTentr# would t#picall# ha e e1ual red, green, and blue alues, but this is not re1uired. $imilarl#, sPLT entries can ha e non-opa1ue alpha alues e en when the PNG image does not use transparenc#. 8ach fre1uenc# alue is proportional to the fraction of the pixels in the image for which that palette entr# is the closest match in -G@( space, before the image has been composited against an# background. The exact scale factor is chosen b# the PNG encoder3 it is recommended that the resulting range of indi idual alues reasonabl# fills the range 7 to &>>:>. ( PNG encoder ma# artificiall# inflate the fre1uencies for colours considered to be 0important0, for example the colours used in a logo or the facial features of a portrait. 2ero is a alid fre1uenc# meaning that the colour is 0least important0 or that it is rarel#, if e er, used. 'hen all the fre1uencies are ;ero, the# are meaningless, that is to sa#, nothing ma# be inferred about the actual fre1uencies with which the colours appear in the PNG image. )ultiple sPLT chunks are permitted, but each shall ha e a different palette name.

11.3.6 Time stamp information

11.3.6.1 tIME Image last-modification time The four-b#te chunk t#pe field contains the decimal alues 116 73 77 69 The tIME chunk gi es the time of the last image modification (not the time of initial image creation). !t contains+

Iear /a# Eour

5 b#tes (complete3 for example, %==>, not =>) % b#te (%-:%) % b#te (7-5:)

)onth % b#te (%-%5)

)inute % b#te (7->=) $econd % b#te (7-&7) (to allow for leap seconds)
Bni ersal Time (BT,) should be specified rather than local time. The tIME chunk is intended for use as an automaticall#-applied time stamp that is updated whene er the image data are changed.

0iblio&raphy
9 :,:4/(78;< Po#nton, ,., 0,olour "(O0.
http://www.poynton.com/ColorFAQ.html

9 :,:4/(242:/!8,< PNG Group, 0,olour tutorial0.

http://www.libpng.org/pub/png/spec/1.2/PNG-ColorAppendix.html

9+8558(242:/!8,< PNG Group, 0Gamma tutorial0.

http://www.libpng.org/pub/png/spec/1.2/PNG-GammaAppendix.html

9+8558(78;< Po#nton, ,., 0Gamma "(O0.

http://www.poynton.com/Poynton-color.html

9=8,,< Eall, -o#, &llumination and 'olor in 'omputer Generated &magery . $pringer-Derlag, New Iork, %=4=. !$@N 7-:46-=&669->. 9! < The !nternational ,olor ,onsortium.
http://www.color.org/

9!3:(3664< !$C :&&9+5777, (iewing conditions ) Graphic technology and photography . 9!24(/(02709< !nternational Telecommunications Bnion, #asic Parameter (alues for the *+,( "tandard for the "tudio and for &nternational Programme -xchange , !TB-- -ecommendation @T.67= (formerl# ,,!- -ec. 67=), %==7. 9!24(2(>42< !nternational Telecommunications Bnion, -rror-correcting Procedures for +'-s .sing $synchronous-to-"ynchronous 'on%ersion, !TB-T -ecommendation D.95, %==9, -e . %. 9?833:*< Nasson, P., and '. Plouffe, 0(n (nal#sis of $elected ,omputer !nterchange ,olor $paces0, $'! ,ransactions on Graphics, ol. %%, no. 9 , pp. :6:-97>, %==5. 9,!,,"@< .ille#, ,., ". .in, '.T. Eewitt, and T...P. Eoward, 'olour in 'omputer Graphics. ,D,P, $heffield, %==:. !$@N %-4>44=-755->. 9/:",:73< -oelofs, G., PNG/ ,he +efiniti%e Guide, CA-eill# Q (ssociates !nc, $ebastopol, ,(, %===. !$@N %->&>=5->95-9. $ee also http://www.libpng.org/pub/png/pngbook.html 9)8"2=< Paeth, (.'., 0!mage "ile ,ompression )ade 8as#0, in Graphics Gems &&, Pames (r o, editor. (cademic Press, $an /iego, %==%. !$@N 7-%5-7&9947-7. 9)*+(1.0< ':, -ecommendation, 0PNG (Portable Network Graphics) $pecification, Dersion %.70, %==&. ( ailable in se eral formats from http://www.w3.org/TR/REC-png-961001 and from
http://www.libpng.org/pub/png/spec/1.0/

9)*+(1.1< PNG /e elopment Group, 0PNG (Portable Network Graphics) $pecification, Dersion %.%0, %===. ( ailable from
http://www.libpng.org/pub/png/spec/1.1/

9)*+(1.2< PNG /e elopment Group, 0PNG (Portable Network Graphics) $pecification, Dersion %.50, %===. ( ailable from
http://www.libpng.org/pub/png/spec/1.2/

9)*+(/"+!32"/< PNG /e elopment Group, 0-egister of PNG Public ,hunks and Ne#words0. ( ailable in se eral formats from+
http://www.libpng.org/pub/png/spec/register/

9):323 /!)2< (dobe $#stems !ncorporated, Post"cript Language 0eference !anual, 5nd edition. (ddison-'esle#, -eading, %==7. !$@N 7-57%-%4%56-9. 9):@*2:*<

Po#nton, ,harles (., $ ,echnical &ntroduction to +igital (ideo. Pohn 'ile# and $ons, !nc., New Iork, %==&. !$@N 7-96%-%55>:-G. 935)2"(1705< $ociet# of )otion Picture and Tele ision 8ngineers, ,ele%ision ) 'omposite $nalog (ideo "ignal ) N,"' for "tudio $pplications, $)PT8-%67), %==9. 932:*"< $tone, ).,., '.@. ,owan, and P.,. @eatt#, 0,olor gamut mapping and the printing of digital images0, $'! ,ransactions on Graphics, ol. 6, no. :, pp. 59=-5=5, %=44. 92!77(6.0< T!""T) -e ision &.7, (ldus ,orporation, Pune %==5. 92/8>!3< Tra is, /a id, -ffecti%e 'olor +isplays ) ,heory and Practice. (cademic Press, .ondon, %==%. !$@N 7-%5-&=6&=7-5. 9-,< P. 2i and (. .empel, 0( Bni ersal (lgorithm for $e1uential /ata ,ompression0, &--,ransactions on &nformation ,heory, ol. !T-5:, no. :, pp. ::6 - :9:, %=66.
(dditional documentation and portable , code for deflate, inflate, and an optimi;ed implementation of the ,-, algorithm are a ailable from the ;lib web site, http://www.zlib.org/.