png_specification.htm

png、jpeg的文档

    Background color</A> 
    <LI><A 
    href="http://www.w3.org/TR/REC-png.html#D.Alpha-channel-processing">10.8. 
    Alpha channel processing</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#D.Progressive-display">10.9. 
    Progressive display</A> 
    <LI><A 
    href="http://www.w3.org/TR/REC-png.html#D.Suggested-palette-and-histogram-usage">10.10. 
    Suggested-palette and histogram usage</A> 
    <LI><A 
    href="http://www.w3.org/TR/REC-png.html#D.Text-chunk-processing">10.11. Text 
    chunk processing</A> </LI></UL>
  <LI><A href="http://www.w3.org/TR/REC-png.html#Glossary">11. Glossary</A> 
  <LI><A href="http://www.w3.org/TR/REC-png.html#Rationale">12. Appendix: 
  Rationale</A> 
  <UL>
    <LI><A 
    href="http://www.w3.org/TR/REC-png.html#R.Why-a-new-file-format">12.1. Why a 
    new file format?</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#R.Why-these-features">12.2. 
    Why these features?</A> 
    <LI><A 
    href="http://www.w3.org/TR/REC-png.html#R.Why-not-these-features">12.3. Why 
    not these features?</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#R.Why-not-use-format-X">12.4. 
    Why not use format X?</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#R.Byte-order">12.5. Byte 
    order</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#R.Interlacing">12.6. 
    Interlacing</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#R.Why-gamma">12.7. Why 
    gamma?</A> 
    <LI><A 
    href="http://www.w3.org/TR/REC-png.html#R.Non-premultiplied-alpha">12.8. 
    Non-premultiplied alpha</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#R.Filtering">12.9. 
    Filtering</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#R.Text-strings">12.10. Text 
    strings</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#R.PNG-file-signature">12.11. 
    PNG file signature</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#R.Chunk-layout">12.12. Chunk 
    layout</A> 
    <LI><A 
    href="http://www.w3.org/TR/REC-png.html#R.Chunk-naming-conventions">12.13. 
    Chunk naming conventions</A> 
    <LI><A href="http://www.w3.org/TR/REC-png.html#R.Palette-histograms">12.14. 
    Palette histograms</A> </LI></UL>
  <LI><A href="http://www.w3.org/TR/REC-png.html#GammaAppendix">13. Appendix: 
  Gamma Tutorial</A> 
  <LI><A href="http://www.w3.org/TR/REC-png.html#ColorAppendix">14. Appendix: 
  Color Tutorial</A> 
  <LI><A href="http://www.w3.org/TR/REC-png.html#CRCAppendix">15. Appendix: 
  Sample CRC Code</A> 
  <LI><A href="http://www.w3.org/TR/REC-png.html#Resources">16. Appendix: Online 
  Resources</A> 
  <LI><A href="http://www.w3.org/TR/REC-png.html#History">17. Appendix: Revision 
  History</A> 
  <LI><A href="http://www.w3.org/TR/REC-png.html#References">18. References</A> 
  <LI><A href="http://www.w3.org/TR/REC-png.html#Credits">19. Credits</A> 
</LI></UL>
<H2><A name=Introduction>1. Introduction</A></H2>The PNG format provides a 
portable, legally unencumbered, well-compressed, well-specified standard for 
lossless bitmapped image files. 
<P>Although the initial motivation for developing PNG was to replace GIF, the 
design provides some useful new features not available in GIF, with minimal cost 
to developers. 
<P>GIF features retained in PNG include: 
<UL>
  <LI>Indexed-color images of up to 256 colors. 
  <LI>Streamability: files can be read and written serially, thus allowing the 
  file format to be used as a communications protocol for on-the-fly generation 
  and display of images. 
  <LI>Progressive display: a suitably prepared image file can be displayed as it 
  is received over a communications link, yielding a low-resolution image very 
  quickly followed by gradual improvement of detail. 
  <LI>Transparency: portions of the image can be marked as transparent, creating 
  the effect of a non-rectangular image. 
  <LI>Ancillary information: textual comments and other data can be stored 
  within the image file. 
  <LI>Complete hardware and platform independence. 
  <LI>Effective, 100% lossless compression. </LI></UL>Important new features of 
PNG, not available in GIF, include: 
<UL>
  <LI>Truecolor images of up to 48 bits per pixel. 
  <LI>Grayscale images of up to 16 bits per pixel. 
  <LI>Full alpha channel (general transparency masks). 
  <LI>Image gamma information, which supports automatic display of images with 
  correct brightness/contrast regardless of the machines used to originate and 
  display the image. 
  <LI>Reliable, straightforward detection of file corruption. 
  <LI>Faster initial presentation in progressive display mode. </LI></UL>PNG is 
designed to be: 
<UL>
  <LI>Simple and portable: developers should be able to implement PNG easily. 
  <LI>Legally unencumbered: to the best knowledge of the PNG authors, no 
  algorithms under legal challenge are used. (Some considerable effort has been 
  spent to verify this.) 
  <LI>Well compressed: both indexed-color and truecolor images are compressed as 
  effectively as in any other widely used lossless format, and in most cases 
  more effectively. 
  <LI>Interchangeable: any standard-conforming PNG decoder must read all 
  conforming PNG files. 
  <LI>Flexible: the format allows for future extensions and private add-ons, 
  without compromising interchangeability of basic PNG. 
  <LI>Robust: the design supports full file integrity checking as well as 
  simple, quick detection of common transmission errors. </LI></UL>
<P>The main part of this specification gives the definition of the file format 
and recommendations for encoder and decoder behavior. An appendix gives the 
rationale for many design decisions. Although the rationale is not part of the 
formal specification, reading it can help implementors understand the design. 
Cross-references in the main text point to relevant parts of the rationale. 
Additional appendixes, also not part of the formal specification, provide 
tutorials on gamma and color theory as well as other supporting material. 
<P>In this specification, the word "must" indicates a mandatory requirement, 
while "should" indicates recommended behavior. 
<P>See Rationale: <A 
href="http://www.w3.org/TR/REC-png.html#R.Why-a-new-file-format">Why a new file 
format? (Section 12.1)</A>, <A 
href="http://www.w3.org/TR/REC-png.html#R.Why-these-features">Why these 
features? (Section 12.2)</A>, <A 
href="http://www.w3.org/TR/REC-png.html#R.Why-not-these-features">Why not these 
features? (Section 12.3)</A>, <A 
href="http://www.w3.org/TR/REC-png.html#R.Why-not-use-format-X">Why not use 
format X? (Section 12.4)</A>. 
<H3>Pronunciation</H3>PNG is pronounced "ping". 
<H2><A name=DataRep>2. Data Representation</A></H2>This chapter discusses basic 
data representations used in PNG files, as well as the expected representation 
of the image data. 
<H3><A name=DR.Integers-and-byte-order>2.1. Integers and byte order</A></H3>All 
integers that require more than one byte must be in network byte order: the most 
significant byte comes first, then the less significant bytes in descending 
order of significance (MSB LSB for two-byte integers, B3 B2 B1 B0 for four-byte 
integers). The highest bit (value 128) of a byte is numbered bit 7; the lowest 
bit (value 1) is numbered bit 0. Values are unsigned unless otherwise noted. 
Values explicitly noted as signed are represented in two's complement notation. 
<P>See Rationale: <A href="http://www.w3.org/TR/REC-png.html#R.Byte-order">Byte 
order (Section 12.5)</A>. 
<H3><A name=DR.Color-values>2.2. Color values</A></H3>Colors can be represented 
by either grayscale or RGB (red, green, blue) sample data. Grayscale data 
represents luminance; RGB data represents calibrated color information (if the 
<TT>cHRM</TT> chunk is present) or uncalibrated device-dependent color (if 
<TT>cHRM</TT> is absent). All color values range from zero (representing black) 
to most intense at the maximum value for the sample depth. Note that the maximum 
value at a given sample depth is (2^sampledepth)-1, not 2^sampledepth. 
<P>Sample values are not necessarily linear; the <TT>gAMA</TT> chunk specifies 
the gamma characteristic of the source device, and viewers are strongly 
encouraged to compensate properly. See <A 
href="http://www.w3.org/TR/REC-png.html#DR.Gamma-correction">Gamma correction 
(Section 2.7)</A>. 
<P>Source data with a precision not directly supported in PNG (for example, 5 
bit/sample truecolor) must be scaled up to the next higher supported bit depth. 
This scaling is reversible with no loss of data, and it reduces the number of 
cases that decoders have to cope with. 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>. 
<H3><A name=DR.Image-layout>2.3. Image layout</A></H3>Conceptually, a PNG image 
is a rectangular pixel array, with pixels appearing left-to-right within each 
scanline, and scanlines appearing top-to-bottom. (For progressive display 
purposes, the data may actually be transmitted in a different order; see <A 
href="http://www.w3.org/TR/REC-png.html#DR.Interlaced-data-order">Interlaced 
data order, Section 2.6</A>.) The size of each pixel is determined by the 
<EM>bit depth</EM>, which is the number of bits per sample in the image data. 
<P>Three types of pixel are supported: 
<UL>
  <LI>An <EM>indexed-color</EM> pixel is represented by a single sample that is 
  an index into a supplied palette. The image bit depth determines the maximum 
  number of palette entries, but not the color precision within the palette. 
  <LI>A <EM>grayscale</EM> pixel is represented by a single sample that is a 
  grayscale level, where zero is black and the largest value for the bit depth 
  is white. 
  <LI>A <EM>truecolor</EM> pixel is represented by three samples: red (zero = 
  black, max = red) appears first, then green (zero = black, max = green), then 
  blue (zero = black, max = blue). The bit depth specifies the size of each 
  sample, not the total pixel size. </LI></UL>
<P>Optionally, grayscale and truecolor pixels can also include an alpha sample, 
as described in the next section. 
<P>Pixels are always packed into scanlines with no wasted bits between pixels. 
Pixels smaller than a byte never cross byte boundaries; they are packed into 
bytes with the leftmost pixel in the high-order bits of a byte, the rightmost in 
the low-order bits. Permitted bit depths and pixel types are restricted so that 
in all cases the packing is simple and efficient. 
<P>PNG permits multi-sample pixels only with 8- and 16-bit samples, so multiple 
samples of a single pixel are never packed into one byte. 16-bit samples are 
stored in network byte order (MSB first). 
<P>Scanlines always begin on byte boundaries. When pixels have fewer than 8 bits 
and the scanline width is not evenly divisible by the number of pixels per byte, 
the low-order bits in the last byte of each scanline are wasted. The contents of 
these wasted bits are unspecified. 
<P>An additional "filter type" byte is added to the beginning of every scanline 
(see <A href="http://www.w3.org/TR/REC-png.html#DR.Filtering">Filtering, Section 
2.5</A>). The filter type byte is not considered part of the image data, but it 
is included in the datastream sent to the compression step. 
<H3><A name=DR.Alpha-channel>2.4. Alpha channel</A></H3>An alpha channel, 
representing transparency information on a per-pixel basis, can be included in 
grayscale and truecolor PNG images. 
<P>An alpha value of zero represents full transparency, and a value of 
(2^bitdepth)-1 represents a fully opaque pixel. Intermediate values indicate 
partially transparent pixels that can be combined with a background image to 
yield a composite image. (Thus, alpha is really the degree of opacity of the 
pixel. But most people refer to alpha as providing transparency information, not 
opacity information, and we continue that custom here.) 
<P>Alpha channels can be included with images that have either 8 or 16 bits per 
sample, but not with images that have fewer than 8 bits per sample. Alpha 
samples are represented with the same bit depth used for the image samples. The 
alpha sample for each pixel is stored immediately following the grayscale or RGB 
samples of the pixel. 
<P>The color values stored for a pixel are not affected by the alpha value 
assigned to the pixel. This rule is sometimes called "unassociated" or 
"non-premultiplied" alpha. (Another common technique is to store sample values 
premultiplied by the alpha fraction; in effect, such an image is already 
composited against a black background. PNG does <EM>not</EM> use premultiplied 
alpha.)