Slashdot Log In
An Overview Of PNG; Mozilla M17 (Updated)
from the mille-bornes dept.
PNG, MNG, JNG and Mozilla M17
26 June 2000
by Greg Roelofs
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...)
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.)
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 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 will 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. (Very old screen shot.)
- 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.)
- 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.)
- Konqueror (Unix/KDE) - I just heard that KDE's file-manager-cum-browser has full alpha support, but I haven't had a chance to check it myself. I'll try to get some screen shots added soon, however.
- 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 12June.
- 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).
- 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, and it doesn't appear to be under development anymore.
- 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 and Tcl/Tk, 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...

M25 (Score:5)
Mozilla (will be) release(d) (Score:4)
Maybe I'm just reloading too often.
Smells Like Troll Spirit (Score:3)
They're fun to pour right down your pants
Natalie is naked and turned to stone
Oh no, OOG's gone, now I'm all alone
Hello, hello, hello, Katz blows
Hello, hello, hello, Katz blows
I like trolling, it's contagious
Here we are now, moderate us
You don't like caps, post aborted?
ASCII art plans, they are thwarted!
I got bitchslapped, I dissed Bojay
I post flamebait every Troll Day
Yeah!
First posting's what I do best
And for this gift I feel blessed
Commander T likes other men
And always will until the end
Hello, hello, hello, Katz blows
Hello, hello, hello, Katz blows
VA's stock price, it's disastrous
Hey, does timmy ride the short bus?
All they post now: Lars and Napster
Well, this sure ain't stuff that matters
Raymond shoots ten who don't 'get it'?
Read it Tuesday on ZDNet
Yeah!
And I forgot
Just why I post
Oh yeah, I'm first, so now I can boast
I'm not that lame, the filters are blind
Can you imagine a -- oh, nevermind
I'm not rabid, like the zealots
So they flamed me, they're just jealous
Metamodding and IP bans
Won't you use them on ol' sorehands?
I don't want to beg for karma
Don't hate patents, just your dogma
I'm not insightful
Not insightful
Not insightful...
Yu Suzuki
Mozilla M17 - No It's Not. (Score:5)
Come on slashdot, this happened before with M16 as well, it was released way after slashdot said it was out. didn't you see it coming this time?
less irresponsible 'Mnn is out!' posts please. how would you like it if someone said 'hey look you've finished!' even though you'd just started. wouldn't be a true indication of the finished product would it.
I'll stop ranting now..
Re:When will the final version of Mozilla arrive? (Score:4)
Plus, Netscape has had print preview since before 1.0. IE added it in what, 5.5?
I'll admit, IE 3 was better then Netscape 3. And Netscape 4 has it's problems as well, but IE went the wrong direction once MS played around with it for 3 versions.
Technological inflation ? (Score:4)
Whenever a system is well done and integrated an application developper should only focus on features more than these disguised OS patches.
For example, on RiscOS [riscos.com], JPEG decompression is handled by the system and performed during the display refresh so that the memory needs are even lower. Most system routines are stored in software modules that can be accessed from whichever program, even BASIC script.
Concerning Mozilla, it is a shame that a Free Software Team is working on such a big thing instead of choosing to re-design it a more clever way.
BTW, here in Europe downloading dozens of Megabytes is a bit expensive, you know?
So, let's keep things small.
--
Clue for the day (Score:4)
alpha (the greek letter) is often used in equations to reflect a coefficient. In the case of calculating out the colour of a pixel, you may be left with an equation like :
a * alpha + b * beta
--------------------
c
In this particular case, "alpha" can be considered the coefficient for a source image intensity and "beta" can be considered the coefficient of a destination image intensity.
What this all boils down to is "alpha" transparency is the same as "beta" transparency, "gamma" transparency, or "horse" transparency. The use of the term "alpha" to describe it is worse than meaningless. Alpha can represent ANYTHING, that includes refractive quantities, air density, paint, or a splatter of your gran's homemade shoe polish.
It's called "transparency", not "alpha transparency". Perhaps semi-transparency, or if you're being really precise, "transparent filtering". Where in the latter case, you MAY use "alpha" to represent the filter.
HAND.
Slashdot - a bad joke (Score:3)
Take this "announcement" for instance. A simple check around the Mozilla website would make it OBVIOUS that M17 is NOT out and won't be for a month or more.
Why is it then that Slashdot seems incapable of checking it's facts before announcing it's "scoop" to the world? Hilariously this is not the first time either - Slashdot announced M16 was out a good four weeks before it actually was.
Re:You want the truth? (Score:4)
How about the test of "will I have to abandon this platform if a single company goes bust / decides to discontinue development"? Especially for businesses, this is important. It costs time to change the browser on 100 machines, and it costs a hell of a lot of time to answer the support queries of 100 users who've just been handed a new browser.
Opera and IE may be alright now, but they're not open-source so you may get left high and dry. That's a problem if you've just spent a fortune developing an intranet which relies on one of them.
You can turn off the "Friendly HTTP error messages (Score:3)
Go Tools->Internet Options->Advanced, and then under the "Browsing" section there is a entry "Show Friendly HTTP error messages"
IE 5 shows them ("Friendly error messages") if there is a HTTP error code and the page size returned from the server is less than x bytes (where x is some number I can't remember now).
IMHO, it's quite a nice way to handle it - it tells newbies what has gone wrong and tells them ways in which they may be able to fix it, and yet it still enables website designers to display a custom web page (or redirect) on 404 errors, and advanced users can turn it off.
IE 5 for mac (Score:4)
It's doing pretty good with standards, and is small and light-weight (takes like 4mb of memory - 7 mb install without java)
Surprisingly enough it even trounced the win IE in more than one way, on a platform they don't control; What's even more surprising were the reports i heard later on that the mac IE development team was dissolved - who knows what the reasoning behind that was. (check out http://www.mozillazine.org/talkback.html?article=
(Making the mac a better browsing platform than windows?! what were they thinking
Re:too little too late? IE = 86% (Score:3)
I really hope that's not the case across the entire Internet (and let's face it, sampling client browsers is unreliable, much worse than checking server OS type, for example). Otherwise we can soon kiss goodbye to HTML and hello to the undocumented MS-HTML standard, and stop expecting it to be possible to write a competing browser that will display web pages.
PNG is fine with IIS - just missconfiguration (Score:5)
This is FUD. PNG's working in IE as opposed to Netscape when served by IIS is probably caused by a miss-configured web-server. And don't tell me that Apache can't be miss-configured either.
We had load-balanced web-servers which seemed to be identically configured. They were running NT 4 Server and IIS 4. Trouble was, the PNGs wouldn't show up in Netscape half the time.
Using "telnet myhost 80", I finally discovered why. One of the servers was returning the wrong MIME type for the PNG images. One was correctly returning image/png in the response header, the other was returning something like application/x-octet-stream.
The fix involved adding the image/png MIME type for
A correctly configured IE client differentiates based on file extension. So it ignores the MIME type in the response header, correctly displaying the PNG. Netscape on the otherhand looks at the response header, and thus cannot display the PNG if IIS is incorrectly configured.
The discussion on how IE uses file extensions is another issue.
Java (Score:4)
Re:M25 (Score:4)
Re:Clue for the day (Score:5)
And it has been used that way for something like twenty years, ever since Ed Catmull (king geek of Pixar) coined the term to contrast with the then-prevalent "z-buffer." He created a new rendering technique called the - cue drum-roll - a-buffer. Catmull added a channel to the frame buffer - the "alpha channel", so that there were now five channels in the rendering system - red, green, blue, depth (z), and transparency (alpha). In fact, he first used it more for "coverage" than transparency. The a-buffer renderer computed sub-pixel polygons and then used the alpha channel to store what percentage of the pixel was covered (i.e., how much light got through from a further pixel). This enabled his renderer to produce anti-aliased images at a phenomenal rate (especially when compared to an over-sampling ray-tracer, which was then the state of the art in anti-aliasing).
At the time, the renderer was called "Reyes" for "renders everything you've ever seen" (and of course, for Point Reyes, near Silicon Valley). Guess what it is called these days? (pregnant pause) RenderMan.
You can learn more about a-buffers and dig up references to the original literature (Catmull first published at SIGGRAPH) in "The White Book", aka, Foley, van Dam, Feiner, Hughes. [amazon.com]
mozilla.org says M17 "on the wire" 6/27/00 (Score:3)
The milestone plan is maintained here [mozilla.org]
If you look at it, you'll see that they have filled in the "on the wire" box, which appears to be an "actual" not a "schedule", because it's only filled in for past milestones and the dates appear (at first glance) to match the actual release dates.
If mozilla doesn't want people to shoot off "mozilla M17 out today" then they need to keep this page accurate and current (or get rid of it).
On the other hand, the M17 open bug and engineering task list is here [mozilla.org].
It lists 1073 bugs and tasks. So is M17 coming out later today or is it going to be 6 weeks away? This gives me the impression that mozilla.org is confused and doesn't have it's shit together on the communication side.
Author's comments/corrections (Score:3)
M17 schedule: I checked the Mozilla milestones page [mozilla.org] on Sunday before beginning the article and again Monday morning (3am PDT) just before submitting it; it claimed M17 would branch yesterday (26 June) and be on the wire today, and in fact it still says that--although there's now a red comment at the top (dated 27 May 1999!) that M17 won't be out for another couple of weeks. As a side note, I submitted the article with the following comment:
Unfortunately, it seems that both Jamie and I believed the other person was more informed about the true release date than we actually were. I apologize for the screwup.
Background: Back in April, around the time of the M15 posting, I commented to Jamie about the recent progress in PNG alpha support in browsers and the, shall we say, somewhat uneven accuracy of /. comments w.r.t. PNG and MNG features. He suggested I write something up for the next milestone, and I agreed to do that. Unfortunately, M16 showed up while I was on an extended business trip, so I wrote the article for M17 instead. I assumed it would be posted when M17 actually hit the wire, but it seems we were a bit premature. Oops...
Browsers and alpha support: As other comments have noted, OmniWeb and CscHTML also support full alpha blending, and Webster XL has not been abandoned--it's still under development. I've requested and/or have received screen shots for all three and will post them soon. On the other hand, I've been informed that Konqueror supports only binary (GIF-style) transparency, not full alpha blending. If anyone knows otherwise, please let me know. (I've downloaded a recent binary but am still missing a sufficiently recent libstdc++, I believe.)
Updated article: a corrected version of this article will be permanently available at http://www.libpng.org/pub/png/slas hpng-2000.html [libpng.org]. (The page is already there, but I haven't had time to update it yet.)
Hemos: I'm not Hemos, but I play one on TV.
Greg