png_specification.htm

png、jpeg的文档

href="http://www.w3.org/TR/REC-png.html#ColorAppendix">Color Tutorial (Chapter 
14)</A> for more information. 
<P>The <TT>cHRM</TT> chunk contains: <PRE>   White Point x: 4 bytes
   White Point y: 4 bytes
   Red x:         4 bytes
   Red y:         4 bytes
   Green x:       4 bytes
   Green y:       4 bytes
   Blue x:        4 bytes
   Blue y:        4 bytes
</PRE>Each value is encoded as a 4-byte unsigned integer, representing the 
<EM>x</EM> or <EM>y</EM> value times 100000. For example, a value of 0.3127 
would be stored as the integer 31270. 
<P><TT>cHRM</TT> is allowed in all PNG files, although it is of little value for 
grayscale images. 
<P>If the encoder does not know the chromaticity values, it should not write a 
<TT>cHRM</TT> chunk; the absence of a <TT>cHRM</TT> chunk indicates that the 
image's primary colors are device-dependent. 
<P>If the <TT>cHRM</TT> chunk appears, it must precede the first <TT>IDAT</TT> 
chunk, and it must also precede the <TT>PLTE</TT> chunk if present. 
<P>See Recommendations for Encoders: <A 
href="http://www.w3.org/TR/REC-png.html#E.Encoder-color-handling">Encoder color 
handling (Section 9.3)</A>, and Recommendations for Decoders: <A 
href="http://www.w3.org/TR/REC-png.html#D.Decoder-color-handling">Decoder color 
handling (Section 10.6)</A>. 
<H4><A name=C.gAMA>4.2.3. <TT>gAMA </TT>Image gamma</A></H4>The <TT>gAMA</TT> 
chunk specifies the gamma of the camera (or simulated camera) that produced the 
image, and thus the gamma of the image with respect to the original scene. More 
precisely, the <TT>gAMA</TT> chunk encodes the file_gamma value, as defined in 
<A href="http://www.w3.org/TR/REC-png.html#GammaAppendix">Gamma Tutorial 
(Chapter 13)</A>. 
<P>The <TT>gAMA</TT> chunk contains: <PRE>   Image gamma: 4 bytes
</PRE>The value is encoded as a 4-byte unsigned integer, representing gamma 
times 100000. For example, a gamma of 0.45 would be stored as the integer 45000. 

<P>If the encoder does not know the image's gamma value, it should not write a 
<TT>gAMA</TT> chunk; the absence of a <TT>gAMA</TT> chunk indicates that the 
gamma is unknown. 
<P>If the <TT>gAMA</TT> chunk appears, it must precede the first <TT>IDAT</TT> 
chunk, and it must also precede the <TT>PLTE</TT> chunk if present. 
<P>See <A href="http://www.w3.org/TR/REC-png.html#DR.Gamma-correction">Gamma 
correction (Section 2.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>. 
<H4><A name=C.hIST>4.2.4. <TT>hIST </TT>Image histogram</A></H4>The 
<TT>hIST</TT> chunk gives the approximate usage frequency of each color in the 
color palette. A histogram chunk can appear only when a palette chunk appears. 
If a viewer is unable to provide all the colors listed in the palette, the 
histogram may help it decide how to choose a subset of the colors for display. 
<P>The <TT>hIST</TT> chunk contains a series of 2-byte (16 bit) unsigned 
integers. There must be exactly one entry for each entry in the <TT>PLTE</TT> 
chunk. Each entry is proportional to the fraction of pixels in the image that 
have that palette index; the exact scale factor is chosen by the encoder. 
<P>Histogram entries are approximate, with the exception that a zero entry 
specifies that the corresponding palette entry is not used at all in the image. 
It is required that a histogram entry be nonzero if there are any pixels of that 
color. 
<P>When the palette is a suggested quantization of a truecolor image, the 
histogram is necessarily approximate, since a decoder may map pixels to palette 
entries differently than the encoder did. In this situation, zero entries should 
not appear. 
<P>The <TT>hIST</TT> chunk, if it appears, must follow the <TT>PLTE</TT> chunk, 
and must precede the first <TT>IDAT</TT> chunk. 
<P>See Rationale: <A 
href="http://www.w3.org/TR/REC-png.html#R.Palette-histograms">Palette histograms 
(Section 12.14)</A>, and Recommendations for Decoders: <A 
href="http://www.w3.org/TR/REC-png.html#D.Suggested-palette-and-histogram-usage">Suggested-palette 
and histogram usage (Section 10.10)</A>. 
<H4><A name=C.pHYs>4.2.5. <TT>pHYs </TT>Physical pixel dimensions</A></H4>The 
<TT>pHYs</TT> chunk specifies the intended pixel size or aspect ratio for 
display of the image. It contains: <PRE>   Pixels per unit, X axis: 4 bytes (unsigned integer)
   Pixels per unit, Y axis: 4 bytes (unsigned integer)
   Unit specifier:          1 byte
</PRE>The following values are legal for the unit specifier: <PRE>   0: unit is unknown
   1: unit is the meter
</PRE>When the unit specifier is 0, the <TT>pHYs</TT> chunk defines pixel aspect 
ratio only; the actual size of the pixels remains unspecified. 
<P>Conversion note: one inch is equal to exactly 0.0254 meters. 
<P>If this ancillary chunk is not present, pixels are assumed to be square, and 
the physical size of each pixel is unknown. 
<P>If present, this chunk must precede the first <TT>IDAT</TT> chunk. 
<P>See Recommendations for Decoders: <A 
href="http://www.w3.org/TR/REC-png.html#D.Pixel-dimensions">Pixel dimensions 
(Section 10.2)</A>. 
<H4><A name=C.sBIT>4.2.6. <TT>sBIT </TT>Significant bits</A></H4>To simplify 
decoders, PNG specifies that only certain sample depths can be used, and further 
specifies that sample values should be scaled to the full range of possible 
values at the sample depth. However, the <TT>sBIT</TT> chunk is provided in 
order to store the original number of significant bits. This allows decoders to 
recover the original data losslessly even if the data had a sample depth not 
directly supported by PNG. We recommend that an encoder emit an <TT>sBIT</TT> 
chunk if it has converted the data from a lower sample depth. 
<P>For color type 0 (grayscale), the <TT>sBIT</TT> chunk contains a single byte, 
indicating the number of bits that were significant in the source data. 
<P>For color type 2 (truecolor), the <TT>sBIT</TT> chunk contains three bytes, 
indicating the number of bits that were significant in the source data for the 
red, green, and blue channels, respectively. 
<P>For color type 3 (indexed color), the <TT>sBIT</TT> chunk contains three 
bytes, indicating the number of bits that were significant in the source data 
for the red, green, and blue components of the palette entries, respectively. 
<P>For color type 4 (grayscale with alpha channel), the <TT>sBIT</TT> chunk 
contains two bytes, indicating the number of bits that were significant in the 
source grayscale data and the source alpha data, respectively. 
<P>For color type 6 (truecolor with alpha channel), the <TT>sBIT</TT> chunk 
contains four bytes, indicating the number of bits that were significant in the 
source data for the red, green, blue and alpha channels, respectively. 
<P>Each depth specified in <TT>sBIT</TT> must be greater than zero and less than 
or equal to the sample depth (which is 8 for indexed-color images, and the bit 
depth given in <TT>IHDR</TT> for other color types). 
<P>A decoder need not pay attention to <TT>sBIT</TT>: the stored image is a 
valid PNG file of the sample depth indicated by <TT>IHDR</TT>. However, if the 
decoder wishes to recover the original data at its original precision, this can 
be done by right-shifting the stored samples (the stored palette entries, for an 
indexed-color image). The encoder must scale the data in such a way that the 
high-order bits match the original data. 
<P>If the <TT>sBIT</TT> chunk appears, it must precede the first <TT>IDAT</TT> 
chunk, and it must also precede the <TT>PLTE</TT> chunk if present. 
<P>See Recommendations for Encoders: <A 
href="http://www.w3.org/TR/REC-png.html#E.Sample-depth-scaling">Sample depth 
scaling (Section 9.1)</A> and Recommendations for Decoders: <A 
href="http://www.w3.org/TR/REC-png.html#D.Sample-depth-rescaling">Sample depth 
rescaling (Section 10.4)</A>. 
<H4><A name=C.tEXt>4.2.7. <TT>tEXt </TT>Textual data</A></H4>Textual information 
that the encoder wishes to record with the image can be stored in <TT>tEXt</TT> 
chunks. Each <TT>tEXt</TT> chunk contains a keyword and a text string, in the 
format: <PRE>   Keyword:        1-79 bytes (character string)
   Null separator: 1 byte
   Text:           n bytes (character string)
</PRE>The keyword and text string are separated by a zero byte (null character). 
Neither the keyword nor the text string can contain a null character. Note that 
the text string is <EM>not</EM> null-terminated (the length of the chunk is 
sufficient information to locate the ending). The keyword must be at least one 
character and less than 80 characters long. The text string can be of any length 
from zero bytes up to the maximum permissible chunk size less the length of the 
keyword and separator. 
<P>Any number of <TT>tEXt</TT> chunks can appear, and more than one with the 
same keyword is permissible. 
<P>The keyword indicates the type of information represented by the text string. 
The following keywords are predefined and should be used where appropriate: <PRE>   Title            Short (one line) title or caption for image
   Author           Name of image's creator
   Description      Description of image (possibly long)
   Copyright        Copyright notice
   Creation Time    Time of original image creation
   Software         Software used to create the image
   Disclaimer       Legal disclaimer
   Warning          Warning of nature of content
   Source           Device used to create the image
   Comment          Miscellaneous comment; conversion from
                    GIF comment
</PRE>For the Creation Time keyword, the date format defined in section 5.2.14 
of RFC 1123 is suggested, but not required <A 
href="ftp://ds.internic.net/rfc/rfc1123.txt">[RFC-1123]</A>. Decoders should 
allow for free-format text associated with this or any other keyword. 
<P>Other keywords may be invented for other purposes. Keywords of general 
interest can be registered with the maintainers of the PNG specification. 
However, it is also permitted to use private unregistered keywords. (Private 
keywords should be reasonably self-explanatory, in order to minimize the chance 
that the same keyword will be used for incompatible purposes by different 
people.) 
<P>Both keyword and text are interpreted according to the ISO 8859-1 (Latin-1) 
character set <A href="ftp://ftp.uu.net/graphics/png/documents/">[ISO-8859]</A>. 
The text string can contain any Latin-1 character. Newlines in the text string 
should be represented by a single linefeed character (decimal 10); use of other 
control characters in the text is discouraged. 
<P>Keywords must contain only printable Latin-1 characters and spaces; that is, 
only character codes 32-126 and 161-255 decimal are allowed. To reduce the 
chances for human misreading of a keyword, leading and trailing spaces are 
forbidden, as are consecutive spaces. Note also that the non-breaking space 
(code 160) is not permitted in keywords, since it is visually indistinguishable 
from an ordinary space. 
<P>Keywords must be spelled exactly as registered, so that decoders can use 
simple literal comparisons when looking for particular keywords. In particular, 
keywords are considered case-sensitive. 
<P>See Recommendations for Encoders: <A 
href="http://www.w3.org/TR/REC-png.html#E.Text-chunk-processing">Text chunk 
processing (Section 9.7)</A> and Recommendations for Decoders: <A 
href="http://www.w3.org/TR/REC-png.html#D.Text-chunk-processing">Text chunk 
processing (Section 10.11)</A>. 
<H4><A name=C.tIME>4.2.8. <TT>tIME </TT>Image last-modification time</A></H4>The 
<TT>tIME</TT> chunk gives the time of the last image modification (<EM>not</EM> 
the time of initial image creation). It contains: <PRE>   Year:   2 bytes (complete; for example, 1995, <EM>not</EM> 95)
   Month:  1 byte (1-12)
   Day:    1 byte (1-31)
   Hour:   1 byte (0-23)
   Minute: 1 byte (0-59)
   Second: 1 byte (0-60)    (yes, 60, for leap seconds; not 61,
                             a common error)
</PRE>Universal Time (UTC, also called GMT) should be specified rather than 
local time. 
<P>The <TT>tIME</TT> chunk is intended for use as an automatically-applied time 
stamp that is updated whenever the image data is changed. It is recommended that 
<TT>tIME</TT> not be changed by PNG editors that do not change the image data. 
See also the Creation Time <TT>tEXt</TT> keyword, which can be used for a 
user-supplied time. 
<H4><A name=C.tRNS>4.2.9. <TT>tRNS </TT>Transparency</A></H4>The <TT>tRNS</TT> 
chunk specifies that the image uses simple transparency: either alpha values 
associated with palette entries (for indexed-color images) or a single 
transparent color (for grayscale and truecolor images). Although simple 
transparency is not as elegant as the full alpha channel, it requires less 
storage space and is sufficient for many common cases. 
<P>For color type 3 (indexed color), the <TT>tRNS</TT> chunk contains a series 
of one-byte alpha values, corresponding to entries in the <TT>PLTE</TT> chunk: <PRE>   Alpha for palette index 0:  1 byte
   Alpha for palette index 1:  1 byte
   ... etc ...
</PRE>Each entry indicates that pixels of the corresponding palette index must 
be treated as having the specified alpha value. Alpha values have the same 
interpretation as in an 8-bit full alpha channel: 0 is fully transparent, 255 is 
fully opaque, regardless of image bit depth. The <TT>tRNS</TT> chunk must not 
contain more alpha values than