Getting started with png

Remarks#

Portable Network Graphics is a raster graphics file format that supports lossless data compression. PNG was created as an improved, non-patented replacement for Graphics Interchange Format (GIF) and is the most widely used lossless image compression format on the Internet.

PNG supports palette-based images (24-bit RGB or 32-bit RGBA colors), grayscale images (with or without alpha channel), and full-color, non-paletted RGB[A] images with an optional alpha channel. PNG was designed for transferring images on the Internet, not for professional-quality print graphics, and does not support non-RGB color spaces such as CMYK.

PNG files nearly always use file extension PNG or png and are assigned MIME media type image/png. PNG was approved for use by the Internet Engineering Steering Group on 14 October 1996, and was published as an ISO/IEC standard in 2004.

For image editing, either professional or otherwise, PNG provides a useful format for the storage of intermediate stages of editing. PNG compression is fully lossless and supports up to 48-bit truecolor or 16-bit grayscal. Therefore saving, restoring, and re-saving an image will not degrade its quality unlike standard JPEG (even at highest quality JPEG settings). Unlike TIFF, the PNG specification leaves no room for implementors to pick and choose what features to support; 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. JPEG’s lossy compression can introduce visible artifacts, but these can be minimized and the savings in file size even at high quality levels are much better than generally possible with a lossless format like PNG. 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.

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.

Versions#

png

libpng version 1.6.21

Libpng was written as a companion to PNG specification as a way of reducing the amount of time and effort it takes to support the PNG file format in application programs.

Libpng was designed to handle multiple sessions at one time, to be easily modifiable, to be portable to the vast majority of machines (ANSI, K&R, 16-, 32-, and 64-bit) available, and to be easy to use. The ultimate goal is to promote acceptance of PNG format in whatever way possible. While there is still work to be done (see the TODO file), libpng should cover the majority of user needs.

User limits:

PNG specification allows the width and height of an image to be as large as 2^31-1 (0x7fffffff), or about 2.147 billion rows and columns. For safety libpng imposes a default limit of 1 million rows and columns. Larger images will be rejected immediately with a png_error() call. Libpng may reject very wide images because of potential buffer overflow conditions, but you can set your own limits with:

png_set_user_limits(png_ptr, width_max, height_max);

Put this statement after creating the PNG structure and before calling png_read_info(), png_read_png(), or png_process_data().

When writing a PNG datastream, put this statement before calling png_write_info() or png_write_png().

To retrieve the limits that are being applied, use

width_max = png_get_user_width_max(png_ptr);
height_max = png_get_user_height_max(png_ptr);

The PNG specification sets no limit on the number of ancillary chunks allowed in a PNG datastream. By default libpng imposes a limit of a total of 1000 sPLT, tEXt, iTXt, zTXt, and unknown chunks to be stored. IF both info_ptr and end_info_ptr are set, the limit applies separately to each. Change the limit on the total number of such chunks to be stored with:

png_set_chunk_cache_max(png_ptr, user_chunk_cache_max);

where 0x7fffffffL means unlimited. You can retrieve this limit with:

chunk_cache_max = png_get_chunk_cache_max(png_ptr);

Libpng imposes a limit of 8 Megabytes (8,000,000 bytes) on the amount of memory that a compressed chunk other than IDAT can occupy, when decompressed. You can change this limit with:

png_set_chunk_malloc_max(png_ptr, user_chunk_malloc_max);

and you can retrieve the limit with:

chunk_malloc_max = png_get_chunk_malloc_max(png_ptr);

Any chunks that would cause either of these limits to be exceeded will be ignored.

Detecting libpng version:

The png_get_io_ptr() function has been present since libpng-0.88, has never changed, and is unaffected by conditional compilation macros. It is the best choice for use in configure scripts for detecting the presence of any libpng version since 0.88. In an autoconf “configure.in” you could use

AC_CHECK_LIB(png, png_get_io_ptr, ...