PNG, MNG, JNG and Mozilla M17
Greg Roelofs
26 June 2000
PNG support in Mozilla has improved greatly over the last few releases
("milestones"), and with each milestone comes a corresponding Slashdot
posting and a lot of discussion. Unfortunately, not all of the discussion
is entirely accurate, so here's a preemptive posting that attempts to
update folks on the status of PNG support in Mozilla and other apps and
to clear up some of the more common misconceptions. (This seems to be
an annual event...thanks to Jamie McCarthy for the suggestion this time
around.)
Home Page
First of all, the PNG home page got booted off of cdrom.com in early
March, and in early May it settled into what should be its absolutely final
home:
This is currently hosted on freesoftware.com, Walnut Creek CD-ROM's new
site for free software (quel surprise!), but if something should ever
happen to Walnut Creek, libpng.org will be redirected appropriately.
(On a related note, the new zlib URL is http://www.info-zip.org/pub/infozip/zlib/, which is also currently
hosted on freesoftware.com.) (Subsequent note, June 2001: zlib at last
has its own domain: http://www.zlib.org/,
currently hosted by France-Teaser.)
PNG Features for the Web
Insofar as this is ostensibly a Mozilla posting, let's have a brief rundown
of the PNG features that are most useful to web designers:
- alpha transparency - This is geek jargon for partial or variable
transparency, and it lets you do nice effects that are independent of
the background color(s), such as antialiased (non-jaggy) text, drop
shadows, gradient fades, and translucency. PNG not only supports a full
8-bit alpha channel in grayscale and RGB images but also what amounts to
an "RGBA palette" in colormapped images. The latter lets you do nice
transparency without a huge hit in file size. For example, all but one
of the transparent images on my PNG alpha-transparency
test page are 8-bit or less; the lone exception (one of the toucans)
is a 32-bit RGBA image, virtually indistinguishable from its 8-bit
cousins. Note that PNG supports only unassociated (non-premultiplied)
alpha, since the alternative is not lossless.
- gamma correction - Gamma allows you to display the same image on
different platforms without looking too dark on some and too light on
others. For best results it does require that both the designer's
display system and the user's be calibrated, but even educated guessing
is better than nothing in a viewing program (which is what Mozilla does).
Warning! Watch out for Adobe Photoshop; version 5.0 had a serious
factor-of-two bug in its PNG gamma support, and 4.0 also had some
problems. (Things seem to be fixed in 5.5, however.)
- color correction - Where gamma has to do with image "brightness,"
color correction has to do with rendering shades of color precisely. PNG
supports it, but not many applications do; it's pretty tricky to get
right. Note that Photoshop 5.5 writes incorrect PNG "iCCP" chunks, and
this will crash some applications based on libpng 1.0.6. (Older versions
of libpng ignore the chunk, and the soon-to-be-released libpng 1.0.7
will work around it.) Also note that feeding a valid iCCP chunk
to PS 5.5 is reported to hang it.
- compression - A lot of people have some seriously crazy ideas about
PNG's compression. Here's the straight dope:
- PNGs tend to be 15% to 20% smaller than equivalent GIFs on
average. There are some GIFs, particularly 32- or 64-color
ones, that are smaller than the best PNGs, but usually by only
a couple of percent. There are also many that are more than twice
as large as the corresponding PNGs, but these tend to be tiny
images. (One exception is this
image, which is dimensionally rather large yet only 1/3 the
file size of the GIF version.)
- PNGs tend to be much larger than standard JPEGs. JPEGs are
lossy, while PNGs are lossless; for natural (photographic) material,
no lossless format can compete with JPEG--PNGs will typically be
5 or 10 times as large. On the other hand, for simple graphics or
text-filled images with relatively few colors and sharp edges, JPEG
is much worse, both in quality and in file size. (This means you,
Slackware guys!) Use the
proper tool for the job--no single image format is best in all
cases.
- PNG is roughly comparable to JPEG-LS, the new lossless JPEG
standard. On the Waterloo BragZone test suite, JPEG-LS beat PNG by
5% to 10% on natural images, but PNG beat JPEG-LS by 35% to 270%
on "artistic" images. YMMV.
- PNG's compression method can be implemented in such a way that it
is completely free of all known patents, but it can also be
implemented in such a way that it infringes on patents held by
PKWARE, Stac and others. You can guess which way zlib was written.
Folks who are neither rich nor expert in patent law should probably
stick to zlib- and
libpng-based implementations.
- Unlike (LZW-based) GIF, in which the compression is basically
deterministic--that is, you end up with pretty much the same data
regardless of who does the compression--PNG's scheme leaves a lot
of room for optimization. Some programs do a good job, some don't.
The GIMP happens to be one of the good ones, as is pngcrush. Photoshop
traditionally has been one of the not-so-good ones, although
version 5.5 includes a "Save for Web" option that presumably
invokes ImageReady. ImageReady 1.0 was mediocre and reportedly
isn't much better in its current release (i.e., pngcrush beats it
by 15% to 25%), but it is better than Photoshop's normal "Save as"
option.
- The compression engine can't help clueless users who perform
apples-and-oranges comparisons. If you start with a truecolor
image and save it as both GIF and PNG, chances are the PNG will be
24-bit while the GIF will be 8-bit. Guess what? It's pretty tough
to overcome that initial 3:1 deficit, no matter how good your
compression engine is. (If you're not sure what kind of PNGs you
have, check!)
Also don't add a lot of text annotations to the PNG--unless you do
the same to the GIF--and especially don't add a useless alpha
channel to opaque images! (That last is directed at the Burn All GIFs folks...) Recompressing
an image after it's been through JPEG compression is also a bad
idea; JPEG leaves a lot of nasty little artifacts (often invisible
to the naked eye) that screw up non-JPEG compressors.
- interlacing - PNG's interlacing scheme is two-dimensional, much
like progressive JPEG, but unlike GIF--which uses a one-dimensional,
line-based scheme. The upshot is that an interlaced PNG with text in it
will be readable roughly twice as soon as the corresponding interlaced
GIF.
- animation - Nope. But see MNG, below.
- MIME type - image/png. If PNG images on your server show
up as broken images within web pages and as gobbledygook text when
referenced directly (i.e., as standalone URLs), you probably don't have
the MIME type set up correctly. On the other hand, if they show up
correctly for MSIE and some versions of Netscape but not others, you're
probably running Microsoft's IIS server. Technically it's a bug in older
versions of Netscape (versions 4.04 through 4.5), but consider switching
to Apache anyway...
- browser compatibility - We'll get to that in a moment.
PNG Extensions and the Future
PNG is extensible. PNG is lossless. PNG is a single-image, raster (bitmap)
format. One of its overriding design goals was backward compatibility. As
a result, don't expect to see any sort of lossy compression methods (JPEG is
doing a fine job of that, with the exception of transparency--but see JNG,
below). Also don't expect to see any vector-based extensions--SVG with gzip
content-encoding has that covered. Indeed, don't expect to see any new,
incompatible compression methods for quite a while. Until there are lossless
methods that can, on average, halve the size of PNG images, the cost in
software compatibility is far too great. (Keep in mind that there still
browsers that don't support progressive JPEG, and that was a relatively
trivial change! And let's not even talk about JPEG 2000...)
PNG is also not going to become an animated format. Leaving multiple-image
support out of PNG was a conscious design decision by the PNG development
group, and it's still the right decision. Overloading a still image format
with animation or video features merely confuses users and web browsers, which
have no way to distinguish still images from animations without prying into
the data streams (which usually means downloading them first). Developers
who prefer to program monolithically can always program for MNG instead; it's
architecturally identical to PNG, and PNG is a pure subset of MNG.
Related Formats
MNG: As the previous paragraph suggests, the animated version of PNG is
called MNG, for Multiple-image Network Graphics. It supports looping
(including nested loops), clipping, deltas, and other features, plus everything
PNG supports--including alpha transparency, of course. The home page is here:
Since this spring, a free reference library, libmng, has been under
development by Gerard Juyn; its home page is at:
Note that the MIME type is video/x-mng; it has not yet been registered
with the IETF. Undoubtedly there will be many misconfigured web servers in
coming years...
JNG: JNG is short for JPEG Network Graphics and is a proper
subset of MNG, just as PNG is, but it's worth a separate mention. The idea
is to combine the best of both worlds: JPEG's excellent compression and PNG's
incredibly spiffy alpha transparency and color correction. JNG is almost
identical to PNG, but in
addition to standard IDAT chunks (which in JNG contain the alpha channel),
there are also JDAT chunks that contain a standard JPEG/JFIF stream (suitable
for handing off to libjpeg). From a
developer's standpoint, if you've got support for both PNG alpha and ordinary
JPEG/JFIF, adding JNG is a breeze. Of course, JNG is also supported by recent
libmng betas. Its MIME type is image/x-jng.
Browser Status
Most browsers have
supported PNG since at least late 1997 (when Netscape
Navigator and Microsoft Internet Explorer finally did), but almost without
exception, their support for alpha transparency has been abominable.
Amazingly enough, it seems that 2000 may be the year that browsers finally
support it, more or less ubiquitously. In April alone there were three
newcomers, with another in May; so far this year, the total has more than
doubled. Here's the current list of browsers that at least attempt to do
alpha transparency correctly, with their supported platforms indicated in
italics. If screen shots of the PNG alpha-transparency test
page are available, they're linked to the browser name:
- Arena (Unix/X) - this was the first browser with good
alpha support (at least for Unix, and I think anywhere). It died in
1998, however, and the final release tends to core-dump on PNG images.
It always used its own "sandy" background pattern rather than that
specified in the HTML.
- Browse (RISC OS) - Acorn's browser was the first to
fully support PNG transparency and gamma correction, including background
images, but it died along with Acorn itself in June 1999. The browser
may or may not eventually show up in Pace Micro's digital set-top boxes.
(Very old screen shot.)
- CSCMail (Unix/GTK+) - This is actually Steven "Count
Zero" Kordik's mail client with built-in HTML support via the CscHTML
widget, but since the built-in minibrowser is capable of fetching remote
URLs, it counts as a (lightweight) web browser in its own right.
- iCab (Macintosh) - this was the first Macintosh
browser to support alpha transparency (since the 1.8 beta), but it
doesn't do gamma correction yet.
- ICE Browser (Java) - ICEsoft's commercial browser for Java
reportedly has full alpha support, but I haven't verified that.
- Internet Explorer (Macintosh) - version 5.0 added
superb PNG support, including alpha, gamma and color correction. This is
probably the best PNG-supporting browser available today. Unfortunately,
the Windows and Unix versions seem to be a completely separate code base,
so there's no telling when (or if) they'll have equally good support.
(See the browsers
page for details.)
- Mozilla (Macintosh, Unix/X, Windows) - alpha was
enabled in April, though there are a few gotchas: the Windows code is
currently broken (bug 36694 and
19283, to
be fixed by beta3), and the X code is a slightly nasty
hack--it looks beautiful on 24-bit displays, but it's slow when scrolling,
and the quality for users of 8- and 16-bit displays will be relatively
poor. Nevertheless, it's a vast improvement over the previous code, and
it's basically the only game in town for Unix users. Note that the
infamous PNG interlacing bug (3195) was fixed
in May, and Tim Rowley checked in initial MNG and JNG support on
12 June.
- NetPositive (BeOS) - version 2.2, released in April,
added support for alpha transparency; but like iCab, it doesn't yet do
gamma correction. (It also doesn't display interlaced PNGs
progressively.)
- Netscape - see Mozilla (which is basically what
Navigator 6.0 will be).
- OmniWeb (NeXTStep/OpenStep, Mac OS X) - the first
release of this browser with PNG support (2.0) didn't support alpha, but
apparently that was fixed soon afterward.
- Sega Dreamcast Web Browser (Dreamcast) - version 2.0 of
Planetweb's browser for the Sega Dreamcast game console, released in May,
fully supports alpha transparency, but I don't have any screen shots yet.
- Webster XL (RISC OS) - R-Comp's RISC OS browser is claimed
to have full alpha support, but I don't have verification. (It is
still being actively developed, contrary to my original claim; version
1.95 was released in May and an internal beta version came out just
yesterday [26 June]. The web site isn't completely up to date,
however.)
- WebTV (WebTV) - surprisingly enough, WebTV has decent
support for 32-bit RGBA PNGs, but its support for palette transparency is
broken. In principle it should be easy to fix, but then again, it's a
strange platform. (Note that the fonts look considerably better on a
television screen.)
Honorable Mention goes to Siegel & Gale's PNG Live plug-in for
Netscape, which was the only plug-in ever to manage alpha transparency (in
Windows only). It died before ever getting out of beta, though, and plug-ins
in general are useless for PNG. So is the HTML 4.0 OBJECT tag, but don't
get me started...
Other Apps, Libs, etc.
I currently list some 500 distinct PNG-supporting packages
(more if you break things like Microsoft Office into their constituent parts)
in 8 categories (soon to be 9 or 10), not to mention a dozen pieces of
hardware. PNG has
now reached the point where even freeware authors generally don't bother
to tell me when they've added support; it's largely taken for granted. (I
do occasional Freshmeat
sweeps, but I usually don't have time, and many entries don't mention PNG
even if it's supported.) Quite a number of the apps include full source code, by the
way--which is the way it should be, of course. ;-)
Within the libraries-and-toolkits category, there are a surprising number of
independent PNG implementations (either encoders or decoders or both),
including ones in C, C++, Java, JavaScript, Pascal, and even Ada95. PNG is
now a standard part of Java 2 SE 1.3 (but not Tcl/Tk as I
originally claimed), and it is the main image format in the popular gd
library and all of its Perl-based derivatives. In turn, this has led to its
online use in areas as diverse as server statistics, chemical diagrams,
computer-generated mazes, and weather maps.
Even better, PNG is the native, internal image format for a number of major
applications (including Macromedia Fireworks and Microsoft
Office), and it's becoming a popular icon format for advanced GUIs.
It also ships as a standard part of BeOS, via the Translation Kit,
and it's supported natively in the Windows Me shell (and possibly
in Windows 2000 Professional).
Conclusion?
Ordinarily I'd mumble something about how PNG has finally achieved massive
studliness and will soon be taking over the world, but what the hell--it has,
it is, and if it's not obvious from what I've already written, another couple
of lines won't make any difference. Go forth, visit the web site, write code, make lots of PNGs,
etc., etc.
And Microsoft, pleeeeease get on the ball with Internet Explorer for
Windows and Unix...
Last modified 14 March 2009.
Copyright © 2000-2009 Greg Roelofs.