Chapter 5. Applications: Image Converters

What may be the most useful conversion tool of all knows nothing of any image format other than PNG; it converts PNGs into other PNGs. pngcrush, by Glenn Randers-Pehrson, is a program for optimizing PNG images--specifically, for reducing their size as much as possible, although it can also perform simple housekeeping tasks such as removing or replacing specific chunks,[29] or adding gamma-correction information or simple transparency. It is an invaluable tool for use in conjunction with other converters and with commercial image editors, which may not always produce optimal PNG files.

[29] PNG's fundamental chunk structure is described in Chapter 8, "PNG Basics".

pngcrush is currently available as a command-line, shareware program in DOS and Linux x86 flavors. The DOS version works under Windows 95/98/NT and can handle long filenames; it may also run in an OS/2 DOS box, but without long-filename support. The current release, as of January 1999, is version 1.1.3 which has a home page at http://pmt.sourceforge.net/pngcrush/.

The simplest pngcrush operation is a basic ``crush'' on a single file, specifying the output filename:

pngcrush foo.png foo-crushed.png

This results in output that looks something like the following:

pngcrush 1.1.3, Copyright (C) 1998, Glenn Randers-Pehrson.
 | This program was built with libpng version 1.0.3,
 |    Copyright (c) Guy Eric Schalnat, Group 42 Inc.,
 |    Copyright (c) 1996, 1997 Andreas Dilger,
 |    Copyright (c) 1998, 1999, Glenn Randers-Pehrson,
 | and zlib version 1.1.3, Copyright (c) 1998,
 |    Jean-loup Gailly and Mark Adler.
  
   foo.png IDAT length in input file =   148723
   IDAT length with method 1 (fm 0 zl 4 zs 0)=   147533
   IDAT length with method 2 (fm 1 zl 4 zs 0)=   124710
   IDAT length with method 3 (fm 5 zl 4 zs 1)=   110589
   IDAT length with method 9 (fm 5 zl 2 zs 2)=   880073
   IDAT length with method 10 (fm 5 zl 9 zs 1)=    85820
   best pngcrush method = 10 for foo-crushed.png (42.36% reduction)
  
   overall result: 42.36% reduction, 62903 bytes

pngcrush typically tries the five or six compression approaches that are, according to its heuristics, the most likely to compress the best. This involves varying the different filter and compression settings allowed by the PNG format (described in Chapter 9, "Compression and Filtering"). If pngcrush finds a method that produces a smaller file than the original, it saves the new file with that approach. (A 42% reduction as shown in the previous output is typical only of cases in which the original file was compressed particularly poorly.) Note that pngcrush operates completely losslessly with respect to the image data; the only loss of information it intentionally allows is the explicit removal or replacement of chunks at the user's direction (though a limitation in versions of the PNG reference library prior to 1.0.6 also caused the accidental deletion of unknown, safe-to-copy chunks). We'll come back to that shortly.

pngcrush also supports a truly brute-force approach that currently tests 102 different methods but may add more in the future. This rarely improves compression by more than a tenth of a percent over the default approach, but for busy sites looking to conserve bandwidth, saving even a dozen bytes may be well worth the cost of a very lengthy--but one-time--pngcrush session. The brute-force method is invoked with the -brute option, logically enough:

pngcrush -brute foo.png foo-crushed.png

In general, a site optimizing its content will want to crush all of its PNG images (by using batch-mode conversion), and pngcrush includes two options to support batch conversion. The first allows one to specify a new extension for converted images, which will be created in the same directory as the original:

pngcrush -e -crushed.png foo.png foo2.png foo3.png foo4.png

This example crushes four images, foo.png through foo4.png, giving them the extension -crushed.png; thus the output names are foo-crushed.png, foo2-crushed.png, and so on. Such an approach is handy for casual use, since an alphabetical directory listing will (usually) list the original and crushed versions in pairs, allowing quick, after-the-fact inspection of the changes in file sizes. But because it involves renaming files, this is probably not the preferred approach for a web site. The alternative is pngcrush's -d option, which allows one to specify an output directory in which to place the crushed images:

pngcrush -d crushed_images foo.png foo2.png foo3.png foo4.png

This example crushes the same four images, but leaves their filenames unchanged. The new versions will go in the crushed_images subdirectory, which will be created if it does not already exist.

The -rem option allows one to remove PNG chunks. This is quite handy, and is often a great way to trim a few dozen bytes from files (which can make a big difference in the case of small web graphics), but it does require knowledge of PNG's chunk names. The following example removes any timestamp chunks and both compressed and uncompressed text chunks from foo.png and places the result in the crushed subdirectory:

pngcrush -d crushed -rem tIME -rem zTXt -rem tEXt -rem iTXt foo.png

Note that this approach is somewhat akin to doing surgery with a hatchet: one has no control over specific instances of the listed chunks in the case of those (like zTXt, tEXt, and iTXt) that may appear more than once. In particular, the tEXt or iTXt chunk is where copyright info usually appears, and that is usually not something one wants to remove.[30]

[30] Of course, if a copyright is also embedded in the image data itself, the text version may be superfluous.

One last option is worth a quick look. pngcrush's -g option allows one to set the gamma value of the image, which in turn provides for cross-platform consistency of the overall brightness of the image. Chapter 10, "Gamma Correction and Precision Color" covers gamma and color correction in more detail, but the effect will be familiar to any site that uses both Macintoshes and PCs: images that look good on Macs tend to look too dark on PCs, and images that look good on PCs tend to look too bright and washed out on Macs. The solution is to include information about the system on which the image was created, and PNG's gAMA chunk is the simplest and most effective means of doing so. Unfortunately, not all image editors support gamma in PNG, and as you saw in the previous chapter, some of those that do support it store the wrong value. A site that has just received a batch of PNG images from its Mac-based design department might do something like the following:

pngcrush -d crushed -replace_gamma 0.65909 mac.png mac2.png mac3.png

For images from a PC-based design group, the corresponding command is:

pngcrush -d crushed -replace_gamma 0.45455 pc.png pc2.png pc3.png

In addition to optimizing the sizes of the images, these examples strip any existing gamma information out of the files, on the assumption that the values are known to be wrong and replace it with values that are appropriate for stock Macs (with a factory-default ``system gamma'' value of 1.8) or stock PCs. If it is known that the images that have gamma information are correct, use the -g option instead; it will add a gAMA chunk only to those images that do not already have one.

I should note that pngcrush is still a relatively new utility, and it does have a number of rough edges yet. For example, if an output file already exists, it will be overwritten without warning. There is also no recursion, no support for wildcards other than what the operating system provides (i.e., only under Unix), and no way to set a default extension or directory for crushed files (say, via an environment variable). The program's extended options also assume a fairly advanced knowledge of PNG files--for example, the official names of PNG chunks, in the case of the -rem option, or the numerical color types used internally by PNG, or the precise palette index of the color to be made transparent, in the case of the -trns option.[31] Nor is there yet support for counting colors in images and automatically converting from, say, RGB to palette format, although this is planned for a future version. But these are relatively minor user interface issues that will undoubtedly improve as the application matures. As regards its primary purpose of squeezing PNG images as tightly as possible, pngcrush is quite capable, and is likely to become an indispensable addition to the toolchest of any image-wrangler.

[31] Newer versions of pngcrush will print the palette, including indices, when given both the -n (``no crush'') and -verbose options.

Possibly the most complete conversion program in existence, at least with respect to support for PNG features, is pnmtopng. In conjunction with its inverse, pngtopnm, and the rest of the NetPBM suite,[32] it is capable of handling basic conversions to and from virtually any image format. But pnmtopng really shines as a tool for adding and modifying PNG chunk information, including such things as text annotations, palette optimization, and support for adding or removing alpha (transparency) channels.

[32] NetPBM originated as the PBMplus package, last released in December 1991. Subsequent third-party contributions from the Internet were gathered together and released as NetPBM in 1993 and early 1994, containing some 200 utilities for converting and manipulating images. The package has lain dormant since then, aside from the occasional appearance of utilities to support new image formats like PNG, but further news on this front is expected in 1999.

Currently, the latest version of pnmtopng is 2.37.2, released in March 1999; it can be found on the PNG home site, http://www.libpng.org/pub/png/apps/pnmtopng.html, along with pointers to the libraries on which it depends.

Written and maintained by Alexander Lehmann and Willem van Schaik with contributions and fixes from others, pnmtopng is primarily a Unix-based tool, which unfortunately limits its usefulness to a minority of computer users. But other parts of the NetPBM suite have been ported to OS/2 and Windows, and it is likely that a future release of both pnmtopng and NetPBM will be more portable and may even include ready-to-go executables.

To begin explaining some of pnmtopng's features, it is first necessary to describe a little about the PBM format itself. If one wishes to be able to convert any of 100 possible image formats into any other, there are two options: write 10,000 individual converters to go directly from format A to format B for all possible pairs of A and B; or write only 200 converters, 100 to go from each of the image formats into some intermediate representation and another 100 to convert back from that intermediate format into the 100 target formats. Once the intermediate format exists, one need not stop at conversion programs; generic utilities to manipulate images suddenly become possible--for example, quantization, smoothing, cropping, contrast enhancement, and so on.

PBMplus/NetPBM is that intermediate format. It was originally designed by Jef Poskanzer and released as the PBMplus suite, with later ``interim'' packages released as NetPBM by Bill Davidsen. Since there has never been another PBMplus release, I will henceforth refer to the format as NetPBM, the name by which it is now most commonly known. The format is quite simple: three lines of text header--which may additionally include one or more comment lines--followed by the uncompressed image data. The image data may be stored as either text or binary values; the latter is more efficient and far more commonly used, but the existence of the text format means that one can actually create images or color palettes in an ordinary text editor. There are also three basic NetPBM image flavors: bilevel (or black and white), which is referred to as a portable bitmap or PBM file; grayscale, called a portable graymap or PGM; and truecolor (RGB), referred to as a portable pixmap or PPM file. Programs that can deal with more than one flavor usually have ``PNM'' in their names; this stands for portable anymap. There is currently no ``real'' PNM format; it is a virtual format and a convenient catchall name.

One notable feature missing from the NetPBM format is provision for alpha channels; this is a known limitation[33] with implications for converting between formats that support transparency, such as PNG, GIF, and TIFF. pnmtopng gets around this to some extent by the simple expedient of storing transparency information in a separate grayscale file. Before we get into that, let's look at some simpler cases.

[33] Alpha support is a major reason behind the expected NetPBM revisions in 1999.

pnmtopng is a command-line program, and, thanks to its Unix heritage, it is designed to operate as part of a multicommand pipeline. Unix pipes are a slick method of connecting the output of one program into the input of another; in principle there is no limit to how long such a chain can be, although in practice the amount of system resources that are available may constrain things. Here is a simple example that converts a GIF image into PNG:

Here are examples for two other popular image formats, TIFF and JPEG:

The first option is self-explanatory: the PNG image will be interlaced. For the -gamma option, we've used a value that corresponds to a typical Macintosh; we're imagining that the original image was scanned and tweaked on a Mac before being converted to PPM format (foo.ppm) on some other system. The -time option requires a little more explanation. First, note that it is distinct from the ``Creation Time'' text chunk we included; the -time option will write the special PNG tIME chunk, which represents the time the image was last modified. But the last modification time is clearly the time the image was converted into PNG format, so pnmtopng really should not require the user to specify the time information explicitly. This is particularly true, given that PNG's time chunk is supposed to be in Coordinated Universal Time, and most users are unlikely to know how to convert to that.[34] With luck, this oversight will also be corrected in the next release of the program.

[34] The example here corresponds to 1:00 p.m. in the US/Pacific time zone. But had the conversion taken place at 1:00 p.m. on the previous day, it would have been specified as 20:00:00 in Universal Time, thanks to the fact that daylight saving time had not yet ended.

Transparency is one of PNG's major strengths, so let's take a look at some of pnmtopng's options there. Suppose that we wish to vignette our treasured foo image--that is, we would like to apply an oval mask to it that gradually fades to complete transparency, in effect transforming our image from rectangular to rounded. This is easily accomplished by creating the oval mask as a grayscale (PGM) image, where white represents the regions that will be completely opaque (i.e., the main subject matter of the image) and black the outer, transparent regions. Then give the following command:

For most users, the second form is probably the most easily understood but the least precise. Making it precise requires the finely honed ability to find the X color-database file, which can be difficult when it exists and impossible when it doesn't[35] (it is also explicitly platform-dependent; that is, the same color name is allowed to have different RGB values on different machines). Therefore, the first form is likely to be the most useful. It specifies the RGB values of the background color as decimal fractions between 0.0 and 1.0. The values are separated by forward slashes (/) and prefixed by rgbi:. The third form is the old-style hexadecimal format that is favored by programmers but almost no one else. (It also happens to be the format used in the demo programs I present in Chapter 13, "Reading PNG Images" and Chapter 14, "Reading PNG Images Progressively" on reading PNG images. Oh, the embarrassment.) The hex value need not be placed in quotation marks on a command line, but within a shell script it should be quoted, or the hash character (#) will be treated as the beginning of a comment.

[35] For the record, it lives in /usr/openwin/lib/X11/rgb.txt on Sun systems, /usr/X11R6/lib/X11/rgb.txt on most Linux and FreeBSD systems, and /usr/lib/X11/rgb.txt on ``generic'' Unix/X11 systems.

Other supported features include chromaticity information, histograms, compressed text, explicit single-color transparency, physical pixel dimensions, and special compression options. Quantization of truecolor images to 256 or fewer colors is not supported by pnmtopng itself, but it is a straightforward part of the standard NetPBM package. For example, to quantize a 24-bit TIFF image to the 256 best colors, dither the result, and save it as a palette-based PNG, one can use:

For users of very large images, one other point is worth mentioning: pnmtopng currently reads the entire image into memory buffers before doing anything with it, which means that a 4000 × 4000 RGBA image would require 64 megabytes of real and/or virtual memory just for the uncompressed image itself. But all is not lost; in Chapter 15, "Writing PNG Images", I present a very simple-minded NetPBM-to-PNG converter, and one of its design goals was the ability to convert images on the fly, requiring only a very small memory footprint. (Of course, this only works if the PNG image is not interlaced.) The demo program also has a -time option that automatically records the current time in the proper format, as well as one or two other potentially handy features.

For simple batch conversion of GIF images into PNGs, pnmtopng is not only overkill but also somewhat tricky to automate. Such a task is more readily handled by gif2png, a special-purpose conversion program written by Alexander Lehmann. Besides the raw image pixels, there are three GIF features that translate directly into PNG features: transparency, text (comments), and interlacing. gif2png handles the first two automatically; only interlacing is not detected and automatically applied to the output image, although the program does include a -i option to force interlacing.

gif2png does have a few drawbacks, as might be expected given its pre-1.0 version number. In addition to the problem of overwriting existing files, gif2png's conversion of GIF transparency information is less than ideal; although it gets the job done, the program copies over the GIF palette without modification, which can result in useless transparency entries in the PNG file. For example, a 256-color GIF image whose last palette entry is the transparent one would result in a 256-entry transparency chunk in the PNG file, where one entry would suffice; in other words, it can waste up to 255 bytes in the output file. gif2png is also rather verbose and provides no option to keep it quiet; in fact, its progress meter (a simple percentage value, updated repeatedly) is supposed to be enabled only when the -p option is given, but it actually is on by default and can only be turned off with -p.

Despite all this, the program is quite stable and useful. It even converts GIF comments from IBM codepage 437 to PNG's Latin-1 format, and it will convert animated GIFs into multiple single-image PNGs. A planned option that would have automatically deleted the GIF input images after conversion was never implemented, nor was the capability of converting GIF Plain Text Extensions into PNG gIFt chunks. But these are minor issues; in fact, the gIFt chunk was officially declared Bad (that is, deprecated) in October 1998, so its lack of support in gif2png turned out to be prescient. Indeed, the only major problem with the program is the fact that it reads GIFs in the first place. It is therefore (according to Unisys) subject to the LZW patent and its associated licensing issues. Unisys initially claimed that freeware GIF programs would be granted a free LZW license, but that later changed, which was directly responsible for the cessation of further development on gif2png.

The gif2png source code and ready-to-go binaries for Linux can be found at http://www.catb.org/~esr/gif2png/. (Older binaries for DOS, OS/2, Amiga, and Macintosh may still exist elsewhere on the Web.) A graphical port written by Nigel Stewart for 32-bit Windows, called The Exorcist, supports drag and drop and is available from its own home page: http://www.nigels.com/exorcist/Exorcist.html. Version 1.1 is the latest release.

The corresponding special-purpose conversion program for TIFF images was written by Willem van Schaik and is called, predictably, Tiff2png. By a strange coincidence, its latest version is also 0.6, but the program is perhaps slightly less robust than gif2png. This is primarily due to the fact that the TIFF format is hugely complex, supporting multiple forms of text annotations, both gamma and color correction, several flavors of transparency, many different sample depths, and numerous other options that might conceivably be carried over into a PNG image with a little effort (or, more likely, a lot of it).

The program also appears not to handle Intel-format (``little-endian'': see the section entitled "Implementation" in Chapter 7, "History of the Portable Network Graphics Format") TIFF images with 16-bit samples correctly, instead storing the samples as is--which effectively means they are inverted, given that PNG samples must be stored in ``big-endian'' format. But lacking any such sample images, I was unable to verify this.

At any rate, Tiff2png is capable of converting at least some TIFF images with alpha transparency correctly, which gives it an advantage over the current NetPBM suite and pnmtopng. Although TIFF is subject to the same LZW licensing issues GIF is, it supports several other compression methods (including no compression) and is therefore less of a problem for program authors. In Tiff2png's case, all TIFF manipulations are handled via Sam Leffler's free libtiff library, which means Tiff2png itself can be updated at will without worrying about the sorts of legal issues that plagued gif2png. Source code for Tiff2png can be found on the PNG home site, http://www.libpng.org/pub/png/apps/tiff2png.html, but there are presently no prebuilt executables.

Finally, we should take a look at an extremely useful PNG utility that is not usually considered a conversion tool: pngcheck. pngcheck prints the chunks in a PNG file, along with their contents, in many cases; one can loosely think of it as a utility that ``converts PNG images to text,'' although it does so in such a way that they could never be converted back to PNG format. (In particular, it provides no way to print the actual pixel data, although it can print just about everything else.)

Originally written by Alexander Lehmann as a simple tool to check PNG images for corruption, such as might occur if the file were transferred in text mode, pngcheck was subsequently extended by Andreas Dilger, Greg Roelofs, and others, evolving into a nearly complete PNG syntax checker and content dumper. The latest versions (1.99-grr1 is current as of this writing) even include partial support for MNG files, the multi-image PNG extension described in Chapter 12, "Multiple-Image Network Graphics" (Multiple-Image Network Graphics). pngcheck is most often used to understand why a particular image is larger than expected--perhaps a 16-color image was saved in 24-bit RGB format instead of palette format, or a truecolor image was saved with minimal compression and no filtering. But it can also be used simply to test PNG files and print their dimensions, image types, and approximate compression ratios.[36]

[36] The compression ratio is computed by dividing the total file size by the nominal size of the uncompressed IDAT data, which means the presence of ancillary information or even a required palette can produce negative compression ratios--i.e., ``expansion''--in small images. In other words, don't take it too seriously.

In this example, we see a fairly basic PNG file, a truecolor image with an alpha channel, composed of only four chunk types: the required IHDR, IDAT, and IEND chunks (described in Chapter 8, "PNG Basics"), plus the optional but highly recommended gamma-correction chunk, gAMA (Chapter 10, "Gamma Correction and Precision Color"). Because the image primarily consists of solid-colored regions and simple gradients, it compressed unusually well; this probably indicates that dynamic filtering was used, but there is no way to be certain, given the preceding information.

The details are too complex to cover right now, but filtering and compression are discussed in Chapter 9, "Compression and Filtering". All that matters here is that different filters have been used for different rows in the image, indicating that some sort of dynamic filtering was applied (which is generally good). Unfiltered images, on the other hand, will have all zeros for the filter numbers, and statically filtered images will use only a single filter type. In most cases, that means the image is not compressed as well as it could be. One major exception, however, is palette-based images; they rarely respond well to filtering, and most programs don't try.

pngcheck also supports more specific types of output. Its -p option, for example, is another rather verbose case; it prints the contents of the palette and optional transparency chunks for colormapped images.[37] This can be useful in conjunction with a program such as pngcrush, for example, when one wishes to specify a particular color as transparent, but more commonly it is used to check whether the transparency chunk is full of needless opaque values. Consider the following example:

[37] It will also print the contents of the optional histogram and suggested-palette chunks; see Chapter 11, "PNG Options and Extensions", for details.

pngcheck -p foo5.png
  
File: foo5.png (146 bytes)
  PLTE chunk: 4 palette entries
    0:  (  0,255,  0) = (0x00,0xff,0x00)
    1:  (255,  0,  0) = (0xff,0x00,0x00)
    2:  (255,255,  0) = (0xff,0xff,0x00)
    3:  (  0,  0,255) = (0x00,0x00,0xff)
  tRNS chunk: 3 transparency entries
    0:  255 = 0xff
    1:  255 = 0xff
    2:    0 = 0x00
No errors detected in foo5.png (32x32, 2-bit colormap, non-interlaced,
43.0%).

Here we have a four-color image: bright green, red, yellow, and blue. The colors of the palette are listed as RGB triplets in both decimal and hexadecimal (base 16) for convenience. The palette itself is unremarkable; what is more interesting is the transparency chunk, tRNS. It includes three entries, but the first two have the value 255, which indicates that the corresponding palette entries should be treated as completely opaque. But all palette entries are considered opaque unless explicitly given a non-opaque transparency value--in other words, any transparency entries with the value 255 are redundant and represent wasted space. In this case, the only non-opaque entry corresponds to the third color, yellow; a smart PNG-writing program would have reordered the palette so that yellow was the first entry, thus shaving two bytes off the file. It is not uncommon to be able to save 100 or more bytes in this manner, which can represent 10% to 20% of the file size for small web graphics.[38] In rare cases, it may be worthwhile to waste a few transparency entries so that the most common pixels in the image are all at the beginning of the palette (i.e., so they all have index values near zero); with filtering enabled, the compression engine may be able to make up the difference and then some. But as of early 1999, filtering has yet to be demonstrated effective on essentially any kind of palette-based image, so the possibility of recovering wasted transparency entries with improved compression is a rather tenuous one.

[38] One of the images used on the VRML98 web site had 211 transparency entries, of which 210 were unnecessary.

The latest version of pngcheck can be found at the PNG home site, http://www.libpng.org/pub/png/apps/pngcheck.html.

The converters we've discussed so far barely scratch the surface of what is available. If one includes image editors and viewers that can convert images in addition to dedicated conversion tools, there are well over one hundred applications capable of converting to and from the PNG format.[38b] Many of these were listed in the previous two chapters and are well worth considering, particularly for users who may be uncomfortable dealing with command-line programs.

Here is a list of some of the other dedicated (or nearly dedicated) image converters that support PNG. The most recent version as of January 1999 is given wherever possible.

ColourEdit

Version of April 3, 1997, Julian Highfield. Available as an OpenDoc part for Mac 68k/PPC (mostly tested with OpenDoc 1.1 and Mac OS System 7.1.2); read/write support for PNGs.

http://www.stile.lboro.ac.uk/~cojch/ColourEdit/

Creator

Version 3.22, John Kortink. Available for Acorn RISC OS; read/write support for PNGs; no alpha or gamma support.

http://web.inter.nl.net/users/J.Kortink/indexsw.htm

dicom2

Version 1.8, Sébastien Barré. Available for Windows 9x/NT, Linux x86, SunOS/Solaris SPARC; write-only support for PNGs; supports conversion of 12-bit medical formats to 16-bit grayscale PNGs.

http://www.hds.utc.fr/~barre/medical/dicom2/

Ghostscript

Version 5.50, Aladdin Enterprises. Available for Unix, VMS, OS/2, Windows 9x/NT, and Mac 68k/PPC; older versions available for Windows 3.x, DOS, Amiga, Atari, and possibly Acorn RISC OS; write-only support for PNGs.

http://www.cs.wisc.edu/~ghost/

gj2png

Version of February 13, 1997, Neil Aggarwal. Available for any platform supporting Java 1.1 or later; write-only support for PNGs.

http://www.anet-dfw.com/~neil/gjFrame.html

Icons Control 95

Version 7.02, Chris Doan. Available for Windows 9x/NT; read-only support for PNGs (converts various image formats to Windows .ico format).

http://members.aol.com/doanc/icnctrl.html

Image Arithmetic

Version 2.2a, Richard van Paasen. Available for Windows 9x/NT; read/write support for PNGs.

http://huizen.dds.nl/~buddha/imgart.html

LatinByrd

Version III v6, Stefan Schneider Software. Available for NeXTStep/OpenStep on 68k/x86/HP-PA/SPARC; write-only support for PNGs; can quantize 32-bit RGBA TIFF images to 8-bit RGBA-palette PNGs.

http://members.ping.at/stefan/LatinByrdProductInfo.html

PicCon

Version 2.50, Morten Eriksen. Available for Amiga; read-only; requires a PNG datatype such as those from Cloanto or Andreas Kleinert.

http://www.aminet.org/pub/aminet/gfx/conv/PicCon250.lha
http://www.aminet.org/pub/aminet/util/dtype/PNG_dt.lha
http://www.aminet.org/pub/aminet/util/dtype/akPNG-dt.lha
http://home.t-online.de/home/Andreas_Kleinert/support.htm

PNG-Box

Version 3.25, Andreas Kleinert. Available for Amiga 68k/PPC; write-only support for PNGs; supports interlacing and single-color transparency. PNG-Box is a graphical ``any to PNG'' conversion utility that uses Andreas's own SuperView Library for its image support instead of datatypes.

http://www.amigaworld.com/support/png-box/
http://home.t-online.de/home/Andreas_Kleinert/support.htm
http://www.aminet.org/pub/aminet/gfx/conv/PNG-Box.lha

!Png2Spr

Version 1.14, Tom Tanner. Available for Acorn RISC OS; read-only support for PNGs (converts to Acorn sprite format).

http://www.argonet.co.uk/users/ttehtann/

ptot

Version of March 10, 1995, Lee Daniel Crocker. Available as portable source code (does not require libpng or zlib); read-only support for PNGs (converts to TIFF); full gamma support (writes TIFF TransferFunction tag); full alpha support for true alpha channels (no palette-alpha or ``cheap transparency'' support).

ftp://swrinde.nde.swri.edu/pub/png/applications/ptot.tar.gz

SmartSaver

Version 3.0, Ulead Systems. Available for 32-bit Windows; read/write support for PNGs; full alpha support, including at least single-color palette transparency (not clear whether full RGBA-palette translucency is supported); reportedly cannot write 1-bit (bilevel) images.

http://www.webutilities.com/ssaver/noslip.htm

Spr2Png

Version 0.04b, Darren Salt. Available for Acorn RISC OS; write-only support for PNGs; full alpha support via secondary sprite that is used as a transparency mask or alpha channel; supports interlacing and background color. An older version was reported to produce streaks in conversions of newer (post-RPC) sprites, but this appears to be fixed in the current release.

http://www.youmustbejoking.demon.co.uk/progs.html#spr2png

ThumbNailer

Version 5.2, Smaller Animals Software. Available for 32-bit Windows; read/write support for PNGs; supports transparency, background color, and text; claims full gamma support.

http://www.smalleranimals.com/thumb.htm

Ultraconv

Version 3.0p1, Felix Schwarz. Available for Amiga 68k/PPC; read/write support for PNGs (natively since version 1.6, or via a datatype for earlier versions); no alpha or gamma support.

http://home.pages.de/~uconv/

New conversion utilities and updated information on the ones listed here can be found at the Image-Conversion Applications with PNG Support web page at the PNG home site, http://www.libpng.org/pub/png/pngapcv.html. This URL is expected to be stable for years, but of course there are no guarantees on the World Wide Web! Use a search engine to look for the title string or for one of the more oddly named utilities listed if the link should ever break.