As I mentioned at the beginning of Chapter 13, "Reading PNG Images", libpng is not the only option for adding PNG support to an application. There are numerous other possibilities, particularly for the Windows platforms; a number of these use libpng themselves.
In the next two sections, I list roughly two dozen PNG-supporting libraries and toolkits, with particular emphasis on those with the greatest cross-platform support or support for some of the less common platforms. For an up-to-date list of PNG toolkits and related code, please check the Toolkits web page and the Source Code and Libraries page at the PNG home site:
Note that I have not personally tested any of the libraries or toolkits listed here.
John Cristy's ImageMagick is a C library that provides a uniform interface to a few dozen image formats. It not only includes a standard C API but also has Perl and Python interfaces. It also provides several powerful utilities, including an X-based viewer called display, for which it is probably better known. ImageMagick is freely available in source and binary formats for Unix, VMS, Macintosh, and 32-bit Windows platforms, albeit without the display and animate tools on the Mac. (An X server is required for those two programs on the other platforms.) It uses libpng and zlib for PNG support and may be modified and distributed freely as long as its copyright is acknowledged.
Colosseum Builders' Image Library is a C++ library that supports reading and writing PNGs, JPEGs, and several other image formats. The distribution includes demo apps for encoding, decoding, and viewing images, the accompanying documentation indicates that the library is an alpha release. Also, much of the code is described at length in The Programmer's Guide to Compressed Image Files, by John Miano, Image Library's principal author. Borland C++ Builder and Microsoft Visual C++ are explicitly mentioned on the web page, which also claims that the library is written in standard C++, implying that it should work with most compilers. Full source code is freely available, including an independent implementation of the deflate and inflate algorithms, i.e., the core routines of zlib. Image Library may be used without fee in software that is likewise free and distributed with source; otherwise, licensing fees apply. The latest release as of this writing was on 22 July 1998; this version incorrectly rejects PNG images with a zlib window size other than 32 KB.
Ulrich von Zadow's PaintLib is a C++ class library for decoding and manipulating several image formats, including PNG; version 2.0 adds an ActiveX control to the Win32 port. Like several of the available imaging toolkits, PaintLib actually uses libpng and zlib for its PNG support and provides a higher-level, unified interface to its supported formats. Source code is available, and it compiles under at least DOS, Unix, and both 16-bit and 32-bit Windows. The library may be freely used and distributed as long as its use is acknowledged.
QHTM is a 32-bit Windows control from Russell Freeman and Gipsysoft that lies somewhere between an image toolkit and an HTML browser. Specifically, it provides a programming interface that allows one to add HTML support, including PNG images, to an application. (PNG is actually supported via code from PaintLib.) QHTM 1.0 does not yet handle transparency, but support for that is planned. Like PaintLib, QHTM may be freely used and distributed as long as its use is acknowledged.
SGI's ImageVision Library is ``a toolkit for creating, processing and displaying images on all Silicon Graphics workstations,'' to quote from the web page. It actually does not read or write image files itself; all file I/O is handled by SGI's Image Format Library, which is also available for 32-bit Windows (Microsoft Visual C++ 5.0 only). According to the IRIX 6.5 documentation, IFL is still based on libpng 0.88 and zlib 1.0, but the Windows version may be more up-to-date. IRIX users compiling applications for use with current versions of libpng and zlib should take care that they don't accidentally load the older IFL code.
Imlib is another high-level, multiformat image library, currently under development by Red Hat Advanced Development (RHAD) Labs. Though developed under and mainly supported for Linux, it is written as portable Unix/X code, and source code is available for compiling on other platforms. Imlib supports programs based on both plain Xlib and on the GIMP Toolkit (GTK+). Unlike the X front ends for the demo programs presented in Chapter 13, "Reading PNG Images" and Chapter 14, "Reading PNG Images Progressively", Imlib has the great advantage of supporting most X displays, including monochrome, pseudocolor (all bit depths from 2 through 8), static color, and truecolor. On the other hand, it treats all images as 24-bit RGB, optionally with a single color marked as transparent. As of this writing, the current release is version 1.9.4, which includes a placeholder pointer for future 8-bit alpha-channel support but no indication of what level of support may eventually show up. The authors indicated in early March 1999 that alpha support was a low priority.
Apple's QuickTime is a high-level, multiformat image (and multimedia) library for Mac OS System 7.0 and later and for 32-bit Windows. Version 3.0, which natively supports reading PNG images, is included as a standard part of Mac OS 8.5, making Mac OS the first operating system for which PNG support is built in. PNG is also supported unofficially in QuickTime 2.5 via a read-only PNG importer written by Sam Bushell. A future QuickTime release is expected to support writing PNG images.
Accusoft's ImageGear is a commercial imaging library that supports several dozen formats, including PNG. It is available for Unix, OS/2, Macintosh, 16-bit and 32-bit Windows (including a Visual Basic interface), and Java (both as Java classes and as Beans). The web page strongly implies that full alpha transparency is supported, too.
In November 1998 Sun's Javasoft subsidiary finally added native PNG support to Java. As of the beta release in April 1999, the Java Advanced Imaging API included both read and write support for PNG. The Advanced Imaging API requires the Java 2 SDK (formerly known as JDK 1.2) or later and will presumably be available under the same terms as Java itself.
Six-Legged Software's Java package reads and displays PNG images as a Java ImageProducer. It supports full alpha transparency, gamma correction, progressive display, and conversion to grayscale, plus quite a few ancillary chunk types. Write support is expected in a separate, yet-to-be-released package. The current read-only release, as of early April 1999, is version 1.0a and requires JDK 1.1 or later (for zlib). Chris Nokleberg released version 1.0a under the GNU LGPL--formerly the Library General Public License, recently renamed the Lesser General Public License since it allows linking to proprietary code. Full source code is included.
The Java Image Content Handlers were originally developed by Justin Couch for his employer, ADI Limited, but the code was subsequently released as free software and is now distributed by Justin's own company, The Virtual Light Company. Several other image formats are supported in addition to PNG, including JPEG, TIFF, NetPBM, BMP, TGA, and GIF. The current release, version 0.9.1, is read-only, but write support is coming. The handlers are written for Java 2 (JDK 1.2) but will work with JDK 1.1 with only minor changes. Full source code is included; as with Sixlegs PNG, the license is the GNU LGPL.
VisualTek's Java PNG library is, as the name suggests, a library for use in Java programs with support for reading and writing PNG images. Its license is somewhat less than clear, however; the web page claims it is distributed under the GNU General Public License, but no source code is available, and another web page refers to a 30-day evaluation period. Apparently it may be freely used in GPL'd programs but must be licensed commercially in other programs.
Activated Intelligence's image toolkit supports a number of image formats, either ``natively'' or via Java's ImageProducer/ImageConsumer model, with both read and write support for PNG. The web site claims it is quite fast and can handle extremely large images (100 MB or more), subject only to available disk space. The package, currently version 2.0, is commercial, but the Standard edition is royalty-free; i.e., it requires no payment beyond the initial purchase.
Faidon Oy-Ab's Java Vector Graphics package supports reading and writing PNG images, as well as a few other formats. The current release, version 1.0, is shareware, but the older 1.0 beta 1 (with read-only PNG support) is free. A company representative promised in November 1998 that at least the PNG portion of JVG 1.0 ``will be freeware soon,'' mainly due to the fact that Sun is including PNG support in the Java Advanced Imaging API.
Jan Nijtmans's Img is a free image-processing extension to the Tcl/Tk scripting language; it uses libpng and zlib for its PNG support. It works with Tcl 7.5 and Tk 4.1 and later versions on both Unix/X and 32-bit Windows platforms. Both reading and writing are supported in versions 1.1.4 and 1.2b2, but a patch to Tk is required in order to write PNG images with an alpha channel. Version 1.2 is expected to be released just after the Tcl/Tk 8.1 release, currently scheduled for early May, 1999. Unfortunately, Scriptics was unwilling to incorporate Jan's Tk patch into the official 8.1 release (Tk 8.1 is thread-safe, but the patch is not), so manual patching will remain necessary for some time to come in order to write alpha PNGs.
As its name suggests, Fredrik Lundh's Python Imaging Library (PIL) provides support for multiple image formats under the Python interpreted programming language on Unix or 32-bit Windows platforms. It can also support Tcl/Tk via the Tkinter package. Though currently still at a suspiciously low beta version (0.3b2), PIL supports both reading and writing PNG images, apparently including alpha channels and some 16-bit-per-sample images (possibly grayscale only). It also includes some support for MNG streams, though this has not been not updated since roughly draft 33. PIL may be freely used and distributed as long as such use is acknowledged.
Simon Clarke's PNGHandler provides read/write PNG support to the BeOS Translation Kit. It is freely available for both PowerPC and Intel platforms, and it requires BeOS version R3 or later. PNGHandler can read all PNG bit depths with the possible exception of 16-bit-per-sample images (e.g., 48-bit RGB), and it appears to have full alpha support. For writing, it supports only depths of 8, 24, and 32 bits. It appeared that PNGHandler may have been renamed to PNGTranslator as of version 1.20, but version 1.21 is once again called PNGHandler. Nevertheless, if the following link should break, check the PNG home site's Toolkits page, given at the beginning of this section, for updates.
Andreas Kleinert's SuperView Library, part of his SViewII image application, provides read and write support for numerous image formats on the Amiga, in addition to a host of image-manipulation functions. It is not clear from the documentation whether it supports any of the more advanced PNG features such as gamma correction or even transparency. SViewII and the SuperView Library are shareware.
Version 4.0, Skyline Tools. This is a 32-bit Windows DLL with Delphi support; version 2.5 also supported 16-bit Windows. It claims ``support for most PNG formats'' and ``image conversion,'' which implies that it has read/write support for PNGs.
Version 6.02, Data Techniques. These are suites of ActiveX controls, Visual Basic controls, and DLLs for image manipulation and conversion. They support both 16- and 32-bit Windows and include read/write support for PNGs.
Version 4.3, Smaller Animals Software. This is a 32-bit Windows DLL with read/write support for PNGs; it claims to support alpha transparency and gamma correction as well. It can be used with Visual C++, Visual Basic, and so on.
LEAD Technologies. This is a suite of toolkits with image support, including partial read/write support for PNGs. According to the features page, 2-bit PNG images and images with 16 bits per sample are not supported for either reading or writing, and interlacing and alpha transparency are supported only for reading. LEADTOOLS once supported the DOS and OS/2 platforms in addition to 16- and 32-bit Windows, but now only Windows appears to be supported.
Version 4.22, VYSOR Integration. This is an ``interpreted image-processing and graphics language toolkit'' for creating multimedia presentations, demos, and imaging applications, especially for satellite data. It is available for 32-bit Windows, and it includes both standalone tools and a DLL for user programs.
Bananas Software. This is an ActiveX control (OCX) for 32-bit Windows. It includes read/write support for PNGs and a number of other image formats, and it can be used with Visual C++, Visual Basic, Delphi, in web browsers, and so on.
Version 5.0, Catenary Systems. This is a DLL for 16-bit and 32-bit Windows; it includes read/write support for PNGs and a number of other image formats, though PNG is only supported in the 16-bit Windows version with a separate add-on (freely downloadable). Apparently, only the 32-bit Windows version is still under active development--the last Windows 3.x release was version 4.25. There is also a version 3.7 for DOS, but it has no PNG support, and the PNG add-on does not apply to it.
The Portable Network Graphics format represents one more step in the evolution of portable, robust image formats. With good, ubiquitous support just around the corner in web browsers, and with support in image viewing and editing applications not only common but actually expected by customers, PNG's future is bright.
Of course, in the four years since PNG was created, we've learned a few lessons about what works and what doesn't. In the spirit of various publications' ``post-game analyses'' or ``postmortems,'' here is a quick look at some of the things we did right and some we did wrong, in no particular order.
Content developers are justifiably excited about the possibility of using variable transparency, including real anti-aliasing. The fact that PNG can do 8-bit (or smaller) RGBA-palettes is currently underappreciated and decidedly underimplemented, but it will come to be seen as one of PNG's greatest strengths in the next year or two.
Despite rather spotty support in applications to date, gamma and color correction are features designers have been begging for, though not always by name. They will eventually come to be expected, but support in more browsers and image editors (correct support!) is necessary before users will begin to notice the difference. And while operating-system support for gamma and color correction isn't absolutely necessary, having it--as in recent releases of Unix/X and Mac OS and rumored future versions of Windows--makes the lives of application developers much easier.
The lack of a PNG-related animation format early on, and the subsequent delay in finishing and implementing a viable one, was perhaps PNG's greatest failing--certainly it is one of the most oft-heard criticisms. While there was no way the PNG Development Group could have known about Netscape's GIF-animation surprise late in 1995, in retrospect, it is obvious that the group should have begun development on a PNG-like alternative right away.
Allowing the early MPNG project to be swayed too far in the direction of a heavyweight multimedia format was also a mistake; the best course would have been to come up with something just a little better than animated GIF, with the option of extending it later to become more in line with today's MNG. A ``thin'' PNG animation spec, similar to the capability provided today by ImageMagick, could have been implemented easily by mid-1996 or even the end of 1995. (Starting small and working up is always easier!) Fortunately, recent drafts of the MNG specification have added the concept of ``simplicity profiles,'' so developers finally have the option of supporting a subset of the full PNG/MNG animation spec in a well-defined manner. Versions since 0.93 have actually extracted low complexity and very low complexity subsets into separate documents--MNG-LC and MNG-VLC, respectively--so ``starting small and working up'' is now not only possible but also actively encouraged.
It is difficult to zero in on one feature that counts as PNG's greatest success, but arguably the open, Internet-based development process was (and is) it. Even four years later, creating a robust, portable, extensible, well-specified image format from scratch in two months is nothing short of amazing. The continued infusion of new blood and new ideas has been invaluable. New code is good, too.
 Or perhaps we are just now learning what university professors and Linux enthusiasts have always known: graduate-student-powered development is the way to go. Certainly the author of this book didn't get a whole lot done during the first two months of 1995, when PNG was being designed. (Actually, only about a quarter of the most active members of the PNG Development Group were students at the time, but the remainder achieved honorary grad-studenthood.)
When trying to promote the acceptance of a new format in existing applications, nothing succeeds so well as doing some of the developers' work! The availability of free and robust reference libraries (libpng and zlib), with minimal restrictions on reuse and redistribution, was clearly vital to PNG's success.
Separating the file format, as symbolized by libpng, from the compression engine, symbolized by zlib, probably made the format more palatable to programmers. If, for some reason, one were averse to using both libraries (perhaps due to code size), one could choose to implement only the PNG half--which is not nearly so intimidating as rewriting both the PNG library and the deflate algorithm. The fact that zlib's core compression code was already a trusted and familiar component of gzip and the Info-ZIP tools may have helped, too.
The failure to get good PNG support into the Big Two browsers even four years after PNG's release--and the lack of any support for two-and-a-half years--must count as a strike against the PNG Group, even if it's still not apparent what could have been done differently. At the time, Netscape and Microsoft were in the midst of the so-called Browser War, and one more image format, even one that boasted alpha and gamma support, just wasn't flashy enough to show up on their proverbial radar screens. Personal contacts might have helped, but both companies were large enough that finding the right contact was close to impossible.
Nevertheless, that's (mostly) water under the bridge. As I noted way back in Chapter 1, "An Introduction to PNG", the 4.0 releases of both browsers have supported PNG files natively since late 1997, and the 5.0 releases are expected to fully support both alpha transparency and gamma correction. Once that happens, web designers can be expected to begin using (and demanding!) PNGs with alpha and gamma support on web pages within a year or so.
Pushing PNG as a standard (Recommendation) of the World Wide Web Consortium was probably key to getting PNG support into the Big Two by the end of 1997. And PNG's inclusion in the VRML97 ISO specification led to its status today as an ISO standards-track format, which is likely both to help speed its acceptance in areas outside the Web (such as medical imaging, perhaps) and to ensure its longevity as a common and useful image format.
As most implementors know, there are specifications, and then there are specifications. PNG's spec has been praised by a number of third parties as being one of the cleanest, most thorough, and least ambiguous image specifications ever written. Partly, this was due to the work of some very good editors, but it owes a lot to the Open Source process, too (the ``many eyeballs'' effect).
PNG's well-defined method for adding new features in a backward-compatible manner has already proven itself many times over. The addition of the iTXt chunk early in 1999 is the latest example; even 1995-era viewers can still display a PNG image with such a chunk in it. Of course, such a powerful tool cuts both ways, as became apparent when some users mistakenly tried to use PNG images containing Fireworks's huge editing extensions on web pages.
The presence of cyclic redundancy check (CRC) values in every chunk is a positive thing and helps PNG's robustness, but one of the original aims--the ability to verify from a command-line prompt that a PNG image was downloaded properly--turned out not to be particularly useful. The advent of high-speed modems, ubiquitous Internet connections, and, above all, web browsers with smart downloading capabilities, all served to make the command-line feature obsolete before it was ever really put in place. The pngcheck utility discussed in Chapter 5, "Applications: Image Converters" was originally written for this purpose, but it has since evolved into more of a PNG conformance tester.
Overall, PNG has done quite well. Yes, there were a few missed turns, a few mistakes, and somewhat slower acceptance than many of us had hoped. But as Tom Lane has repeatedly reminded us, JPEG didn't catch on any faster, and even GIF took quite a while outside of CompuServe. The fact that PNG is currently one of only three accepted image formats on the Web is quite an achievement. May its next four years be equally exciting!
Sun sets over GIF.
With PNG on the horizon,
Web is dark no more.
--Michael N. Randers-Pehrson