For images of color type 6 (truecolor with alpha channel), it is
recommended that a bKGD chunk appear and that the palette and
histogram be computed with reference to the image as it would
appear after compositing against the specified background color.
This definition is necessary to ensure that useful palette entries
are generated for pixels having fractional alpha values. The
resulting palette will probably only be useful to viewers that
present the image against the same background color. It is
recommended that PNG editors delete or recompute the palette if
they alter or remove the bKGD chunk in an image of color type 6.
If PLTE appears without bKGD in an image of color type 6, the
circumstances under which the palette was computed are
unspecified.
9.6. Filter selection
For images of color type 3 (indexed color), filter type 0 (None)
is usually the most effective. Note that color images with 256 or
fewer colors should almost always be stored in indexed color
format; truecolor format is likely to be much larger.
Filter type 0 is also recommended for images of bit depths less
than 8. For low-bit-depth grayscale images, it may be a net win
to expand the image to 8-bit representation and apply filtering,
but this is rare.
For truecolor and grayscale images, any of the five filters may
prove the most effective. If an encoder uses a fixed filter, the
Paeth filter is most likely to be the best.
For best compression of truecolor and grayscale images, we
recommend an adaptive filtering approach in which a filter is
chosen for each scanline. The following simple heuristic has
performed well in early tests: compute the output scanline using
all five filters, and select the filter that gives the smallest
sum of absolute values of outputs. (Consider the output bytes as
signed differences for this test.) This method usually
outperforms any single fixed filter choice. However, it is likely
that much better heuristics will be found as more experience is
gained with PNG.
Filtering according to these recommendations is effective on
interlaced as well as noninterlaced images.
9.7. Text chunk processing
A nonempty keyword must be provided for each text chunk. The
generic keyword "Comment" can be used if no better description of
the text is available. If a user-supplied keyword is used, be
sure to check that it meets the restrictions on keywords.
PNG text strings are expected to use the Latin-1 character set.
Encoders should avoid storing characters that are not defined in
Latin-1, and should provide character code remapping if the local
system's character set is not Latin-1.
Encoders should discourage the creation of single lines of text
longer than 79 characters, in order to facilitate easy reading.
It is recommended that text items less than 1K (1024 bytes) in
size should be output using uncompressed tEXt chunks. In
particular, it is recommended that the basic title and author
keywords should always be output using uncompressed tEXt chunks.
Lengthy disclaimers, on the other hand, are ideal candidates for
zTXt.
Placing large tEXt and zTXt chunks after the image data (after
IDAT) can speed up image display in some situations, since the
decoder won't have to read over the text to get to the image data.
But it is recommended that small text chunks, such as the image
title, appear before IDAT.
9.8. Use of private chunks
Applications can use PNG private chunks to carry information that
need not be understood by other applications. Such chunks must be
given names with lowercase second letters, to ensure that they can
never conflict with any future public chunk definition. Note,
however, that there is no guarantee that some other application
will not use the same private chunk name. If you use a private
chunk type, it is prudent to store additional identifying
information at the beginning of the chunk data.
Use an ancillary chunk type (lowercase first letter), not a
critical chunk type, for all private chunks that store information
that is not absolutely essential to view the image. Creation of
private critical chunks is discouraged because they render PNG
files unportable. Such chunks should not be used in publicly
available software or files. If private critical chunks are
essential for your application, it is recommended that one appear
near the start of the file, so that a standard decoder need not
read very far before discovering that it cannot handle the file.
If you want others outside your organization to understand a chunk
type that you invent, contact the maintainers of the PNG
specification to submit a proposed chunk name and definition for
addition to the list of special-purpose public chunks (see
Additional chunk types, Section 4.4). Note that a proposed public
chunk name (with uppercase second letter) must not be used in
publicly available software or files until registration has been
approved.
If an ancillary chunk contains textual information that might be
of interest to a human user, you should not create a special chunk
type for it. Instead use a tEXt chunk and define a suitable
keyword. That way, the information will be available to users not
using your software.
Keywords in tEXt chunks should be reasonably self-explanatory,
since the idea is to let other users figure out what the chunk
contains. If of general usefulness, new keywords can be
registered with the maintainers of the PNG specification. But it
is permissible to use keywords without registering them first.
9.9. Private type and method codes
This specification defines the meaning of only some of the
possible values of some fields. For example, only compression
method 0 and filter types 0 through 4 are defined. Numbers
greater than 127 must be used when inventing experimental or
private definitions of values for any of these fields. Numbers
below 128 are reserved for possible future public extensions of
this specification. Note that use of private type codes may
render a file unreadable by standard decoders. Such codes are
strongly discouraged except for experimental purposes, and should
not appear in publicly available software or files.
10. Recommendations for Decoders
This chapter gives some recommendations for decoder behavior. The
only absolute requirement on a PNG decoder is that it successfully
read any file conforming to the format specified in the preceding
chapters. However, best results will usually be achieved by
following these recommendations.
10.1. Error checking
To ensure early detection of common file-transfer problems,
decoders should verify that all eight bytes of the PNG file
signature are correct. (See Rationale: PNG file signature,
Section 12.11.) A decoder can have additional confidence in the
file's integrity if the next eight bytes are an IHDR chunk header
with the correct chunk length.
Unknown chunk types must be handled as described in Chunk naming
conventions (Section 3.3). An unknown chunk type is not to be
treated as an error unless it is a critical chunk.
It is strongly recommended that decoders should verify the CRC on
each chunk.
In some situations it is desirable to check chunk headers (length
and type code) before reading the chunk data and CRC. The chunk
type can be checked for plausibility by seeing whether all four
bytes are ASCII letters (codes 65-90 and 97-122); note that this
need only be done for unrecognized type codes. If the total file
size is known (from file system information, HTTP protocol, etc),
the chunk length can be checked for plausibility as well.
If CRCs are not checked, dropped/added data bytes or an erroneous
chunk length can cause the decoder to get out of step and
misinterpret subsequent data as a chunk header. Verifying that
the chunk type contains letters is an inexpensive way of providing
early error detection in this situation.
For known-length chunks such as IHDR, decoders should treat an
unexpected chunk length as an error. Future extensions to this
specification will not add new fields to existing chunks; instead,
new chunk types will be added to carry new information.
Unexpected values in fields of known chunks (for example, an
unexpected compression method in the IHDR chunk) must be checked
for and treated as errors. However, it is recommended that
unexpected field values be treated as fatal errors only in
critical chunks. An unexpected value in an ancillary chunk can be
handled by ignoring the whole chunk as though it were an unknown
chunk type. (This recommendation assumes that the chunk's CRC has
been verified. In decoders that do not check CRCs, it is safer to
treat any unexpected value as indicating a corrupted file.)
10.2. Pixel dimensions
Non-square pixels can be represented (see the pHYs chunk), but
viewers are not required to account for them; a viewer can present
any PNG file as though its pixels are square.
Conversely, viewers running on display hardware with non-square
pixels are strongly encouraged to rescale images for proper
display.
10.3. Truecolor image handling
To achieve PNG's goal of universal interchangeability, decoders
are required to accept all types of PNG image: indexed-color,
truecolor, and grayscale. Viewers running on indexed-color
display hardware need to be able to reduce truecolor images to
indexed format for viewing. This process is usually called "color
quantization".
A simple, fast way of doing this is to reduce the image to a fixed
palette. Palettes with uniform color spacing ("color cubes") are
usually used to minimize the per-pixel computation. For
photograph-like images, dithering is recommended to avoid ugly
contours in what should be smooth gradients; however, dithering
introduces graininess that can be objectionable.
The quality of rendering can be improved substantially by using a
palette chosen specifically for the image, since a color cube
usually has numerous entries that are unused in any particular
image. This approach requires more work, first in choosing the
palette, and second in mapping individual pixels to the closest
available color. PNG allows the encoder to supply a suggested
palette in a PLTE chunk, but not all encoders will do so, and the
suggested palette may be unsuitable in any case (it may have too
many or too few colors). High-quality viewers will therefore need
to have a palette selection routine at hand. A large lookup table
is usually the most feasible way of mapping individual pixels to
palette entries with adequate speed.
Numerous implementations of color quantization are available. The
PNG reference implementation, libpng, includes code for the
purpose.
10.4. Sample depth rescaling
Decoders may wish to scale PNG data to a lesser sample depth (data
precision) for display. For example, 16-bit data will need to be
reduced to 8-bit depth for use on most present-day display
hardware. Reduction of 8-bit data to 5-bit depth is also common.
The most accurate scaling is achieved by the linear equation
output = ROUND(input * MAXOUTSAMPLE / MAXINSAMPLE)
where
MAXINSAMPLE = (2^sampledepth)-1
MAXOUTSAMPLE = (2^desired_sampledepth)-1
A slightly less accurate conversion is achieved by simply shifting
right by sampledepth-desired_sampledepth places. For example, to
reduce 16-bit samples to 8-bit, one need only discard the low-
order byte. In many situations the shift method is sufficiently
accurate for display purposes, and it is certainly much faster.
(But if gamma correction is being done, sample rescaling can be
merged into the gamma correction lookup table, as is illustrated
in Decoder gamma handling, Section 10.5.)
When an sBIT chunk is present, the original pre-PNG data can be
recovered by shifting right to the sample depth specified by sBIT.
Note that linear scaling will not necessarily reproduce the
original data, because the encoder is not required to have used
linear scaling to scale the data up. However, the encoder is
required to have used a method that preserves the high-order bits,
so shifting always works. This is the only case in which shifting
might be said to be more accurate than linear scaling.
When comparing pixel values to tRNS chunk values to detect
transparent pixels, it is necessary to do the comparison exactly.
Therefore, transparent pixel detection must be done before
reducing sample precision.
10.5. Decoder gamma handling
See Gamma Tutorial (Chapter 13) if you aren't already familiar
with gamma issues.
To produce correct tone reproduction, a good image display program
should take into account the gammas of the image file and the
display device, as well as the viewing_gamma appropriate to the
lighting conditions near the display. This can be done by
calculating
gbright = insample / MAXINSAMPLE
bright = gbright ^ (1.0 / file_gamma)
vbright = bright ^ viewing_gamma
gcvideo = vbright ^ (1.0 / display_gamma)
fbval = ROUND(gcvideo * MAXFBVAL)
where MAXINSAMPLE is the maximum sample value in the file (255 for
8-bit, 65535 for 16-bit, etc), MAXFBVAL is the maximum value of a
frame buffer sample (255 for 8-bit, 31 for 5-bit, etc), insample
is the value of the sample in the PNG file, and fbval is the value
to write into the frame buffer. The first line converts from
integer samples into a normalized 0 to 1 floating point value, the
second undoes the gamma encoding of the image file to produce a
linear intensity value, the third adjusts for the viewing
conditions, the fourth corrects for the display system's gamma
value, and the fifth converts to an integer frame buffer sample.
In practice, the second through fourth lines can be merged into
gcvideo = gbright^(viewing_gamma / (file_gamma*display_gamma))
so as to perform only one power calculation. For color images, the
entire calculation is performed separately for R, G, and B values.
It is not necessary to perform transcendental math for every
pixel. Instead, compute a lookup table that gives the correct
output value for every possible sample value. This requires only
256 calculations per image (for 8-bit accuracy), not one or three
calculations per pixel. For an indexed-color image, a one-time
correction of the palette is sufficient, unless the image uses
transparency and is being displayed against a nonuniform
background.
In some cases even the cost of computing a gamma lookup table may
be a concern. In these cases, viewers are encouraged to have
precomputed gamma correction tables for file_gamma values of 1.0
and 0.5 with some reasonable choice of viewing_gamma and
display_gamma, and to use the table closest to the gamma indicated
in the file. This will produce acceptable results for the majority
of real files.
When the incoming image has unknown gamma (no gAMA chunk), choose
a likely default file_gamma value, but allow the user to select a
new one if the result proves too dark or too light.
In practice, it is often difficult to determine what value of
display_gamma should be used. In systems with no built-in gamma
correction, the display_gamma is determined entirely by the CRT.
Assuming a CRT_gamma of 2.5 is recommended, unless you have
detailed calibration measurements of this particular CRT
available.
However, many modern frame buffers have lookup tables that are
used to perform gamma correction, and on these systems the
display_gamma value should be the gamma of the lookup table and
CRT combined. You may not be able to find out what the lookup
table contains from within an image viewer application, so you may
have to ask the user what the system's gamma value is.
Unfortunately, different manufacturers use different ways of
specifying what should go into the lookup table, so interpretation
of the system gamma value is system-dependent. Gamma Tutorial
(Chapter 13) gives some examples.
The response of real displays is actually more complex than can be
described by a single number (display_gamma). If actual
measurements of the monitor's light output as a function of
voltage input are available, the fourth and fifth lines of the
computation above can be replaced by a lookup in these
measurements, to find the actual frame buffer value that most
nearly gives the desired brightness.
The value of viewing_gamma depends on lighting conditions; see
Gamma Tutorial (Chapter 13) for more detail. Ideally, a viewer
would allow the user to specify viewing_gamma, either directly
numerically, or via selecting from "bright surround", "dim
surround", and "dark surround" conditions. Viewers that don't
want to do this should just assume a value for viewing_gamma of
1.0, since most computer displays live in brightly-lit rooms.
When viewing images that are digitized from video, or that are
destined to become video frames, the user might want to set the
viewing_gamma to about 1.25 regardless of the actual level of room
lighting. This value of viewing_gamma is "built into" NTSC video
practice, and displaying an image with that viewing_gamma allows
the user to see what a TV set would show under the current room
lighting conditions. (This is not the same thing as trying to
obtain the most accurate rendition of the content of the scene,
which would require adjusting viewing_gamma to correspond to the
room lighting level.) This is another reason viewers might want
to allow users to adjust viewing_gamma directly.
10.6. Decoder color handling
See Color Tutorial (Chapter 14) if you aren't already familiar
with color issues.
In many cases, decoders will treat image data in PNG files as
device-dependent RGB data and display it without modification
(except for appropriate gamma correction). This provides the
fastest display of PNG images. But unless the viewer uses exactly
the same display hardware as the original image author used, the
colors will not be exactly the same as the original author saw,
particularly for darker or near-neutral colors. The cHRM chunk
provides information that allows closer color matching than that
provided by gamma correction alone.
Decoders can use the cHRM data to transform the image data from
RGB to XYZ and thence into a perceptually linear color space such
as CIE LAB. They can then partition the colors to generate an
optimal palette, because the geometric distance between two colors
in CIE LAB is strongly related to how different those colors
appear (unlike, for example, RGB or XYZ spaces). The resulting
palette of colors, once transformed back into RGB color space,
could be used for display or written into a PLTE chunk.
Decoders that are part of image processing applications might also
transform image data into CIE LAB space for analysis.
In applications where color fidelity is critical, such as product
design, scientific visualization, medicine, architecture, or
advertising, decoders can transform the image data from source_RGB
to the display_RGB space of the monitor used to view the image.
This involves calculating the matrix to go from source_RGB to XYZ
and the matrix to go from XYZ to display_RGB, then combining them
to produce the overall transformation. The decoder is responsible
for implementing gamut mapping.
Decoders running on platforms that have a Color Management System
(CMS) can pass the image data, gAMA and cHRM values to the CMS for
display or further processing.
Decoders that provide color printing facilities can use the
facilities in Level 2 PostScript to specify image data in
calibrated RGB space or in a device-independent color space such
as XYZ. This will provide better color fidelity than a simple RGB
to CMYK conversion. The PostScript Language Reference manual
gives examples of this process [POSTSCRIPT]. Such decoders are
responsible for implementing gamut mapping between source_RGB
(specified in the cHRM chunk) and the target printer. The
PostScript interpreter is then responsible for producing the
required colors.
Decoders can use the cHRM data to calculate an accurate grayscale
representation of a color image. Conversion from RGB to gray is
simply a case of calculating the Y (luminance) component of XYZ,
which is a weighted sum of the R G and B values. The weights
depend on the monitor type, i.e., the values in the cHRM chunk.
Decoders may wish to do this for PNG files with no cHRM chunk. In
that case, a reasonable default would be the CCIR 709 primaries
[ITU-BT709]. Do not use the original NTSC primaries, unless you
really do have an image color-balanced for such a monitor. Few
monitors ever used the NTSC primaries, so such images are probably
nonexistent these days.
10.7. Background color
The background color given by bKGD will typically be used to fill
unused screen space around the image, as well as any transparent
pixels within the image. (Thus, bKGD is valid and useful even
when the image does not use transparency.) If no bKGD chunk is
present, the viewer will need to make its own decision about a
suitable background color.
Viewers that have a specific background against which to present
the image (such as Web browsers) should ignore the bKGD chunk, in
effect overriding bKGD with their preferred background color or
background image.
The background color given by bKGD is not to be considered
transparent, even if it happens to match the color given by tRNS
(or, in the case of an indexed-color image, refers to a palette
index that is marked as transparent by tRNS). Otherwise one would
have to imagine something "behind the background" to composite
against. The background color is either used as background or
ignored; it is not an intermediate layer between the PNG image and
some other background.
Indeed, it will be common that bKGD and tRNS specify the same
color, since then a decoder that does not implement transparency
processing will give the intended display, at least when no
partially-transparent pixels are present.
10.8. Alpha channel processing
In the most general case, the alpha channel can be used to
composite a foreground image against a background image; the PNG
file defines the foreground image and the transparency mask, but
not the background image. Decoders are not required to support
this most general case. It is expected that most will be able to
support compositing against a single background color, however.
The equation for computing a composited sample value is
output = alpha * foreground + (1-alpha) * background
where alpha and the input and output sample values are expressed
as fractions in the range 0 to 1. This computation should be
performed with linear (non-gamma-encoded) sample values. For
color images, the computation is done separately for R, G, and B
samples.
The following code illustrates the general case of compositing a
foreground image over a background image. It assumes that you
have the original pixel data available for the background image,
and that output is to a frame buffer for display. Other variants
are possible; see the comments below the code. The code allows
the sample depths and gamma values of foreground image, background
image, and frame buffer/CRT all to be different. Don't assume
they are the same without checking.
This code is standard C, with line numbers added for reference in
the comments below.
01 int foreground[4]; /* image pixel: R, G, B, A */
02 int background[3]; /* background pixel: R, G, B */
03 int fbpix[3]; /* frame buffer pixel */
04 int fg_maxsample; /* foreground max sample */
05 int bg_maxsample; /* background max sample */
06 int fb_maxsample; /* frame buffer max sample */
07 int ialpha;
08 float alpha, compalpha;
09 float gamfg, linfg, gambg, linbg, comppix, gcvideo;
/* Get max sample values in data and frame buffer */
10 fg_maxsample = (1 << fg_sample_depth) - 1;
11 bg_maxsample = (1 << bg_sample_depth) - 1;
12 fb_maxsample = (1 << frame_buffer_sample_depth) - 1;
/*
* Get integer version of alpha.
* Check for opaque and transparent special cases;
* no compositing needed if so.
*
* We show the whole gamma decode/correct process in
* floating point, but it would more likely be done
* with lookup tables.
*/
13 ialpha = foreground[3];
14 if (ialpha == 0) {
/*
* Foreground image is transparent here.
* If the background image is already in the frame
* buffer, there is nothing to do.
*/
15 ;
16 } else if (ialpha == fg_maxsample) {
/*
* Copy foreground pixel to frame buffer.
*/
17 for (i = 0; i < 3; i++) {
18 gamfg = (float) foreground[i] / fg_maxsample;
19 linfg = pow(gamfg, 1.0/fg_gamma);
20 comppix = linfg;
21 gcvideo = pow(comppix,viewing_gamma/display_gamma);
22 fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
23 }
24 } else {
/*
* Compositing is necessary.
* Get floating-point alpha and its complement.
* Note: alpha is always linear; gamma does not
* affect it.
*/
25 alpha = (float) ialpha / fg_maxsample;
26 compalpha = 1.0 - alpha;
27 for (i = 0; i < 3; i++) {
/*
* Convert foreground and background to floating
* point, then linearize (undo gamma encoding).
*/
28 gamfg = (float) foreground[i] / fg_maxsample;
29 linfg = pow(gamfg, 1.0/fg_gamma);
30 gambg = (float) background[i] / bg_maxsample;
31 linbg = pow(gambg, 1.0/bg_gamma);
/*
* Composite.
*/
32 comppix = linfg * alpha + linbg * compalpha;
/*
* Gamma correct for display.
* Convert to integer frame buffer pixel.
*/
33 gcvideo = pow(comppix,viewing_gamma/display_gamma);
34 fbpix[i] = (int) (gcvideo * fb_maxsample + 0.5);
35 }
36 }
Variations:
* If output is to another PNG image file instead of a frame
buffer, lines 21, 22, 33, and 34 should be changed to be
something like
/*
* Gamma encode for storage in output file.
* Convert to integer sample value.
*/
gamout = pow(comppix, outfile_gamma);
outpix[i] = (int) (gamout * out_maxsample + 0.5);
Also, it becomes necessary to process background pixels when
alpha is zero, rather than just skipping pixels. Thus, line
15 will need to be replaced by copies of lines 17-23, but
processing background instead of foreground pixel values.
* If the sample depths of the output file, foreground file,
and background file are all the same, and the three gamma
values also match, then the no-compositing code in lines
14-23 reduces to nothing more than copying pixel values from
the input file to the output file if alpha is one, or
copying pixel values from background to output file if alpha
is zero. Since alpha is typically either zero or one for
the vast majority of pixels in an image, this is a great
savings. No gamma computations are needed for most pixels.
* When the sample depths and gamma values all match, it may
appear attractive to skip the gamma decoding and encoding
(lines 28-31, 33-34) and just perform line 32 using gamma-
encoded sample values. Although this doesn't hurt image
quality too badly, the time savings are small if alpha
values of zero and one are special-cased as recommended
here.
* If the original pixel values of the background image are no
longer available, only processed frame buffer pixels left by
display of the background image, then lines 30 and 31 need
to extract intensity from the frame buffer pixel values
using code like
/*
* Decode frame buffer value back into linear space.
*/
gcvideo = (float) fbpix[i] / fb_maxsample;
linbg = pow(gcvideo, display_gamma / viewing_gamma);
However, some roundoff error can result, so it is better to
have the original background pixels available if at all
possible.
* Note that lines 18-22 are performing exactly the same gamma
computation that is done when no alpha channel is present.
So, if you handle the no-alpha case with a lookup table, you
can use the same lookup table here. Lines 28-31 and 33-34
can also be done with (different) lookup tables.
* Of course, everything here can be done in integer
arithmetic. Just be careful to maintain sufficient
precision all the way through.
Note: in floating point, no overflow or underflow checks are
needed, because the input sample values are guaranteed to be
between 0 and 1, and compositing always yields a result that is in
between the input values (inclusive). With integer arithmetic,
some roundoff-error analysis might be needed to guarantee no
overflow or underflow.
When displaying a PNG image with full alpha channel, it is
important to be able to composite the image against some
background, even if it's only black. Ignoring the alpha channel
will cause PNG images that have been converted from an
associated-alpha representation to look wrong. (Of course, if the
alpha channel is a separate transparency mask, then ignoring alpha
is a useful option: it allows the hidden parts of the image to be
recovered.)
Even if the decoder author does not wish to implement true
compositing logic, it is simple to deal with images that contain
only zero and one alpha values. (This is implicitly true for
grayscale and truecolor PNG files that use a tRNS chunk; for
indexed-color PNG files, it is easy to check whether tRNS contains
any values other than 0 and 255.) In this simple case,
transparent pixels are replaced by the background color, while
others are unchanged. If a decoder contains only this much
transparency capability, it should deal with a full alpha channel
by treating all nonzero alpha values as fully opaque; that is, do
not replace partially transparent pixels by the background. This
approach will not yield very good results for images converted
from associated-alpha formats, but it's better than doing nothing.
10.9. Progressive display
When receiving images over slow transmission links, decoders can
improve perceived performance by displaying interlaced images
progressively. This means that as each pass is received, an
approximation to the complete image is displayed based on the data
received so far. One simple yet pleasing effect can be obtained
by expanding each received pixel to fill a rectangle covering the
yet-to-be-transmitted pixel positions below and to the right of
the received pixel. This process can be described by the
following pseudocode:
Starting_Row [1..7] = { 0, 0, 4, 0, 2, 0, 1 }
Starting_Col [1..7] = { 0, 4, 0, 2, 0, 1, 0 }
Row_Increment [1..7] = { 8, 8, 8, 4, 4, 2, 2 }
Col_Increment [1..7] = { 8, 8, 4, 4, 2, 2, 1 }
Block_Height [1..7] = { 8, 8, 4, 4, 2, 2, 1 }
Block_Width [1..7] = { 8, 4, 4, 2, 2, 1, 1 }
pass := 1
while pass <= 7
begin
row := Starting_Row[pass]
while row < height
begin
col := Starting_Col[pass]
while col < width
begin
visit (row, col,
min (Block_Height[pass], height - row),
min (Block_Width[pass], width - col))
col := col + Col_Increment[pass]
end
row := row + Row_Increment[pass]
end
pass := pass + 1
end
Here, the function "visit(row,column,height,width)" obtains the
next transmitted pixel and paints a rectangle of the specified
height and width, whose upper-left corner is at the specified row
and column, using the color indicated by the pixel. Note that row
and column are measured from 0,0 at the upper left corner.
If the decoder is merging the received image with a background
image, it may be more convenient just to paint the received pixel
positions; that is, the "visit()" function sets only the pixel at
the specified row and column, not the whole rectangle. This
produces a "fade-in" effect as the new image gradually replaces
the old. An advantage of this approach is that proper alpha or
transparency processing can be done as each pixel is replaced.
Painting a rectangle as described above will overwrite
background-image pixels that may be needed later, if the pixels
eventually received for those positions turn out to be wholly or
partially transparent. Of course, this is only a problem if the
background image is not stored anywhere offscreen.
10.10. Suggested-palette and histogram usage
In truecolor PNG files, the encoder may have provided a suggested
PLTE chunk for use by viewers running on indexed-color hardware.
If the image has a tRNS chunk, the viewer will need to adapt the
suggested palette for use with its desired background color. To
do this, replace the palette entry closest to the tRNS color with
the desired background color; or just add a palette entry for the
background color, if the viewer can handle more colors than there
are PLTE entries.
For images of color type 6 (truecolor with alpha channel), any
suggested palette should have been designed for display of the
image against a uniform background of the color specified by bKGD.
Viewers should probably ignore the palette if they intend to use a
different background, or if the bKGD chunk is missing. Viewers
can use a suggested palette for display against a different
background than it was intended for, but the results may not be
very good.
If the viewer presents a transparent truecolor image against a
background that is more complex than a single color, it is
unlikely that the suggested palette will be optimal for the
composite image. In this case it is best to perform a truecolor
compositing step on the truecolor PNG image and background image,
then color-quantize the resulting image.
The histogram chunk is useful when the viewer cannot provide as
many colors as are used in the image's palette. If the viewer is
only short a few colors, it is usually adequate to drop the
least-used colors from the palette. To reduce the number of
colors substantially, it's best to choose entirely new
representative colors, rather than trying to use a subset of the
existing palette. This amounts to performing a new color
quantization step; however, the existing palette and histogram can
be used as the input data, thus avoiding a scan of the image data.
If no palette or histogram chunk is provided, a decoder can
develop its own, at the cost of an extra pass over the image data.
Alternatively, a default palette (probably a color cube) can be
used.
See also Recommendations for Encoders: Suggested palettes (Section
9.5).
10.11. Text chunk processing
If practical, decoders should have a way to display to the user
all tEXt and zTXt chunks found in the file. Even if the decoder
does not recognize a particular text keyword, the user might be
able to understand it.
PNG text is not supposed to contain any characters outside the ISO
8859-1 "Latin-1" character set (that is, no codes 0-31 or 127-
159), except for the newline character (decimal 10). But decoders
might encounter such characters anyway. Some of these characters
can be safely displayed (e.g., TAB, FF, and CR, decimal 9, 12, and
13, respectively), but others, especially the ESC character
(decimal 27), could pose a security hazard because unexpected
actions may be taken by display hardware or software. To prevent
such hazards, decoders should not attempt to directly display any
non-Latin-1 characters (except for newline and perhaps TAB, FF,
CR) encountered in a tEXt or zTXt chunk. Instead, ignore them or
display them in a visible notation such as "\nnn". See Security
considerations (Section 8.5).
Even though encoders are supposed to represent newlines as LF, it
is recommended that decoders not rely on this; it's best to
recognize all the common newline combinations (CR, LF, and CR-LF)
and display each as a single newline. TAB can be expanded to the
proper number of spaces needed to arrive at a column multiple of
8.
Decoders running on systems with non-Latin-1 character set
encoding should provide character code remapping so that Latin-1
characters are displayed correctly. Some systems may not provide
all the characters defined in Latin-1. Mapping unavailable
characters to a visible notation such as "\nnn" is a good
fallback. In particular, character codes 127-255 should be
displayed only if they are printable characters on the decoding
system. Some systems may interpret such codes as control
characters; for security, decoders running on such systems should
not display such characters literally.
Decoders should be prepared to display text chunks that contain
any number of printing characters between newline characters, even
though encoders are encouraged to avoid creating lines in excess
of 79 characters.
11. Glossary
a^b
Exponentiation; a raised to the power b. C programmers should be
careful not to misread this notation as exclusive-or. Note that
in gamma-related calculations, zero raised to any power is valid
and must give a zero result.
Alpha
A value representing a pixel's degree of transparency. The more
transparent a pixel, the less it hides the background against
which the image is presented. In PNG, alpha is really the degree
of opacity: zero alpha represents a completely transparent pixel,
maximum alpha represents a completely opaque pixel. But most
people refer to alpha as providing transparency information, not
opacity information, and we continue that custom here.
Ancillary chunk
A chunk that provides additional information. A decoder can still
produce a meaningful image, though not necessarily the best
possible image, without processing the chunk.
Bit depth
The number of bits per palette index (in indexed-color PNGs) or
per sample (in other color types). This is the same value that
appears in IHDR.
Byte
Eight bits; also called an octet.
Channel
The set of all samples of the same kind within an image; for
example, all the blue samples in a truecolor image. (The term
"component" is also used, but not in this specification.) A
sample is the intersection of a channel and a pixel.
Chromaticity
A pair of values x,y that precisely specify the hue, though not
the absolute brightness, of a perceived color.
Chunk
A section of a PNG file. Each chunk has a type indicated by its
chunk type name. Most types of chunks also include some data.
The format and meaning of the data within the chunk are determined
by the type name.
Composite
As a verb, to form an image by merging a foreground image and a
background image, using transparency information to determine
where the background should be visible. The foreground image is
said to be "composited against" the background.
CRC
Cyclic Redundancy Check. A CRC is a type of check value designed
to catch most transmission errors. A decoder calculates the CRC
for the received data and compares it to the CRC that the encoder
calculated, which is appended to the data. A mismatch indicates
that the data was corrupted in transit.
Critical chunk
A chunk that must be understood and processed by the decoder in
order to produce a meaningful image from a PNG file.
CRT
Cathode Ray Tube: a common type of computer display hardware.
Datastream
A sequence of bytes. This term is used rather than "file" to
describe a byte sequence that is only a portion of a file. We
also use it to emphasize that a PNG image might be generated and
consumed "on the fly", never appearing in a stored file at all.
Deflate
The name of the compression algorithm used in standard PNG files,
as well as in zip, gzip, pkzip, and other compression programs.
Deflate is a member of the LZ77 family of compression methods.
Filter
A transformation applied to image data in hopes of improving its
compressibility. PNG uses only lossless (reversible) filter
algorithms.
Frame buffer
The final digital storage area for the image shown by a computer
display. Software causes an image to appear onscreen by loading
it into the frame buffer.
Gamma
The brightness of mid-level tones in an image. More precisely, a
parameter that describes the shape of the transfer function for
one or more stages in an imaging pipeline. The transfer function
is given by the expression
output = input ^ gamma
where both input and output are scaled to the range 0 to 1.
Grayscale
An image representation in which each pixel is represented by a
single sample value representing overall luminance (on a scale
from black to white). PNG also permits an alpha sample to be
stored for each pixel of a grayscale image.
Indexed color
An image representation in which each pixel is represented by a
single sample that is an index into a palette or lookup table.
The selected palette entry defines the actual color of the pixel.
Lossless compression
Any method of data compression that guarantees the original data
can be reconstructed exactly, bit-for-bit.
Lossy compression
Any method of data compression that reconstructs the original data
approximately, rather than exactly.
LSB
Least Significant Byte of a multi-byte value.
Luminance
Perceived brightness, or grayscale level, of a color. Luminance
and chromaticity together fully define a perceived color.
LUT
Look Up Table. In general, a table used to transform data. In
frame buffer hardware, a LUT can be used to map indexed-color
pixels into a selected set of truecolor values, or to perform
gamma correction. In software, a LUT can be used as a fast way of
implementing any one-variable mathematical function.
MSB
Most Significant Byte of a multi-byte value.
Palette
The set of colors available in an indexed-color image. In PNG, a
palette is an array of colors defined by red, green, and blue
samples. (Alpha values can also be defined for palette entries,
via the tRNS chunk.)
Pixel
The information stored for a single grid point in the image. The
complete image is a rectangular array of pixels.
PNG editor
A program that modifies a PNG file and preserves ancillary
information, including chunks that it does not recognize. Such a
program must obey the rules given in Chunk Ordering Rules (Chapter
7).
Sample
A single number in the image data; for example, the red value of a
pixel. A pixel is composed of one or more samples. When
discussing physical data layout (in particular, in Image layout,
Section 2.3), we use "sample" to mean a number stored in the image
array. It would be more precise but much less readable to say
"sample or palette index" in that context. Elsewhere in the
specification, "sample" means a color value or alpha value. In
the indexed-color case, these are palette entries not palette
indexes.
Sample depth
The precision, in bits, of color values and alpha values. In
indexed-color PNGs the sample depth is always 8 by definition of
the PLTE chunk. In other color types it is the same as the bit
depth.
Scanline
One horizontal row of pixels within an image.
Truecolor
An image representation in which pixel colors are defined by
storing three samples for each pixel, representing red, green, and
blue intensities respectively. PNG also permits an alpha sample
to be stored for each pixel of a truecolor image.
White point
The chromaticity of a computer display's nominal white value.
zlib
A particular format for data that has been compressed using
deflate-style compression. Also the name of a library
implementing this method. PNG implementations need not use the
zlib library, but they must conform to its format for compressed
data.
12. Appendix: Rationale
(This appendix is not part of the formal PNG specification.)
This appendix gives the reasoning behind some of the design decisions
in PNG. Many of these decisions were the subject of considerable
debate. The authors freely admit that another group might have made
different decisions; however, we believe that our choices are
defensible and consistent.
12.1. Why a new file format?
Does the world really need yet another graphics format? We
believe so. GIF is no longer freely usable, but no other commonly
used format can directly replace it, as is discussed in more
detail below. We might have used an adaptation of an existing
format, for example GIF with an unpatented compression scheme.
But this would require new code anyway; it would not be all that
much easier to implement than a whole new file format. (PNG is
designed to be simple to implement, with the exception of the
compression engine, which would be needed in any case.) We feel
that this is an excellent opportunity to design a new format that
fixes some of the known limitations of GIF.
12.2. Why these features?
The features chosen for PNG are intended to address the needs of
applications that previously used the special strengths of GIF.
In particular, GIF is well adapted for online communications
because of its streamability and progressive display capability.
PNG shares those attributes.
We have also addressed some of the widely known shortcomings of
GIF. In particular, PNG supports truecolor images. We know of no
widely used image format that losslessly compresses truecolor
images as effectively as PNG does. We hope that PNG will make use
of truecolor images more practical and widespread.
Some form of transparency control is desirable for applications in
which images are displayed against a background or together with
other images. GIF provided a simple transparent-color
specification for this purpose. PNG supports a full alpha channel
as well as transparent-color specifications. This allows both
highly flexible transparency and compression efficiency.
Robustness against transmission errors has been an important
consideration. For example, images transferred across Internet
are often mistakenly processed as text, leading to file
corruption. PNG is designed so that such errors can be detected
quickly and reliably.
PNG has been expressly designed not to be completely dependent on
a single compression technique. Although deflate/inflate
compression is mentioned in this document, PNG would still exist
without it.
12.3. Why not these features?
Some features have been deliberately omitted from PNG. These
choices were made to simplify implementation of PNG, promote
portability and interchangeability, and make the format as simple
and foolproof as possible for users. In particular:
* There is no uncompressed variant of PNG. It is possible to
store uncompressed data by using only uncompressed deflate
blocks (a feature normally used to guarantee that deflate
does not make incompressible data much larger). However,
PNG software must support full deflate/inflate; any software
that does not is not compliant with the PNG standard. The
two most important features of PNG---portability and
compression---are absolute requirements for online
applications, and users demand them. Failure to support full
deflate/inflate compromises both of these objectives.
* There is no lossy compression in PNG. Existing formats such
as JFIF already handle lossy compression well. Furthermore,
available lossy compression methods (e.g., JPEG) are far
from foolproof --- a poor choice of quality level can ruin
an image. To avoid user confusion and unintentional loss of
information, we feel it is best to keep lossy and lossless
formats strictly separate. Also, lossy compression is
complex to implement. Adding JPEG support to a PNG decoder
might increase its size by an order of magnitude. This
would certainly cause some decoders to omit support for the
feature, which would destroy our goal of interchangeability.
* There is no support for CMYK or other unusual color spaces.
Again, this is in the name of promoting portability. CMYK,
in particular, is far too device-dependent to be useful as a
portable image representation.
* There is no standard chunk for thumbnail views of images.
In discussions with software vendors who use thumbnails in
their products, it has become clear that most would not use
a "standard" thumbnail chunk. For one thing, every vendor
has a different idea of what the dimensions and
characteristics of a thumbnail ought to be. Also, some