png_specification.htm

png、jpeg的文档

<P>Transparency control is also possible without the storage cost of a full 
alpha channel. In an indexed-color image, an alpha value can be defined for each 
palette entry. In grayscale and truecolor images, a single pixel value can be 
identified as being "transparent". These techniques are controlled by the 
<TT>tRNS</TT> ancillary chunk type. 
<P>If no alpha channel nor <TT>tRNS</TT> chunk is present, all pixels in the 
image are to be treated as fully opaque. 
<P>Viewers can support transparency control partially, or not at all. 
<P>See Rationale: <A 
href="http://www.w3.org/TR/REC-png.html#R.Non-premultiplied-alpha">Non-premultiplied 
alpha (Section 12.8)</A>, Recommendations for Encoders: <A 
href="http://www.w3.org/TR/REC-png.html#E.Alpha-channel-creation">Alpha channel 
creation (Section 9.4)</A>, and Recommendations for Decoders: <A 
href="http://www.w3.org/TR/REC-png.html#D.Alpha-channel-processing">Alpha 
channel processing (Section 10.8)</A>. 
<H3><A name=DR.Filtering>2.5. Filtering</A></H3>PNG allows the image data to be 
<EM>filtered</EM> before it is compressed. Filtering can improve the 
compressibility of the data. The filter step itself does not reduce the size of 
the data. All PNG filters are strictly lossless. 
<P>PNG defines several different filter algorithms, including "None" which 
indicates no filtering. The filter algorithm is specified for each scanline by a 
filter type byte that precedes the filtered scanline in the precompression 
datastream. An intelligent encoder can switch filters from one scanline to the 
next. The method for choosing which filter to employ is up to the encoder. 
<P>See <A href="http://www.w3.org/TR/REC-png.html#Filters">Filter Algorithms 
(Chapter 6)</A> and Rationale: <A 
href="http://www.w3.org/TR/REC-png.html#R.Filtering">Filtering (Section 
12.9)</A>. 
<H3><A name=DR.Interlaced-data-order>2.6. Interlaced data order</A></H3>A PNG 
image can be stored in interlaced order to allow progressive display. The 
purpose of this feature is to allow images to "fade in" when they are being 
displayed on-the-fly. Interlacing slightly expands the file size on average, but 
it gives the user a meaningful display much more rapidly. Note that decoders are 
required to be able to read interlaced images, whether or not they actually 
perform progressive display. 
<P>With interlace method 0, pixels are stored sequentially from left to right, 
and scanlines sequentially from top to bottom (no interlacing). 
<P>Interlace method 1, known as Adam7 after its author, Adam M. Costello, 
consists of seven distinct passes over the image. Each pass transmits a subset 
of the pixels in the image. The pass in which each pixel is transmitted is 
defined by replicating the following 8-by-8 pattern over the entire image, 
starting at the upper left corner: <PRE>   1 6 4 6 2 6 4 6
   7 7 7 7 7 7 7 7
   5 6 5 6 5 6 5 6
   7 7 7 7 7 7 7 7
   3 6 4 6 3 6 4 6
   7 7 7 7 7 7 7 7
   5 6 5 6 5 6 5 6
   7 7 7 7 7 7 7 7
</PRE>Within each pass, the selected pixels are transmitted left to right within 
a scanline, and selected scanlines sequentially from top to bottom. For example, 
pass 2 contains pixels 4, 12, 20, etc. of scanlines 0, 8, 16, etc. (numbering 
from 0,0 at the upper left corner). The last pass contains the entirety of 
scanlines 1, 3, 5, etc. 
<P><STRONG>The data within each pass is laid out as though it were a complete 
image of the appropriate dimensions.</STRONG> For example, if the complete image 
is 16 by 16 pixels, then pass 3 will contain two scanlines, each containing four 
pixels. When pixels have fewer than 8 bits, each such scanline is padded as 
needed to fill an integral number of bytes (see <A 
href="http://www.w3.org/TR/REC-png.html#DR.Image-layout">Image layout, Section 
2.3</A>). Filtering is done on this reduced image in the usual way, and a filter 
type byte is transmitted before each of its scanlines (see <A 
href="http://www.w3.org/TR/REC-png.html#Filters">Filter Algorithms, Chapter 
6</A>). Notice that the transmission order is defined so that all the scanlines 
transmitted in a pass will have the same number of pixels; this is necessary for 
proper application of some of the filters. 
<P><STRONG>Caution:</STRONG> If the image contains fewer than five columns or 
fewer than five rows, some passes will be entirely empty. Encoders and decoders 
must handle this case correctly. In particular, filter type bytes are only 
associated with nonempty scanlines; no filter type bytes are present in an empty 
pass. 
<P>See Rationale: <A 
href="http://www.w3.org/TR/REC-png.html#R.Interlacing">Interlacing (Section 
12.6)</A> and Recommendations for Decoders: <A 
href="http://www.w3.org/TR/REC-png.html#D.Progressive-display">Progressive 
display (Section 10.9)</A>. 
<H3><A name=DR.Gamma-correction>2.7. Gamma correction</A></H3>PNG images can 
specify, via the <TT>gAMA</TT> chunk, the gamma characteristic of the image with 
respect to the original scene. Display programs are strongly encouraged to use 
this information, plus information about the display device they are using and 
room lighting, to present the image to the viewer in a way that reproduces what 
the image's original author saw as closely as possible. See <A 
href="http://www.w3.org/TR/REC-png.html#GammaAppendix">Gamma Tutorial (Chapter 
13)</A> if you aren't already familiar with gamma issues. 
<P>Gamma correction is not applied to the alpha channel, if any. Alpha samples 
always represent a linear fraction of full opacity. 
<P>For high-precision applications, the exact chromaticity of the RGB data in a 
PNG image can be specified via the <TT>cHRM</TT> chunk, allowing more accurate 
color matching than gamma correction alone will provide. See <A 
href="http://www.w3.org/TR/REC-png.html#ColorAppendix">Color Tutorial (Chapter 
14)</A> if you aren't already familiar with color representation issues. 
<P>See Rationale: <A href="http://www.w3.org/TR/REC-png.html#R.Why-gamma">Why 
gamma? (Section 12.7)</A>, Recommendations for Encoders: <A 
href="http://www.w3.org/TR/REC-png.html#E.Encoder-gamma-handling">Encoder gamma 
handling (Section 9.2)</A>, and Recommendations for Decoders: <A 
href="http://www.w3.org/TR/REC-png.html#D.Decoder-gamma-handling">Decoder gamma 
handling (Section 10.5)</A>. 
<H3><A name=DR.Text-strings>2.8. Text strings</A></H3>A PNG file can store text 
associated with the image, such as an image description or copyright notice. 
Keywords are used to indicate what each text string represents. 
<P>ISO 8859-1 (Latin-1) is the character set recommended for use in text strings 
<A href="ftp://ftp.uu.net/graphics/png/documents/">[ISO-8859]</A>. This 
character set is a superset of 7-bit ASCII. 
<P>Character codes not defined in Latin-1 should not be used, because they have 
no platform-independent meaning. If a non-Latin-1 code does appear in a PNG text 
string, its interpretation will vary across platforms and decoders. Some systems 
might not even be able to display all the characters in Latin-1, but most modern 
systems can. 
<P>Provision is also made for the storage of compressed text. 
<P>See Rationale: <A 
href="http://www.w3.org/TR/REC-png.html#R.Text-strings">Text strings (Section 
12.10)</A>. 
<H2><A name=Structure>3. File Structure</A></H2>A PNG file consists of a PNG 
<EM>signature</EM> followed by a series of <EM>chunks</EM>. This chapter defines 
the signature and the basic properties of chunks. Individual chunk types are 
discussed in the next chapter. 
<H3><A name=PNG-file-signature>3.1. PNG file signature</A></H3>The first eight 
bytes of a PNG file always contain the following (decimal) values: <PRE>   137 80 78 71 13 10 26 10
</PRE>This signature indicates that the remainder of the file contains a single 
PNG image, consisting of a series of chunks beginning with an <TT>IHDR</TT> 
chunk and ending with an <TT>IEND</TT> chunk. 
<P>See Rationale: <A 
href="http://www.w3.org/TR/REC-png.html#R.PNG-file-signature">PNG file signature 
(Section 12.11)</A>. 
<H3><A name=Chunk-layout>3.2. Chunk layout</A></H3>Each chunk consists of four 
parts: 
<DL>
  <DT>Length 
  <DD>A 4-byte unsigned integer giving the number of bytes in the chunk's data 
  field. The length counts <STRONG>only</STRONG> the data field, 
  <STRONG>not</STRONG> itself, the chunk type code, or the CRC. Zero is a valid 
  length. Although encoders and decoders should treat the length as unsigned, 
  its value must not exceed (2^31)-1 bytes. 
  <DT>Chunk Type 
  <DD>A 4-byte chunk type code. For convenience in description and in examining 
  PNG files, type codes are restricted to consist of uppercase and lowercase 
  ASCII letters (<TT>A</TT>-<TT>Z</TT> and <TT>a</TT>-<TT>z</TT>, or 65-90 and 
  97-122 decimal). However, encoders and decoders must treat the codes as fixed 
  binary values, not character strings. For example, it would not be correct to 
  represent the type code <TT>IDAT</TT> by the EBCDIC equivalents of those 
  letters. Additional naming conventions for chunk types are discussed in the 
  next section. 
  <DT>Chunk Data 
  <DD>The data bytes appropriate to the chunk type, if any. This field can be of 
  zero length. 
  <DT>CRC 
  <DD>A 4-byte CRC (Cyclic Redundancy Check) calculated on the preceding bytes 
  in the chunk, including the chunk type code and chunk data fields, but 
  <STRONG>not</STRONG> including the length field. The CRC is always present, 
  even for chunks containing no data. See <A 
  href="http://www.w3.org/TR/REC-png.html#CRC-algorithm">CRC algorithm (Section 
  3.4)</A>. </DD></DL>
<P>The chunk data length can be any number of bytes up to the maximum; 
therefore, implementors cannot assume that chunks are aligned on any boundaries 
larger than bytes. 
<P>Chunks can appear in any order, subject to the restrictions placed on each 
chunk type. (One notable restriction is that <TT>IHDR</TT> must appear first and 
<TT>IEND</TT> must appear last; thus the <TT>IEND</TT> chunk serves as an 
end-of-file marker.) Multiple chunks of the same type can appear, but only if 
specifically permitted for that type. 
<P>See Rationale: <A 
href="http://www.w3.org/TR/REC-png.html#R.Chunk-layout">Chunk layout (Section 
12.12)</A>. 
<H3><A name=Chunk-naming-conventions>3.3. Chunk naming conventions</A></H3>Chunk 
type codes are assigned so that a decoder can determine some properties of a 
chunk even when it does not recognize the type code. These rules are intended to 
allow safe, flexible extension of the PNG format, by allowing a decoder to 
decide what to do when it encounters an unknown chunk. The naming rules are not 
normally of interest when the decoder does recognize the chunk's type. 
<P>Four bits of the type code, namely bit 5 (value 32) of each byte, are used to 
convey chunk properties. This choice means that a human can read off the 
assigned properties according to whether each letter of the type code is 
uppercase (bit 5 is 0) or lowercase (bit 5 is 1). However, decoders should test 
the properties of an unknown chunk by numerically testing the specified bits; 
testing whether a character is uppercase or lowercase is inefficient, and even 
incorrect if a locale-specific case definition is used. 
<P>It is worth noting that the property bits are an inherent part of the chunk 
name, and hence are fixed for any chunk type. Thus, <TT>TEXT</TT> and 
<TT>Text</TT> would be unrelated chunk type codes, not the same chunk with 
different properties. Decoders must recognize type codes by a simple four-byte 
literal comparison; it is incorrect to perform case conversion on type codes. 
<P>The semantics of the property bits are: 
<DL>
  <DT>Ancillary bit: bit 5 of first byte 
  <DD>0 (uppercase) = critical, 1 (lowercase) = ancillary. 
  <P>Chunks that are not strictly necessary in order to meaningfully display the 
  contents of the file are known as "ancillary" chunks. A decoder encountering 
  an unknown chunk in which the ancillary bit is 1 can safely ignore the chunk 
  and proceed to display the image. The time chunk (<TT>tIME</TT>) is an example 
  of an ancillary chunk. 
  <P>Chunks that are necessary for successful display of the file's contents are 
  called "critical" chunks. A decoder encountering an unknown chunk in which the 
  ancillary bit is 0 must indicate to the user that the image contains 
  information it cannot safely interpret. The image header chunk (<TT>IHDR</TT>) 
  is an example of a critical chunk. 
  <P></P>
  <DT>Private bit: bit 5 of second byte 
  <DD>0 (uppercase) = public, 1 (lowercase) = private. 
  <P>A public chunk is one that is part of the PNG specification or is 
  registered in the list of PNG special-purpose public chunk types. Applications 
  can also define private (unregistered) chunks for their own purposes. The 
  names of private chunks must have a lowercase second letter, while public 
  chunks will always be assigned names with uppercase second letters. Note that 
  decoders do not need to test the private-chunk property bit, since it has no 
  functional significance; it is simply an administrative convenience to ensure 
  that public and private chunk names will not conflict. See <A 
  href="http://www.w3.org/TR/REC-png.html#C.Additional-chunk-types">Additional 
  chunk types (Section 4.4)</A> and Recommendations for Encoders: <A 
  href="http://www.w3.org/TR/REC-png.html#E.Use-of-private-chunks">Use of 
  private chunks (Section 9.8)</A>. 
  <P></P>
  <DT>Reserved bit: bit 5 of third byte 
  <DD>Must be 0 (uppercase) in files conforming to this version of PNG. 
  <P>The significance of the case of the third letter of the chunk name is 
  reserved for possible future expansion. At the present time all chunk names