Post by Santosh Puthran on Nov 13, 2005 21:08:39 GMT
Typical Usage
The Portable Network Graphics (PNG) format was designed to replace the older and simpler GIF format and, to some extent, the much more complex TIFF format. (See the main page or the history page for background information.) Here we'll concentrate on two major uses: the World Wide Web (WWW) and image-editing.
For the Web, PNG really has three main advantages over GIF: alpha channels (variable transparency), gamma correction (cross-platform control of image brightness), and two-dimensional interlacing (a method of progressive display). PNG also compresses better than GIF in almost every case, but the difference is generally only around 5% to 25%, not a large enough factor to encourage folks to switch on that basis alone. One GIF feature that PNG does not try to reproduce is multiple-image support, especially animations; PNG was and is intended to be a single-image format only. (A very PNG-like extension format called MNG was finalized in mid-1999 and is beginning to be supported by various applications, but MNGs and PNGs will have different file extensions and different purposes.)
For image editing, either professional or otherwise, PNG provides a useful format for the storage of intermediate stages of editing. Since PNG's compression is fully lossless--and since it supports up to 48-bit truecolor or 16-bit grayscale--saving, restoring and re-saving an image will not degrade its quality, unlike standard JPEG (even at its highest quality settings). And unlike TIFF, the PNG specification leaves no room for implementors to pick and choose what features they'll support; the result is that a PNG image saved in one app is readable in any other PNG-supporting application. (Note that for transmission of finished truecolor images--especially photographic ones--JPEG is almost always a better choice. Although JPEG's lossy compression can introduce visible artifacts, these can be minimized, and the savings in file size even at high quality levels is much better than is generally possible with a lossless format like PNG. And for black-and-white images, particularly of text or drawings, TIFF's Group 4 fax compression or the JBIG format are often far better than 1-bit grayscale PNG.)
Compression
PNG's compression is among the best that can be had without losing image information and without paying patent fees, but not all implementations take full advantage of the available power. Even those that do can be thwarted by unwise choices on the part of the user.
PNG supports three main image types: truecolor, grayscale and palette-based ("8-bit"). JPEG only supports the first two; GIF only the third (although it can fake grayscale by using a gray palette). The impact on compression comes from the ability to mix up image types in PNG. Specifically, forcing an application to save an 8-bit palette image as a 24-bit truecolor (or "RGB") image is not going to result in a small file. This may be unavoidable if the original has been modified to include more than 256 colors (for example, if a continuous gradient background has been added), but many images intended for the Web have 256 or fewer colors.
On the programmer's side, one common mistake is to include too many palette entries in a PNG image. This error is most noticeable when converting tiny GIF images (bullets, buttons, etc.) to PNG format; these images are typically only 1000 bytes or so in size, and storing 256 three-byte palette entries where only 50 are needed would result in over 600 bytes of wasted space.
Another common programmer mistake is to use only one type of compression filter, or to vary them incorrectly. Compression filters are described below and can make a dramatic difference in the compressibility of the image. In general this is not a feature that users should be forced to experiment with.
Finally, the low-level compression engine itself can be tweaked to compress either better or faster. Often "best compression" is the preferred setting, but an implementor may choose to use an intermediate level of compression in order to boost the interactive performance for the user. Usually the difference in file size is small, but there are cases where such a choice can make a big difference.
See the zlib home page for further details on PNG's compression engine and the CRC-32 algorithm, the 7-Zip home page for an alternative implementation of the deflate algorithm, and Vince Sabio's Compression Primer for an overview of compression in general. For tools to optimize the compression of PNG images, see the converters page (especially Glenn Randers-Pehrson's pngcrush and Ulead's SmartSaver).
www.libpng.org/pub/png/
The Portable Network Graphics (PNG) format was designed to replace the older and simpler GIF format and, to some extent, the much more complex TIFF format. (See the main page or the history page for background information.) Here we'll concentrate on two major uses: the World Wide Web (WWW) and image-editing.
For the Web, PNG really has three main advantages over GIF: alpha channels (variable transparency), gamma correction (cross-platform control of image brightness), and two-dimensional interlacing (a method of progressive display). PNG also compresses better than GIF in almost every case, but the difference is generally only around 5% to 25%, not a large enough factor to encourage folks to switch on that basis alone. One GIF feature that PNG does not try to reproduce is multiple-image support, especially animations; PNG was and is intended to be a single-image format only. (A very PNG-like extension format called MNG was finalized in mid-1999 and is beginning to be supported by various applications, but MNGs and PNGs will have different file extensions and different purposes.)
For image editing, either professional or otherwise, PNG provides a useful format for the storage of intermediate stages of editing. Since PNG's compression is fully lossless--and since it supports up to 48-bit truecolor or 16-bit grayscale--saving, restoring and re-saving an image will not degrade its quality, unlike standard JPEG (even at its highest quality settings). And unlike TIFF, the PNG specification leaves no room for implementors to pick and choose what features they'll support; the result is that a PNG image saved in one app is readable in any other PNG-supporting application. (Note that for transmission of finished truecolor images--especially photographic ones--JPEG is almost always a better choice. Although JPEG's lossy compression can introduce visible artifacts, these can be minimized, and the savings in file size even at high quality levels is much better than is generally possible with a lossless format like PNG. And for black-and-white images, particularly of text or drawings, TIFF's Group 4 fax compression or the JBIG format are often far better than 1-bit grayscale PNG.)
Compression
PNG's compression is among the best that can be had without losing image information and without paying patent fees, but not all implementations take full advantage of the available power. Even those that do can be thwarted by unwise choices on the part of the user.
PNG supports three main image types: truecolor, grayscale and palette-based ("8-bit"). JPEG only supports the first two; GIF only the third (although it can fake grayscale by using a gray palette). The impact on compression comes from the ability to mix up image types in PNG. Specifically, forcing an application to save an 8-bit palette image as a 24-bit truecolor (or "RGB") image is not going to result in a small file. This may be unavoidable if the original has been modified to include more than 256 colors (for example, if a continuous gradient background has been added), but many images intended for the Web have 256 or fewer colors.
On the programmer's side, one common mistake is to include too many palette entries in a PNG image. This error is most noticeable when converting tiny GIF images (bullets, buttons, etc.) to PNG format; these images are typically only 1000 bytes or so in size, and storing 256 three-byte palette entries where only 50 are needed would result in over 600 bytes of wasted space.
Another common programmer mistake is to use only one type of compression filter, or to vary them incorrectly. Compression filters are described below and can make a dramatic difference in the compressibility of the image. In general this is not a feature that users should be forced to experiment with.
Finally, the low-level compression engine itself can be tweaked to compress either better or faster. Often "best compression" is the preferred setting, but an implementor may choose to use an intermediate level of compression in order to boost the interactive performance for the user. Usually the difference in file size is small, but there are cases where such a choice can make a big difference.
See the zlib home page for further details on PNG's compression engine and the CRC-32 algorithm, the 7-Zip home page for an alternative implementation of the deflate algorithm, and Vince Sabio's Compression Primer for an overview of compression in general. For tools to optimize the compression of PNG images, see the converters page (especially Glenn Randers-Pehrson's pngcrush and Ulead's SmartSaver).
www.libpng.org/pub/png/
