Jump to content

PNG: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Idioma-bot (talk | contribs)
m robot Modifying: fa:پی‌ان‌جی
added a link to a sample of the technique
Line 224: Line 224:
The fact that Internet Explorer 4.0–6.0 did not support alpha-channel transparency has led some people to erroneously believe that Internet Explorer ≤6 does not support transparency at all. However, colormapped (palette) PNGs can be given a single transparent background color, which works on IE and is equivalent to the transparency available with GIF images. (In the [[GIMP]], suitable PNGs can be generated or converted by setting the Mode to 'Indexed' rather than 'RGB'.)
The fact that Internet Explorer 4.0–6.0 did not support alpha-channel transparency has led some people to erroneously believe that Internet Explorer ≤6 does not support transparency at all. However, colormapped (palette) PNGs can be given a single transparent background color, which works on IE and is equivalent to the transparency available with GIF images. (In the [[GIMP]], suitable PNGs can be generated or converted by setting the Mode to 'Indexed' rather than 'RGB'.)


There are also a number of methods using [[DirectX]] functions in style sheets and HTML that can make Internet Explorer ≤6 display full transparency data in PNG images on web pages.
There are also a number of methods using [[DirectX]] functions in [http://www.drunkenfist.com/304/2006/10/20/cross-browser-png-transparency/ style sheets and HTML] that can make Internet Explorer ≤6 display full transparency data in PNG images on web pages.


Internet Explorer ≤6 also renders PNGs in a slightly incorrect color [[gamut]]. If a GIF and PNG image of several colors are placed side-by-side on a page, a user can often see a slight difference in color. This is due to an incorrect handling of the [[Portable Network Graphics#Ancillary_chunks|gAMA ancillary chunk]]. Tools exist to get rid of these chunks, including gAMA (usually for image size gains), and some PNG re-compressors such as [[PNGOUT]] or [http://psydk.org/PngOptimizer.php PNG Optimizer] automatically remove the gAMA chunk if not explicitly asked to keep it. Others such as [[pngcrush]] will remove it upon request.
Internet Explorer ≤6 also renders PNGs in a slightly incorrect color [[gamut]]. If a GIF and PNG image of several colors are placed side-by-side on a page, a user can often see a slight difference in color. This is due to an incorrect handling of the [[Portable Network Graphics#Ancillary_chunks|gAMA ancillary chunk]]. Tools exist to get rid of these chunks, including gAMA (usually for image size gains), and some PNG re-compressors such as [[PNGOUT]] or [http://psydk.org/PngOptimizer.php PNG Optimizer] automatically remove the gAMA chunk if not explicitly asked to keep it. Others such as [[pngcrush]] will remove it upon request.

Revision as of 19:05, 12 November 2007

Portable Network Graphics

A PNG image with an 8-bit transparency channel (top). The same image is overlaid onto a checkered background (bottom), typically used with graphics software to denote the transparency.
Filename extension
.png
Internet media type
image/png
Type codePNGf
Uniform Type Identifier (UTI)public.png
Developed byPNG Development Group (donated to W3C)
Type of formatlossless bitmap image format
Extended toAPNG, JNG and MNG
StandardISO 15948, IETF RFC 2083

Portable Network Graphics (PNG) is a bitmapped image format that employs lossless data compression. PNG was created to improve upon and replace the GIF format, as an image-file format not requiring a patent license. PNG is pronounced "ping" (/pɪŋ/ in IPA).[1]

PNG supports palette-based (palettes of 24-bit RGB colors) or greyscale or RGB images. PNG was designed for transferring images on the Internet, not professional graphics, and so does not support other color spaces (such as CMYK).

PNG files nearly always use file-extension "PNG" or "png" and are assigned MIME media type "image/png" (approved October 14 1996).

History and development

The motivation for creating the PNG format came in early 1995 when it came to light that the LZW data compression algorithm used in the GIF format had been patented by Unisys. The acronym PNG is optionally recursive, unofficially standing for “PNG's Not GIF”.[2] For more on this controversy see GIF (Unisys and LZW patent enforcement). There were also other problems with the GIF format which made a replacement desirable, notably its limitation to 256 colors at a time when computers capable of displaying far more than 256 colors were becoming common. Although GIF allows for animation, it was decided that PNG should be a single-image format. A companion format called MNG has been defined for animation.

  • 1996-10-01 – Version 1.0 of the PNG specification was released, and later appeared as RFC 2083. It became a W3C Recommendation on 1996-10-01.
  • 1998-12-31 – Version 1.1, with some small changes and the addition of three new chunks, was released.
  • 1999-08-11 – Version 1.2, adding one extra chunk, was released.
  • 2003-11-10 – PNG is now an International Standard (ISO/IEC 15948:2003). This version of PNG differs only slightly from version 1.2 and adds no new chunks.
  • 2004-03-03ISO/IEC 15948:2004.

Technical details

File header

A PNG file starts with an 8-byte signature. The hexadecimal byte values are 89 50 4E 47 0D 0A 1A 0A. Each of the header bytes is there for a specific reason:[3]

Byte(s) Purpose
89 Has the high bit set to detect transmission systems that do not support 8 bit data and to reduce the chance that a text file is mistakenly interpreted as a PNG, or vice versa.
50 4E 47 In ASCII, the letters "PNG", allowing a person to identify the format easily if it is viewed in a text editor.
0D 0A A DOS style line ending (CRLF) to detect DOS-UNIX line ending conversion of the data.
1A A byte that stops display of the file under DOS when the command type has been used – the end-of-file character
0A A UNIX style line ending (LF) to detect UNIX-DOS line ending conversion.

"Chunks" within the file

After the header come a series of chunks, each of which conveys certain information about the image. Chunks declare themselves as critical or ancillary, and a program encountering an ancillary chunk that it does not understand can safely ignore it. This chunk-based structure is designed to allow the PNG format to be extended while maintaining compatibility with older versions.

The chunks each have a header specifying their size and type. This is immediately followed by the actual data, and then the checksum of the data. Chunks are given a 4 letter case sensitive ascii name. The case of the different letters in the name (bit 5 of the numeric value of the character) provides the decoder with some information on the nature of chunks it does not recognize.

The case of the first letter indicates if the chunk is critical or not. If the first letter is uppercase, the chunk is critical; if not, the chunk is ancillary. Critical chunks contain information that is necessary to read the file. If a decoder encounters a critical chunk it does not recognize, it must abort reading the file or supply the user with an appropriate warning.

The case of the second letter indicates if the chunk is "public" (either in the specification or the registry of special purpose public chunks) or "private" (not standardised). Uppercase is public and lowercase is private. This ensures that public and private chunk names can never conflict with each other (although two private chunk names could conflict).

The third letter must be uppercase to conform to the PNG specification. It is reserved for future expansion. Decoders should treat a chunk with a lower case third letter the same as any other unrecognised chunk.

The case of the fourth letter indicates if a chunk is safe to copy by editors that do not recognize it. If lowercase, the chunk may be safely copied regardless of the extent of modifications to the file. If uppercase, it may only be copied if the modifications have not touched any critical chunks.

Critical chunks

A decoder must be able to interpret these to read and render a PNG file.

  • IHDR must be the first chunk, it contains the header.
  • PLTE contains the palette; list of colors.
  • IDAT contains the image, which may be split among multiple IDAT chunks. Doing so increases filesize slightly, but makes it possible to generate a PNG in a streaming manner.
  • IEND marks the image end.

The PLTE chunk is essential for color type 3 (indexed color). It is optional for color types 2 and 6 (truecolor and truecolor with alpha) and it must not appear for color types 0 and 4 (greyscale and greyscale with alpha).

Ancillary chunks

Other image attributes that can be stored in PNG files include gamma values, background color, and textual metadata information. PNG also supports color management through the inclusion of ICC color space profiles.

  • bKGD gives the default background color. It is intended for use when there is no better choice available, such as in standalone image viewers (but not web browsers, although Internet Explorer 6 and lower, which does not support alpha transparency, will display this color as the background of the PNG).
  • cHRM gives the white balance.
  • gAMA specifies gamma.
  • hIST can store the histogram, or total amount of each color in the image.
  • iCCP is an ICC color profile.
  • iTXt contains UTF-8 text, compressed or not, with an optional language tag.
  • pHYs holds the intended pixel size and/or aspect ratio of the image.
  • sBIT (significant bits) indicates the color-accuracy of the source data.
  • sPLT suggests a palette to use if the full range of colors is unavailable.
  • sRGB indicates that the standard sRGB color space is used.
  • tEXt can store text that can be represented in ISO 8859-1, with one name=value pair for each chunk.
  • tIME stores the time that the image was last changed.
  • tRNS contains transparency information. For indexed images, it stores alpha channel values for one or more palette entries. For truecolor and greyscale images, it stores a single pixel value that is to be regarded as fully transparent.
  • zTXt contains compressed text with the same limits as tEXt.

The lowercase first letter in these chunks indicates that they are not needed for the PNG specification. The lowercase last letter in some chunks indicates that they are safe to copy, even if the application concerned does not understand them.

Color depth

PNG images can either use palette-indexed color or be made up of one or more channels (numerical values directly representing quantities about the pixels). When there is more than one channel in an image all channels have the same number of bits allocated per pixel (known as the bitdepth of the channel). Although the PNG specification always talks about the bitdepth of channels, most software and users generally talk about the total number of bits per pixel (sometimes also referred to as bitdepth or color depth).

The number of channels will depend on whether the image is greyscale or color and whether it has an alpha channel. PNG allows the following combinations of channels:

  • indexed (channel containing indexes into a palette of colors)
  • greyscale
  • greyscale and alpha (level of transparency for each pixel)
  • red, green and blue (rgb/truecolor)
  • red, green, blue and alpha
PNG color options, cell values are total bits per pixel for that combination
Type Bit depth per channel
1 2 4 8 16
indexed (color type 3) 1 2 4 8 No
greyscale (color type 0) 1 2 4 8 16
greyscale & alpha
(color type 4)
No No No 16 32
truecolor
(RGB: color type 2)
No No No 24 48
truecolor & alpha
(RGBA: color type 6)
No No No 32 64

With indexed color images, the palette is always stored in RGB at a depth of 8 bits per channel (24 bits per palette entry). The palette must not have more entries than the image bitdepth allows for but it may have fewer (so if an image for example only uses 90 colors there is no need to have palette entries for all 256).

Indexed color PNGs are allowed to have 1, 2, 4 or 8 bits per pixel by the standard; greyscale images with no alpha channel allow for 1, 2, 4, 8 or 16 bits per pixel. Everything else uses a bitdepth per channel of either 8 or 16. The combinations this allows are given in the table above. The standard requires that decoders can read all supported color formats but many image editors can only produce a small subset of them.

Transparency of image

PNG offers a variety of transparency options. With truecolor and greyscale images either a single pixel value can be declared as transparent or an alpha channel can be added. For paletted images, alpha values can be added to palette entries. The number of such values stored may be less than the total number of palette entries, in which case the remaining entries are considered fully opaque.

The scanning of pixel values for binary transparency is supposed to be performed before any color reduction to avoid pixels becoming unintentionally transparent. This is most likely to pose an issue for systems that can decode 16 bits per channel images (as they must be compliant with the specification) but only output at 8 bits per channel (the norm for all but the highest end systems).

Compression

PNG uses a non-patented lossless data compression method known as deflate (zlib/gzlib). This method is combined with prediction, where for each image line, a filter method is chosen that predicts the color of each pixel based on the colors of previous pixels and subtracts the predicted color of the pixel from the actual color. An image line filtered in this way is often more compressible than the raw image line would be, especially if it is similar to the line above (since deflate has no understanding that an image is a 2D entity, and instead just sees the image data as a stream of bytes).

Interlacing

PNG offers an optional 2-dimensional, 7-pass interlacing scheme – the Adam7 algorithm. This is more sophisticated than GIF's 1-dimensional, 4-pass scheme, and allows a clearer low-resolution image to be visible earlier in the transfer. However, as a 7-pass scheme, it tends to reduce the data's compressibility more than simpler schemes.

Animation

PNG itself does not support animation. MNG is an extension to PNG that does; it was designed by members of the same group that created PNG. MNG shares PNG's basic structure and chunks, but it is significantly more complex and has a different file signature, which automatically renders it incompatible with standard PNG decoders.

The complexity of MNG lead to the proposal of APNG by developers of the Mozilla Foundation. It is based on PNG, supports animation and is simpler than MNG. APNG offers fallback to single-image display for PNG decoders that do not support APNG. However, neither of these formats is currently widely supported. APNG is supported in development builds of Firefox 3.0 and Opera 9.5 test versions[4]. The PNG Group decided in April 2007 not to embrace APNG. Several alternatives are under discussion, ANG, aNIM/mPNG, PNG in GIF and its subset RGBA in GIF.[5]

Comparison with other file formats

Comparison with GIF

  • On most images, PNG can achieve greater compression than GIF (see the section on filesize, below).
  • PNG gives a much wider range of transparency options than GIF, including alpha-channel transparency.
  • PNG gives a much wider range of color depths than GIF (truecolor up to 48-bit compared to 8-bit 256-color), allowing for greater color precision, smoother fades, etc.[6]
  • GIF supports animation while PNG does not (see the section on animation, above).
  • PNG images are widely supported, but not as widely supported as GIF images.

Comparison with JPEG

Composite image comparing JPEG and PNG: notice artifacts in JPEG versus solid PNG background.

JPEG can produce a smaller file than PNG for photographic (and photo-like) images since it uses a lossy encoding method specifically designed for photographic image data. Using PNG instead of a high-quality JPEG for such images would result in a large increase in filesize (often 5–10 times) with negligible gain in quality.

PNG is a better choice than JPEG for storing images that contain text, line art, or other images with sharp transitions. Where an image contains both sharp transitions and photographic parts a choice must be made between the large but sharp PNG and a small JPEG with artifacts around sharp transitions. JPEG also does not support transparency.

JPEG is a poor choice for storing images that require further editing as it suffers from generation loss, whereas lossless formats do not. This makes PNG useful for saving temporary photographs that require successive editing. When the photograph is ready to be distributed, it can then be saved as a JPEG, and this limits the information loss to just one generation. That said, PNG does not support Exif image data from sources such as digital cameras, which makes it problematic for use amongst amateur and especially professional photographers. TIFF does support it as a lossless format.

JPEG has historically been the format of choice for exporting images containing gradients, as it could handle the color depth much better than the GIF format. However, any compression by the JPEG would cause the gradient to become blurry, but a 24-bit PNG export of a gradient image often comes out identical to the source vector image, and at a small file size. As such, the PNG format is the optimal choice for exporting small, repeating gradients for web usage.

Comparison with TIFF

TIFF is a complicated format that incorporates an extremely wide range of options. While this makes TIFF useful as a generic format for interchange between professional image editing applications, it makes adding support for it to applications a much bigger task and so it has little support in applications not concerned with image manipulation (such as web browsers). It also means that many applications can read only a subset of TIFF types, creating more potential user confusion.

The most common general-purpose, lossless compression algorithm used with TIFF is LZW, which is inferior to PNG and, until expiration in 2003, suffered from the same patent issues that GIF did. There is a TIFF variant that uses the same compression algorithm as PNG uses, but it is not supported by many proprietary programs. TIFF also offers special-purpose lossless compression algorithms like CCITT Group IV, which can compress bilevel images (e.g., faxes or black-and-white text) better than PNG's compression algorithm.

Software support

Bitmap graphics editor support for PNG

Adobe Fireworks (formerly by Macromedia) uses PNG as its native file format, allowing other image editors and preview utilities to view the flattened image. However, Fireworks by default also stores meta data for layers, animation, vector data, text and effects. Such files should not be distributed directly. Fireworks can instead export the image as an optimized PNG without the extra meta data for use on web pages, etc.[7]

Other popular graphics programs which support the PNG format include Inkscape, Xara, Adobe Photoshop, Corel PaintShop Pro, The GIMP, Pixel image editor, Helicon Filter, Paint.NET and GraphicConverter. Some programs bundled with popular operating systems which support PNG include Microsoft's Paint and Apple's iPhoto and Preview.

Some image processing programs have PNG compression problems, mainly related to lack of full implementation of the PNG compressor library:

  • Microsoft's Paint for Windows XP
  • Microsoft Picture It! Photo Premium 9
  • older versions of Adobe Photoshop.

Adobe's Fireworks is sometimes placed in this category, but its difficulties are less severe than the other entries. The confusion stems from a misunderstanding of the mechanics of its Save format: though PNGs, the intermediate images produced by that option include large, private chunks containing complete layer and vector information, which allows further, lossless editing. Properly saved with the Export option, Fireworks' PNGs are competitive with those produced by other image editors, but are no longer editable as anything but flattened bitmaps. Fireworks is unable to save size-optimized vector-editable PNGs.

Web browser support for PNG

Despite tools such as gif2png, influential writers, calls by the Free Software Foundation, and even more extreme campaigns such as "burn all gifs", PNG adoption on websites has been fairly slow.

GIF is still more widely used than PNG, partially due to misconceptions but also for several more accurate reasons:

The full feature set of PNG is not often used on the web, for several reasons:

  • Internet Explorer 4 can crash on images containing metadata (e.g., Adobe Fireworks's native PNG file format)
  • Versions of Internet Explorer up to and including 6 do not support native alpha-channel transparency (although a JavaScript fix is possible for clients using IE 5.5 to 6).

The fact that Internet Explorer 4.0–6.0 did not support alpha-channel transparency has led some people to erroneously believe that Internet Explorer ≤6 does not support transparency at all. However, colormapped (palette) PNGs can be given a single transparent background color, which works on IE and is equivalent to the transparency available with GIF images. (In the GIMP, suitable PNGs can be generated or converted by setting the Mode to 'Indexed' rather than 'RGB'.)

There are also a number of methods using DirectX functions in style sheets and HTML that can make Internet Explorer ≤6 display full transparency data in PNG images on web pages.

Internet Explorer ≤6 also renders PNGs in a slightly incorrect color gamut. If a GIF and PNG image of several colors are placed side-by-side on a page, a user can often see a slight difference in color. This is due to an incorrect handling of the gAMA ancillary chunk. Tools exist to get rid of these chunks, including gAMA (usually for image size gains), and some PNG re-compressors such as PNGOUT or PNG Optimizer automatically remove the gAMA chunk if not explicitly asked to keep it. Others such as pngcrush will remove it upon request.

Internet Explorer 7 has addressed the transparency-rendering issues, though not the gamma- and color-correction errors [1].

Apple's Safari, Mozilla Firefox, and Opera have full PNG compatibility. For the complete comparison, see Comparison of web browsers (Image format support).

There is an open source solution to display transparent PNGs in IE, Firefox, and Safari without the use of filters, PHP, or complicated Javascript and CSS – PNGPong. The solution uses a combination of Javascript, Flash, and simple DHTML.

Windows Vista icon support for PNG

Microsoft Windows Vista uses PNG compression in order to allow zoomable icons while still using reasonable filesizes for the icons by associating each icon with a PNG file [2].

File size and optimization software

File:PNGOUT plugin.png
Screenshots of the Save Options for the PNGOUT plugin which is included in the IrfanView image converter. The screenshots show the default settings.

Generally, PNG files without unnecessary metadata should have a smaller file size than the identical image encoded in GIF format. PNG gives the image creator far more flexibility than GIF, but care must be taken to avoid PNG files that are needlessly large.

As GIF is limited to 256 colors, many image editors will automatically reduce the color depth when saving an image in GIF format. Often when people save the same truecolor image as PNG and GIF, they see that the GIF is smaller, and do not realise it is possible to create a 256 color PNG that has identical quality to the GIF with a smaller file size. This leads to the misconception that PNG files are larger than equivalent GIF files.

In practice, well optimized and compressed PNG files are usually much smaller than GIF files (10 % to 50 % savings) for filesizes above about 100 bytes.

Some versions of Adobe Photoshop, CorelDRAW and MS Paint provide poor PNG compression effort, further fueling the idea that PNG is larger than GIF. Many graphics programs (such as Apple's Preview software) save PNGs with large amounts of metadata and color-correction data that are generally unnecessary for Web viewing. Unoptimized PNG files from Adobe Fireworks are also notorious for this.

It should be noted that Adobe Photoshop's performance on PNG files has been much improved in the CS Suite when using the Save For Web feature (which also allows explicit PNG/8 use).

Various tools are available for optimizing PNG files. OptiPNG and pngcrush are both open-source software optimizers that run from a Unix command line or a Windows Command Prompt, and effectively reduce the size of PNG files. The littleutils is another open-source package that contains a wrapper script called opt-png. This script utilizes pngcrush and a variant of pngrewrite to reduce bit-depth when possible, reducing PNG file sizes further. Perl scripts might wish to employ Image-Pngslimmer which allows some dynamic optimization.

Other tools such as AdvanceCOMP and Ken Silverman's PNGOUT are capable of reducing the file size even further still, giving the competent user the smallest file size possible for a given PNG image. The current version of IrfanView can use PNGOUT as an external plug-in, and the screenshots show PNGOUT's save options.

pngcrush and PNGOUT have the extra ability to remove all color correction data from PNG files (gamma, white balance, ICC color profile, standard RGB color profile). This often results in much smaller file sizes. The following command line options achieve this with pngcrush:

pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB InputFile.png OutputFile.png

PNG was not intended to replace the other popular web image format JPEG. See the Comparison with JPEG section above for more details on how the two formats compare.

References

See also

External links

libpng.org

W3C

Others

Internet Explorer incompatibility