Concluding Remarks
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.
- Alpha transparency
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.
- Gamma and color correction
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.
- Animation
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.
- Open Source-style development
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.
- Free reference code
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.
- Decoupled compression engine
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.
- Slow browser support
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.
- Standardization
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.
- Specification
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).
- Extensibility
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.
- Internal consistency checks
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
|