png_specification.htm

png、jpeg的文档

  must have uppercase third letters. (Decoders should not complain about a 
  lowercase third letter, however, as some future version of the PNG 
  specification could define a meaning for this bit. It is sufficient to treat a 
  chunk with a lowercase third letter in the same way as any other unknown chunk 
  type.) 
  <P></P>
  <DT>Safe-to-copy bit: bit 5 of fourth byte 
  <DD>0 (uppercase) = unsafe to copy, 1 (lowercase) = safe to copy. 
  <P>This property bit is not of interest to pure decoders, but it is needed by 
  PNG editors (programs that modify PNG files). This bit defines the proper 
  handling of unrecognized chunks in a file that is being modified. 
  <P>If a chunk's safe-to-copy bit is 1, the chunk may be copied to a modified 
  PNG file whether or not the software recognizes the chunk type, and regardless 
  of the extent of the file modifications. 
  <P>If a chunk's safe-to-copy bit is 0, it indicates that the chunk depends on 
  the image data. If the program has made <EM>any</EM> changes to 
  <EM>critical</EM> chunks, including addition, modification, deletion, or 
  reordering of critical chunks, then unrecognized unsafe chunks must 
  <STRONG>not</STRONG> be copied to the output PNG file. (Of course, if the 
  program <STRONG>does</STRONG> recognize the chunk, it can choose to output an 
  appropriately modified version.) 
  <P>A PNG editor is always allowed to copy all unrecognized chunks if it has 
  only added, deleted, modified, or reordered <EM>ancillary</EM> chunks. This 
  implies that it is not permissible for ancillary chunks to depend on other 
  ancillary chunks. 
  <P>PNG editors that do not recognize a <EM>critical</EM> chunk must report an 
  error and refuse to process that PNG file at all. The safe/unsafe mechanism is 
  intended for use with ancillary chunks. The safe-to-copy bit will always be 0 
  for critical chunks. 
  <P>Rules for PNG editors are discussed further in <A 
  href="http://www.w3.org/TR/REC-png.html#Ordering">Chunk Ordering Rules 
  (Chapter 7)</A>. </P></DD></DL>
<P>For example, the hypothetical chunk type name "<TT>bLOb</TT>" has the 
property bits: <PRE>   bLOb  &lt;-- 32 bit chunk type code 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)
</PRE>Therefore, this name represents an ancillary, public, safe-to-copy chunk. 
<P>See Rationale: <A 
href="http://www.w3.org/TR/REC-png.html#R.Chunk-naming-conventions">Chunk naming 
conventions (Section 12.13)</A>. 
<H3><A name=CRC-algorithm>3.4. CRC algorithm</A></H3>Chunk CRCs are calculated 
using standard CRC methods with pre and post conditioning, as defined by ISO 
3309 [ISO-3309] or ITU-T V.42 [ITU-V42]. The CRC polynomial employed is <PRE>   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
</PRE>The 32-bit CRC register is initialized to all 1's, and then the data from 
each byte is processed from the least significant bit (1) to the most 
significant bit (128). After all the data bytes are processed, the CRC register 
is inverted (its ones complement is taken). This value is transmitted (stored in 
the file) MSB first. For the purpose of separating into bytes and ordering, the 
least significant bit of the 32-bit CRC is defined to be the coefficient of the 
<TT>x^31</TT> term. 
<P>Practical calculation of the CRC always employs a precalculated table to 
greatly accelerate the computation. See <A 
href="http://www.w3.org/TR/REC-png.html#CRCAppendix">Sample CRC Code (Chapter 
15)</A>. 
<H2><A name=Chunks>4. Chunk Specifications</A></H2>This chapter defines the 
standard types of PNG chunks. 
<H3><A name=C.Critical-chunks>4.1. Critical chunks</A></H3>All implementations 
must understand and successfully render the standard critical chunks. A valid 
PNG image must contain an <TT>IHDR</TT> chunk, one or more <TT>IDAT</TT> chunks, 
and an <TT>IEND</TT> chunk. 
<H4><A name=C.IHDR>4.1.1. <TT>IHDR </TT>Image header</A></H4>The <TT>IHDR</TT> 
chunk must appear FIRST. It contains: <PRE>   Width:              4 bytes
   Height:             4 bytes
   Bit depth:          1 byte
   Color type:         1 byte
   Compression method: 1 byte
   Filter method:      1 byte
   Interlace method:   1 byte
</PRE>Width and height give the image dimensions in pixels. They are 4-byte 
integers. Zero is an invalid value. The maximum for each is (2^31)-1 in order to 
accommodate languages that have difficulty with unsigned 4-byte values. 
<P>Bit depth is a single-byte integer giving the number of bits per sample or 
per palette index (not per pixel). Valid values are 1, 2, 4, 8, and 16, although 
not all values are allowed for all color types. 
<P>Color type is a single-byte integer that describes the interpretation of the 
image data. Color type codes represent sums of the following values: 1 (palette 
used), 2 (color used), and 4 (alpha channel used). Valid values are 0, 2, 3, 4, 
and 6. 
<P>Bit depth restrictions for each color type are imposed to simplify 
implementations and to prohibit combinations that do not compress well. Decoders 
must support all legal combinations of bit depth and color type. The allowed 
combinations are: <PRE>   Color    Allowed    Interpretation
   Type    Bit Depths
   
   0       1,2,4,8,16  Each pixel is a grayscale sample.
   
   2       8,16        Each pixel is an R,G,B triple.
   
   3       1,2,4,8     Each pixel is a palette index;
                       a PLTE chunk must appear.
   
   4       8,16        Each pixel is a grayscale sample,
                       followed by an alpha sample.
   
   6       8,16        Each pixel is an R,G,B triple,
                       followed by an alpha sample.
</PRE>The sample depth is the same as the bit depth except in the case of color 
type 3, in which the sample depth is always 8 bits. 
<P>Compression method is a single-byte integer that indicates the method used to 
compress the image data. At present, only compression method 0 (deflate/inflate 
compression with a 32K sliding window) is defined. All standard PNG images must 
be compressed with this scheme. The compression method field is provided for 
possible future expansion or proprietary variants. Decoders must check this byte 
and report an error if it holds an unrecognized code. See <A 
href="http://www.w3.org/TR/REC-png.html#Compression">Deflate/Inflate Compression 
(Chapter 5)</A> for details. 
<P>Filter method is a single-byte integer that indicates the preprocessing 
method applied to the image data before compression. At present, only filter 
method 0 (adaptive filtering with five basic filter types) is defined. As with 
the compression method field, decoders must check this byte and report an error 
if it holds an unrecognized code. See <A 
href="http://www.w3.org/TR/REC-png.html#Filters">Filter Algorithms (Chapter 
6)</A> for details. 
<P>Interlace method is a single-byte integer that indicates the transmission 
order of the image data. Two values are currently defined: 0 (no interlace) or 1 
(Adam7 interlace). See <A 
href="http://www.w3.org/TR/REC-png.html#DR.Interlaced-data-order">Interlaced 
data order (Section 2.6)</A> for details. 
<H4><A name=C.PLTE>4.1.2. <TT>PLTE </TT>Palette</A></H4>The <TT>PLTE</TT> chunk 
contains from 1 to 256 palette entries, each a three-byte series of the form: <PRE>   Red:   1 byte (0 = black, 255 = red)
   Green: 1 byte (0 = black, 255 = green)
   Blue:  1 byte (0 = black, 255 = blue)
</PRE>The number of entries is determined from the chunk length. A chunk length 
not divisible by 3 is an error. 
<P>This chunk must appear for color type 3, and can appear for color types 2 and 
6; it must not appear for color types 0 and 4. If this chunk does appear, it 
must precede the first <TT>IDAT</TT> chunk. There must not be more than one 
<TT>PLTE</TT> chunk. 
<P>For color type 3 (indexed color), the <TT>PLTE</TT> chunk is required. The 
first entry in <TT>PLTE</TT> is referenced by pixel value 0, the second by pixel 
value 1, etc. The number of palette entries must not exceed the range that can 
be represented in the image bit depth (for example, 2^4 = 16 for a bit depth of 
4). It is permissible to have fewer entries than the bit depth would allow. In 
that case, any out-of-range pixel value found in the image data is an error. 
<P>For color types 2 and 6 (truecolor and truecolor with alpha), the 
<TT>PLTE</TT> chunk is optional. If present, it provides a suggested set of from 
1 to 256 colors to which the truecolor image can be quantized if the viewer 
cannot display truecolor directly. If <TT>PLTE</TT> is not present, such a 
viewer will need to select colors on its own, but it is often preferable for 
this to be done once by the encoder. (See Recommendations for Encoders: <A 
href="http://www.w3.org/TR/REC-png.html#E.Suggested-palettes">Suggested 
palettes, Section 9.5</A>.) 
<P>Note that the palette uses 8 bits (1 byte) per sample 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. 
<P>There is no requirement that the palette entries all be used by the image, 
nor that they all be different. 
<H4><A name=C.IDAT>4.1.3. <TT>IDAT </TT>Image data</A></H4>The <TT>IDAT</TT> 
chunk contains the actual image data. To create this data: 
<OL>
  <LI>Begin with image scanlines represented as described in <A 
  href="http://www.w3.org/TR/REC-png.html#DR.Image-layout">Image layout (Section 
  2.3)</A>; the layout and total size of this raw data are determined by the 
  fields of <TT>IHDR</TT>. 
  <LI>Filter the image data according to the filtering method specified by the 
  <TT>IHDR</TT> chunk. (Note that with filter method 0, the only one currently 
  defined, this implies prepending a filter type byte to each scanline.) 
  <LI>Compress the filtered data using the compression method specified by the 
  <TT>IHDR</TT> chunk. </LI></OL>The <TT>IDAT</TT> chunk contains the output 
datastream of the compression algorithm. 
<P>To read the image data, reverse this process. 
<P>There can be multiple <TT>IDAT</TT> chunks; if so, they must appear 
consecutively with no other intervening chunks. The compressed datastream is 
then the concatenation of the contents of all the <TT>IDAT</TT> chunks. The 
encoder can divide the compressed datastream into <TT>IDAT</TT> chunks however 
it wishes. (Multiple <TT>IDAT</TT> chunks are allowed so that encoders can work 
in a fixed amount of memory; typically the chunk size will correspond to the 
encoder's buffer size.) It is important to emphasize that <TT>IDAT</TT> chunk 
boundaries have no semantic significance and can occur at any point in the 
compressed datastream. A PNG file in which each <TT>IDAT</TT> chunk contains 
only one data byte is legal, though remarkably wasteful of space. (For that 
matter, zero-length <TT>IDAT</TT> chunks are legal, though even more wasteful.) 
<P>See <A href="http://www.w3.org/TR/REC-png.html#Filters">Filter Algorithms 
(Chapter 6)</A> and <A 
href="http://www.w3.org/TR/REC-png.html#Compression">Deflate/Inflate Compression 
(Chapter 5)</A> for details. 
<H4><A name=C.IEND>4.1.4. <TT>IEND </TT>Image trailer</A></H4>The <TT>IEND</TT> 
chunk must appear LAST. It marks the end of the PNG datastream. The chunk's data 
field is empty. 
<H3><A name=C.Ancillary-chunks>4.2. Ancillary chunks</A></H3>All ancillary 
chunks are optional, in the sense that encoders need not write them and decoders 
can ignore them. However, encoders are encouraged to write the standard 
ancillary chunks when the information is available, and decoders are encouraged 
to interpret these chunks when appropriate and feasible. 
<P>The standard ancillary chunks are listed in alphabetical order. This is not 
necessarily the order in which they would appear in a file. 
<H4><A name=C.bKGD>4.2.1. <TT>bKGD </TT>Background color</A></H4>The 
<TT>bKGD</TT> chunk specifies a default background color to present the image 
against. Note that viewers are not bound to honor this chunk; a viewer can 
choose to use a different background. 
<P>For color type 3 (indexed color), the <TT>bKGD</TT> chunk contains: <PRE>   Palette index:  1 byte
</PRE>The value is the palette index of the color to be used as background. 
<P>For color types 0 and 4 (grayscale, with or without alpha), <TT>bKGD</TT> 
contains: <PRE>   Gray:  2 bytes, range 0 .. (2^bitdepth)-1
</PRE>(For consistency, 2 bytes are used regardless of the image bit depth.) The 
value is the gray level to be used as background. 
<P>For color types 2 and 6 (truecolor, with or without alpha), <TT>bKGD</TT> 
contains: <PRE>   Red:   2 bytes, range 0 .. (2^bitdepth)-1
   Green: 2 bytes, range 0 .. (2^bitdepth)-1
   Blue:  2 bytes, range 0 .. (2^bitdepth)-1
</PRE>(For consistency, 2 bytes per sample are used regardless of the image bit 
depth.) This is the RGB color to be used as background. 
<P>When present, the <TT>bKGD</TT> chunk must precede the first <TT>IDAT</TT> 
chunk, and must follow the <TT>PLTE</TT> chunk, if any. 
<P>See Recommendations for Decoders: <A 
href="http://www.w3.org/TR/REC-png.html#D.Background-color">Background color 
(Section 10.7)</A>. 
<H4><A name=C.cHRM>4.2.2. <TT>cHRM </TT>Primary chromaticities and white 
point</A></H4>Applications that need device-independent specification of colors 
in a PNG file can use the <TT>cHRM</TT> chunk to specify the 1931 CIE 
<EM>x,y</EM> chromaticities of the red, green, and blue primaries used in the 
image, and the referenced white point. See <A