PNG (PORTABLE NETWORK GRAPHICS) SPECIFICATION, SEVENTH DRAFT
By:
* Thomas Boutell, bout...@netcom.com
* Mark Adler, mad...@cco.caltech.edu
* Lee Daniel Crocker, lcroc...@netcom.com
* Tom Lane, t...@sss.pgh.pa.us
Permission granted to reproduce this specification in complete and
unaltered form. Excerpts may be printed with the following notice:
"excerpted from the PNG (Portable Network Graphics) specification,
seventh draft." No notice is required in software that follows this
specification; notice is only required when reproducing or
excerpting from the specification itself.
The authors wish to acknowledge the contributions of the New Graphics
Format mailing list and the readers of comp.graphics.
This is the seventh draft of the PNG (formerly "PBF") specification
discussion document, replacing all previous drafts. There are several
significant changes from the previous drafts.
CHANGES IN THIS DRAFT
* Chunk naming convention changed
* EOIM: Formerly EOF
* HEAD, EOIM: CRC added to HEAD, modified in EOIM
* HEAD: Filter type added to HEAD chunk
* IDAT: Bytes no longer straddle scan lines
* PLTE: Removed injunctions regarding palette order
* phys: Meters only, rather than decimeters and inches
* gama: Divide by 10000 rather than 1000
* text: Replaces ACMT and ACPY; creates keyword scheme
* thmb: Thumbnail stream does not have 8-byte header
* prnt: Location of origin made explicit
1. RATIONALE
The PNG format is intended to provide a portable, legally
unencumbered, simple, lossless, streaming-capable, well-compressed,
well-specified standard for bitmapped image files which gives new
features to the end user at minimal cost to the developer.
It has been asked why the PNG format is not simply an extension of the
GIF format. The short answer is that the GIF format is embroiled in
legal disputes, does not support 24-bit images and lacks the option of
an alpha channel.
It has been asked why the PNG format is not TIFF, or a subset of TIFF.
The answer is that TIFF does not support a compression scheme that is
not legally encumbered, and that a subset of TIFF would simply
frustrate users making the reasonable assumption that a file saved as
TIFF from Software XYZ will load into a program supporting our flavor
of TIFF. Implementing full TIFF would violate the simplicity
constraint.
It has been asked why the PNG format is not IFF, or a sub- or superset
of IFF. The same concern applies as with TIFF: users with software
that purports to generate IFF files will not be pleased when those
files do not load in programs supporting the new specification. In
addition, the IFF specification has rarely been accurately implemented
and there is considerable disagreement among implementations. The IFF
file structure could be used, but was not designed with streaming
applications in mind; there are workarounds for this, but they are not
widely implemented.
It has been asked why PNG does not include lossy compression. The
answer is that JPEG already does an excellent job of lossy
compression, and there is no reason to repeat that effort. Different
tools, different jobs.
It has been asked why PNG uses network byte order. We have selected
one byte ordering and used it consistently. Which order in particular
is of little relevance, but network byte order has the advantage that
routines to convert to and from it are already available on any
platform that supports TCP/IP networking, including all PC
platforms.
It has been asked why PNG does not directly support multiple images.
It is expected that a metaformat will be created which permits
multiple images and uses PNG-like data streams internally, with
certain minimal alterations, such as the optional omission of
palettes. In such a metaformat, the identifying bytes at the beginning
must NOT be the same as for PNG.
PNG has been expressly designed not to be completely dependent on a
single compression technique. Although inflate/deflate compression is
mentioned in this document, PNG would still exist without it.
PNG supports an alpha channel as well as the transparency-index
approach used in GIF. An alpha channel is much more flexible than a
transparency index, whereas a transparency index compresses more
efficiently.
3. DATA REPRESENTATION NOTE
Integer Values and Byte Order
All integers which are not 1 byte integers will be in network byte
order, which is to say the most significant byte comes first, and the
less significant bytes in descending order of significance (MSB LSB
for two-byte integers, B3 B2 B1 B0 for 4-byte integers). References to
bit 7 refer to the highest bit (128) of a byte; references to bit 0
refer to the lowest bit (1) of a byte. Values are unsigned unless
otherwise noted. Values explicitly noted as signed are represented in
two's complement notation.
Color Values
All color values range from zero (black) to most intense at the
maximum value for the bit depth. The "gama" chunk specifies the gamma
response of the source device, and viewers are strongly encouraged to
properly compensate.
Note that the maximum value at a given bit depth is not 2^bitdepth,
but rather 2^(bitdepth-1). When scaling values with a bit depth that
cannot be directly represented in PNG (4 bit truecolor, for instance),
an excellent approximation to the correct value can be achieved by
shifting the valid bits to begin in bit 7 (the most significant bit)
and repeating the most significant bits into the open bits.
For example, if 5 bits per channel are available in the source data,
an acceptable conversion to a bitdepth of 8 can be achieved as
follows:
If the red value for a pixel in the source data is 27 (in a range from
0-31), then the original bits are:
4 3 2 1 0
---------
1 1 0 1 1
Converted to a bitdepth of 8:
7 6 5 4 3 2 1 0
----------------
1 1 0 1 1 1 1 0
|=======| |===|
| Leftmost Bits Repeated to Fill Open Bits
|
Original Bits
Pixel dimensions
Non-square pixels can be represented, but viewers are not required to
account for them; see the "phys" chunk.
4. THE FORMAT
The Identification Header
The first eight bytes always contain the following values:
137 80 78 71 13 10 26 10
The first two bytes distinguish the file on systems that expect the
first two bytes to identify the file uniquely. Bytes two through four
(overlap with the first two intentional) name the format. The CR-LF
sequence catches bad file transfers that alter these characters. The
control-Z character stops file display under MSDOS. The final line
feed checks for the inverse of the CR-LF translation problem.
The Main Section
The remainder of the file consists of a series of chunks, where each
chunk consists of a 4-byte chunk type, 4-byte, UNSIGNED length (not
including itself or the chunk type), and the data bytes appropriate to
that chunk, if any. Note that this provides for a chunk to be skipped
even if the implementation does not recognize that particular chunk
type. The last chunk must always be an EOIM chunk.
The four-byte chunk type should consist entirely of ASCII letters.
If the chunk is critical (see below), its name begins with an
uppercase letter. If the chunk is ancillary (see below), its name
begins with a lowercase letter. Official chunk types in this
specification will always consist entirely of either uppercase or
lowercase letters; mixed-case chunk names will always be unassigned
and can be used for proprietary purposes.
IMPORTANT:
Even though chunk lengths are unsigned, chunks should not exceed
(2^31)-1 in size, in order to accommodate languages which do not
accommodate 4-byte unsigned integers well. (1- and 2-byte unsigned
integers can be accommodated by using the next larger size of integer
in such languages.)
Note also that the same chunk type can appear more than once if
necessary, but only if so specified in the description of the chunk.
This is sometimes necessary in order to implement streaming encoders.
The chunk-ordering mechanism present in the first two drafts has been
dropped. Instead, rules regarding chunk order are stated in the
description of each chunk.
Ancillary and Critical Chunks
Chunks which are not strictly necessary in order to meaningfully
display the contents of the file are known as "ancillary" chunks, and
their names must begin with a lowercase letter. Decoders encountering
an unknown chunk beginning with a lowercase letter may safely ignore
it and display the image. The printing position chunk (prnt) is an
example of an ancillary chunk.
Chunks which are critical to the successful display of the file's
contents begin with an uppercase letter. Decoders encountering an
unknown chunk beginning with an uppercase letter must indicate to the
user that the image contains information it cannot safely interpret
and refuse to display the contents of the file. The image header chunk
(HEAD) is an example of a critical chunk.
Proprietary Chunks
If you want others outside your organization to understand a chunk
type that you invent, CONTACT THE AUTHOR OF THE PNG SPECIFICATION
(bout...@netcom.com) and specify the format of the chunk's data and
your preferred chunk type. The author will assign a permanent, unique
chunk type. The chunk type will be publicly listed in an appendix of
extended chunk types which can be optionally implemented. In the event
that Mr. Boutell is unable to maintain the specification, the task
will be passed on to a qualified volunteer.
If you do not require or desire that others outside your organization
understand the chunk type, you may use a chunk name containing BOTH
uppercase and lowercase characters. The first character should
indicate whether the chunk is critical (capital) or ancillary
(lowercase); at least one of the subsequent three characters must
differ in case from the first.
Please note that if you want to use these chunks for information that
is not essential to view the image, and have any desire whatsoever
that others not using your internal viewer software be able to view
the image, you should use an ancillary chunk type (first character is
lowercase) rather than a critical chunk type (first character
uppercase).
Also note that others may use the same proprietary chunk names, so it
is advantageous to keep additional identifying information at the
beginning of the chunk.
Standard Chunks
All PNG implementations must accept the following chunk types in order
to be considered PNG-compliant. All implementations must understand
and successfully render the critical chunks below. Standalone image
viewers should also be capable of displaying the ancillary chunks
below, such as the copyright notice, but this is not necessary for
applications in which many images may be displayed at once (ie, WWW
browsers).
Chunk Type Description
HEAD Bitmapped image header
This chunk must appear FIRST if the file contains
a bitmapped image.
Width: 4 bytes
Height: 4 bytes
Bit depth: 1 byte
Color type: 1 byte
Compression type: 1 byte
Filter type: 1 byte
Interlace type: 1 byte
CRC: 4 bytes
Width and height are 4-byte integers. Zero
is an invalid value. The maximum for both
is (2^31)-1 in order to accommodate languages
which have difficulty with unsigned 4-byte values.
Bit depth is a single-byte integer. Valid values
that software must support are 1, 2, 4, 8, and 16.
(Note that bit depths of 16 are easily supported on
8-bit display hardware by dropping the least
significant byte.)
Color type is a single-byte integer. Valid values
are 1, 2, 3 and 4. Color type determines the
interpretation of the image data.
Color Type Valid Bit Depths Interpretation
1 1,2,4,8 Each pixel value is a palette
index; a palette chunk will appear
2 1,2,4,8,16 Each pixel value is a grayscale
level, where the largest value is
white, and zero is black
3 8,16 Each pixel value is a three-value
series: red (0 = black, max = red),
green (0 = black, max = green),
blue (0 = black, max = blue)
4 8,16 Each pixel value is a four-value
series: red (0 = black, max = red),
green (0 = black, max = green),
blue (0 = black, max = blue),
alpha (0 = transparent,
max = opaque)
Compression Type
Compression type indicates the compression scheme
which will be used to compress the image data.
This draft proposes use of the inflate/deflate compression
scheme, an LZ77 derivative which is used in zip, gzip, pkzip
and related programs, because extensive research has been done
supporting its legality. Inflate and deflate code
is available in the zip/unzip packages with a very
permissive license (yes, permissive enough for
commercial purposes, see those packages for details).
At present, only compression type 0 (inflate/deflate
compression with a 32K sliding window) is defined. At present,
all standard PNG images must be compressed with this scheme.
Filter Type
Several filters are defined by the PNG specification. The
purpose of these filters is to prepare the image data for
optimum compression. For color types 3 and 4, filters are
applied to each distinct component (red, green, blue and
alpha in the case of color type 4). All PNG filters are
strictly lossless. Decoders must understand filters in
order to display the image.
Filters defined in PNG:
Byte Name
0 None
1 Cross
2 Sub
Filter 0 (none) should always be used for color type 1.
Filter type 1 (cross) should be used for noninterlaced
images of color type 2, and should also be used for
noninterlaced images of color types 3 and 4 unless it is
known that the image was converted from
an 8-bit source (eg, a GIF converted to a 24-bit PNG),
in which case 0 (none) should be used.
Filter type 2 (sub) should be used for interlaced
images of color type 2, and should also be used for
interlaced images of color types 3 and 4 unless it is
known that the image was converted from
an 8-bit source (eg, a GIF converted to a 24-bit PNG),
in which case 0 (none) should be used.
See section 5 (details of specific algorithms) for
exact definitions of the cross and sub filters.
Interlace Type
At present, there are two legal values for
interlace type: 0 (no interlace) or 1
(line-wise interlace).
With interlace type 0, rows are laid out
continuously from top to bottom.
With interlace type 1, rows are stored in the
following order:
Every eighth row, starting from row 0
Every eighth row, starting from row 4
Every fourth row, starting from row 2
Every second row, starting from row 1
The purpose of this feature is to allow images
to "fade in" in a simple fashion that does
minimal damage to compression efficiency,
although the file size is slightly expanded
on average.
Other interlace types have been proposed, and will
replace this scheme in the final proposal if the gain
in visual quality is sufficient to outweigh any compression
penalties.
CRC
A four-byte value containing the result of a Cyclical
Redundancy Check on the preceding bytes of the chunk.
This is required in order to detect badly-transferred
images as quickly as possible. The CRC polynomial
is as follows:
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1
(CRC computation is not difficult, nor as computationally
intensive as the above may suggest.)
gama Gamma Correction
Gamma correction factor: 2 bytes
The gamma correction chunk specifies the gamma of the
device which created the image, and for which the
color values are intended. If the encoder does not
know the gamma value, it should not
write a gamma chunk; the absence of a gamma chunk
indicates the gamma is unknown. If the gamma chunk
does appear, it must precede the PLTE chunk.
If it is possible for the encoder to determine the gamma,
or to make a strong guess based on the hardware on which it
runs, then the encoder is strongly encouraged to output
the "gama" chunk.
The gamma function determines the true response of the video
display to a given level, assuming that input levels have
been normalized to a range between 0.0 and 1.0:
brightness = inputLevel ^ gamma
A value of 10000 is equivalent to a gamma of 1.0, a value
of 20000 to a gamma of 2.0, and so on (divide by 10000.0).
Thus, when writing an image display program,
if the display hardware has a gamma
value of 2.0 (2000), and the gamma specified in
the gamma correction chunk for a particular image is
3.0 (3000), then color and grayscale levels should ideally
be normalized to a range between 0.0 and 1.0,
then converted according to the following function:
nativeLevel = inputLevel ^ (inputGamma / nativeGamma)
Where inputLevel is the level specified for that
pixel in the PNG file, inputGamma is the gamma specified in
the PNG file, and nativeGamma is the gamma of the
actual display to be used.
In practice, it is often difficult to determine
the gamma of the actual display. It is common to
assume a gamma of 2.2 (or 1.0, on hardware for
which this value is common) and allow the user to
modify this value at their option.
Also note that it is not difficult to calculate a gamma
conversion table; it is *not* necessary to
perform transcendental math for every pixel!
Although viewers are strongly encouraged to
implement gamma correction, in some cases speed
may be a concern. In these cases, viewers are
encouraged to provide gamma correction tables for
gamma values of 1.0 and 2.2, and to use the table
closest to the gamma indicated in the file.
PLTE Palette
This chunk must appear for color type 1, and
may appear for color types 3 and 4. If this chunk
does appear, it must precede the first IDAT chunk.
In the case of color types 3 and 4, the palette chunk is
optional, and provides a recommended set of from 1 to 256
colors to which the true-color image should be quantized if
the display hardware cannot display truecolor directly.
If it is not present, the viewer must select colors on its own,
but it is most efficient for this to be done once by
the encoder.
The number of palette entries varies from 1 to 256.
For palette type 1, the number of entries should not
exceed the range that can be represented by the
bit depth (for example, 2^4 = 16 for a bit depth of 4).
Note that this does NOT mean that there have to
be a full 16 entries. The length of the chunk is used
to determine the number of entries.
For color type 1, each palette entry consists of a
three-byte series:
red (0 = black, 255 = red),
green (0 = black, 255 = green),
blue (0 = black, 255 = blue),
For color types 3 and 4, in which the palette is
optional and only a suggested quantization,
the same exact format is used, again with
3 bytes per palette entry:
red (0 = black, 255 = red),
green (0 = black, 255 = green),
blue (0 = black, 255 = blue)
Note that the palette uses 8 bits (1 byte) per value
regardless of the image bit depth specification.
In particular, the palette is 8 bits deep even when it is
a suggested quantization of a 16-bit truecolor image.
trns Transparency. Transparency is a simple alternative to
the full truecolor alpha channel which does not
compromise compression.
For color type 1:
Transparent index into palette
(1 byte, range: 0 - (size of palette-1) )
Any value outside the size of the palette is an error. Note
that the size of the palette is determined by the size of
the palette chunk (and thus the number of three-byte entries
in it), and not by the bit depth.
For color type 2:
Transparent gray level (2 bytes, range: 0 - (2^bitdepth - 1))
For color type 3:
Transparent RGB color (6 bytes, 2 bytes for
red, green and blue components, range for each:
0 - (2^bitdepth - 1))
The transparency chunk, when present, specifies a
specific palette entry, grayscale level or
RGB color which should be regarded as transparent.
Although transparency is not as elegant as the full
alpha channel of color type 4, transparency does not adversely
affect the compression of the image.
When present, the "trns" chunk must precede
the first IDAT chunk, and follow the
PLTE chunk, if any.
bkgd Background color.
When displaying the image in a
stand-alone viewer, it is useful to specify the
background color against which the image is
intended to appear.
For color type 1:
Background index into palette
(1 byte, range: 0 - (size of palette-1) )
For color type 2:
Background gray level (2 bytes, range: 0 - (2^bitdepth - 1))
For color type 3:
Background RGB color (6 bytes, 2 bytes for
red, green and blue components, range for each:
0 - (2^bitdepth - 1))
When present, the bkgd chunk must precede
the first IDAT chunk, and follow the
PLTE chunk, if any.
text Text.
Text chunks consist of a null-terminated keyword
containing any sequence of ISO 8859-1 (LATIN-1)
characters (the LATIN-1 set includes the ASCII set),
followed by the text associated with that keyword.
Note that the text is not null-terminated
(the length of the chunk is sufficient information
to locate the ending).
Any number of "text" chunks may appear, and more than
one with the same keyword is permissible.
The following text keywords are predefined
and should be used where possible:
Title
Author
Copyright
Description
Other keywords, containing any sequence of
printable characters in the character set, may
be invented for other purposes.
phys Physical pixel dimensions.
4 bytes: pixels per unit, X axis (unsigned integer)
4 bytes: pixels per unit, Y axis (unsigned integer)
1 byte: unit specifier
The following values are legal for the unit specifier:
0: units unknown (aspect ratio only)
1: unit is the meter
Large units are employed to ensure sufficient
resolution. If this ancillary chunk is not present,
pixels are assumed to be square, and the physical
size of each pixel is unknown. (Conversion note: one inch
is equal to 2.54 centimeters, and therefore to .0254 meters.)
prnt Physical image location for printing purposes.
4 bytes: image position in microns (X axis)
4 bytes: image position in microns (Y axis)
The position on a printed page at which the image
should be output when printed alone. Note that the
origin is assumed to be at the upper left corner
of the page.
time Time of image creation. Greenwich Mean Time (GMT)
should be specified, not local time.
2 bytes: Year (complete; ie, 1995)
1 byte: Month (1-12)
1 byte: Day (1-31)
1 byte: Hour (0-23)
1 byte: Minute (0-23)
1 byte: Second (0-59)
thmb Thumbnail image. This chunk contains a complete, distinct
PNG data stream, with the following and only exceptions:
1. The eight-byte header is not present.
2. The enclosed stream must not include another
"thmb" chunk.
The thumbnail PNG stream should describe a much smaller version
of the same image, suitable for icon or catalog use.
If the "thmb" chunk appears, it should appear prior
to the IDAT chunk.
Since the "thmb" chunk is a PNG data stream in its
own right, it can easily be extracted and transmitted
independently by packages such as web servers, and it can
also be palette-based even if the complete image is a
truecolor image.
Note that the entire thumbnail stream must fit in a single
"thmb" chunk; this is intentional as thumbnails are
intended to be much smaller than the full image and
are not intended as a general-purpose
multiple image facility.
IDAT Image data.
The image data will be compressed using the
compression scheme indicated by the compression
type field of the HEAD chunk.
IMPORTANT: the compressed image data is the concatenation
of the contents of ALL the IDAT chunks. (If there are
multiple IDAT chunks, they will always appear
sequentially.) Viewers must be able to interpret such chunks.
(Simply speaking, the viewer knows it is not finished until it
has read as many pixels as are indicated by the
image dimensions in the HEAD chunk.) This rule
exists to permit encoders to work in a fixed
amount of memory by outputting multiple chunks.
The following text describes the uncompressed
data stream which will be fed to the compressor
or received from the decompressor.
Pixels are always laid out left to right in
each row, and rows are arranged from
top to bottom, except as modified by
the interlace type field of the HEAD chunk.
Color types 1 and 2
For color type 1, each pixel value is an index into the
palette indicating which color in the palette should be
displayed at that location.
For color type 2 (grayscale), each pixel value relates to the
grayscale level as follows:
Grayscale levels are represented by a value between 0
and (2^bitdepth) - 1, where 0 is black and the latter value is
white. This value is then passed through the
filter specified by the Filter Type field of the
HEAD chunk. Note that correct interpretation of the filter
is required for proper display.
The resulting values are then packed as follows:
For 1-bit images, each horizontal line of pixels is represented
by a stream of bits, in which bit 7 (128) is the
leftmost pixel in the byte and bit 0 (1) is the
rightmost. Consecutive lines do NOT share bytes.
That is, if the last pixel of the line falls
in bit 4 of a byte, the first pixel of the next
line is stored in bit 7 of the next byte.
For 2-bit images, the same scheme is followed, except that
each pixel is represented by a 2-bit portion
of a byte, with the leftmost bit being most
significant. For instance, the first pixel
of the line is represented by bits 7 (128) and
6 (64) of the byte. Consecutive lines do NOT share bytes.
For 4-bit images, the same scheme is followed, except
that each pixel is represented by a 4-bit portion
of a byte, with the leftmost bit being most
significant. For instance, the first pixel
of the line is represented by bits 7 (128),
6 (64), 5 (32) and 4 (16) of the byte.
Consecutive lines do NOT share bytes.
For 8-bit images, each pixel is represented by a single
byte. For 16-bit grayscale images (color type 2),
each pixel is represented by a two-byte unsigned integer.
Again, note that grayscale values are filtered
before packing (see discussion above). Palette
color values (color type 1) are NOT filtered.
Color types 3 and 4
For color type 3, each pixel is initially represented
by a red value, a green value, and a blue value,
8 or 16 bits apiece respectively depending
on the bit depth (8 or 16). For color type 4,
an additional alpha (opacity) value of the
same depth is added for each pixel.
For both color type 3 and color type 4, the resulting
values are then filtered according to the
value of the Filter Type field of the HEAD chunk.
Note that viewers must properly handle filtering
in order to successfully display all images.
EOIM End of Image
CRC (4 bytes)
The EOIM chunk must appear last in the PNG file.
The EOIM chunk contains a 4-byte CRC
(Cyclical Redundancy Check) of all bytes
FOLLOWING the end of the HEAD chunk.
The CRC is NOT optional.
The CRC polynomial is as follows:
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1
(CRC computation is not difficult, nor as computationally
intensive as the above may suggest.)
If the CRC does not match that calculated by
the viewer, the viewer may elect to attempt to
display the contents of the file, but must warn the user
that the CRC is incorrect and the data is very likely to be
garbage. This mechanism helps to detect images that have been
improperly transmitted.
5. DETAILS OF SPECIFIC ALGORITHMS
Inflate and Deflate
See the zip/unzip package, which includes source code for both
purposes in the files inflate.c and deflate.c, with a very permissive
license. Documentation of the compression scheme is also available;
see the zip/unzip package for references. (zip/unzip and pkzip are
compatible but not identical. pkzip is commercial software.)
A formal, detailed specification of inflate and deflate will be
included in the final standard, and is being written at this time. The
formal specification will be compatible with the format defined by the
inflate.c/deflate.c code.
The Sub Filter
The sub filter is used to improve compression on interlaced truecolor
images (color types 3 and 4) and 8- and 16-bit grayscale images (color
type 2).
For each pixel, output the difference between that pixel and the
previous pixel, modulo the range possible in that bit depth. For
instance, for a bit depth of 8, if the previous pixel was 16 and the
current pixel is 64, store 48. If the previous pixel was 255 and the
current pixel is 20, store 21. Note that unsigned addition is used.
IMPORTANT: At the start of each line, consider the previous pixel
value to be zero.
The Cross Filter
The cross filter is used to improve compression on non-interlaced
truecolor images (color types 3 and 4) and 8- and 16-bit grayscale
images (color type 2). Cross is similar to sub, but takes the previous
line into account (highly effective as long as the image is not
interlaced).
Output the following value, using unsigned modulo arithmetic and
integers of the size appropriate to the bit depth (8 or 16):
Pixel[x][y] - Pixel[x-1][y] - Pixel[x][y-1] + Pixel[x-1][y-1]
for each channel (red, green, blue, and sometimes alpha) of each
pixel.
On the first row of the image, the previous row is considered to have
contained only zeroes. On the first pixel of each row, the previous
pixel is considered to have contained only zeroes.
To reverse the effect of the cross filter after decompression, output
the following value:
CrossedValue + Pixel[x-1][y] + Pixel[x][y-1] - Pixel[x-1][y-1]
storing the result as the value of the previous pixel for use in
uncrossing subsequent pixels.
The Alpha Channel
Standalone image viewers can ignore the alpha channel, provided that
they properly skip over it in order to be in the right position to
read the next pixel. However, if the background color has been set
with the ABGD chunk, the alpha channel can be meaningfully interpreted
with respect to it even in a standalone image viewer.
World Wide Web browsers and the like should regard any pixel with an
alpha channel value of zero as transparent (the pixel should be given
the background color of the browser), and any pixel with the maximum
alpha channel value for that bit depth as opaque (not blending with
the background at all).
Viewers which are not in a position to smoothly combine foreground and
background colors should regard any nonzero alpha channel value as
fully opaque (fully foreground color).
For applications that do not require a full alpha channel, or cannot
afford the price in compression efficiency, the ATNS transparency
chunk is also available.
6. PRONOUNCIATION
PNG is pronounced "ping".
End of PNG Specification
--
The ouzo of human kindness.
<URL:http://sunsite.unc.edu/boutell/index.html>
|
