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:
http://www.libpng.org/pub/png/pngaptk.html http://www.libpng.org/pub/png/pngcode.html
Note that I have not personally tested any of the libraries or toolkits listed here.
http://www.wizards.dupont.com/cristy/ImageMagick.html
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.
http://www.colosseumbuilders.com/sourcecode.htm
http://user.cs.tu-berlin.de/~uzadow/paintlib/
http://www.gipsysoft.com/qhtm/features.html
http://www.sgi.com/Technology/ImageVision/
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.
http://www.labs.redhat.com/imlib/
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.[106] 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.
[106] A developer's release of Apple's next-generation Rhapsody OS also had PNG support, but it has not yet been released as a shipping product.
http://www.apple.com/quicktime/
http://www.accusoft.com/Digital_Imaging/ImageGear/IG98_Fr.htm
http://www.javasoft.com/products/java-media/jai/ http://www.javasoft.com/products/java-media/jai/forDevelopers/jai-apidocs/ http://www.javasoft.com/products/java-media/jai/forDevelopers/jai-guide/
http://www.sixlegs.com/png/
http://www.vlc.com.au/imageloader/
http://www.visualtek.com/PNG/
http://www.activated.com/products/jimi/jimi.html
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.
http://web.avo.fr/faidon/JVG.htm
Pnglets was a late addition; created by Roger E. Critchlow, Jr., and first released in April 1999, it is written entirely in JavaScript and is capable of creating palette-based PNG images on the fly. Thus it can be included on web pages, allowing the client browser (rather than the web server) to render PNG bitmaps dynamically. The author considered the initial release to be ``pre-alpha,'' but it already appeared to be relatively feature-complete; the main problems noted on the web page included a JavaScript incompatibility with Microsoft's Internet Explorer and the lack of PNG transparency support in current releases of Netscape Navigator. Pnglets is available under the GNU General Public License (GPL), which is more restrictive than the GNU LGPL. The initial version did not appear to include any special wording about how the license might affect user-written JavaScript embedded in a web page that uses Pnglets, but that will probably be clarified in a subsequent release. (The Pnglets code itself lives in a separate file, Pnglet.js, and is ``linked in'' via the HTML SCRIPT tag.)
http://www.elf.org/pnglets/
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[107] 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.
[107] As of version 8.0, Tcl and Tk share the same version number.
http://home.wxs.nl/~nijtmans/img.html
http://www.python.org/sigs/image-sig/Imaging.html
http://www.be.com/beware/Datatypes/PNGHandler.html
http://home.t-online.de/home/Andreas_Kleinert/sview.htm
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.
http://www.imagelib.com/
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.
http://www.data-tech.com/imocx/imageman_activex_suite.htm http://www.data-tech.com/imageman_dll_suite.htm
http://www.smalleranimals.com/imgdll.htm
http://www.leadtools.com/products.htm
http://www.vysor.com/p40tools.htm
http://www.beyersdorf.com/pgraphe.html
http://home.earthlink.net/~bananasoft/twisted.htm
http://www.catenary.com/victor/ http://www.catenary.com/victor/download/vicpng.html
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.[108] The continued infusion of new blood and new ideas has been invaluable. New code is good, too.
[108] 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.
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.