Insofar as I may be heard by anything, which may or may not care what I say, I ask, if it matters, that you be forgiven for anything you may have done or failed to do which requires forgiveness. Conversely, if not forgiveness but something else may be required to insure any possible benefit for which you may be eligible after the destruction of your body, I ask that this, whatever it may be, be granted or withheld, as the case may be, in such a manner as to insure your receiving said benefit. I ask this in my capacity as your elected intermediary between yourself and that which may not be yourself, but which may have an interest in the matter of your receiving as much as it is possible for you to receive of this thing, and which may in some way be influenced by this ceremony. Amen.
(from Roger Zelazny's Creatures of Light and Darkness, copyright 1969)
Title: My original title for the article was PNG, MNG, JNG and Mozilla M17, specifically because the article was primarily about PNG and its buddies, not Mozilla. I'm sorry the actual title is misleading, but I can't take the blame for that one.
M17 schedule: I checked the Mozilla milestones page 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:
Well, supposedly M17 branches later today and hits the wire tomorrow (ha!)
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. (The page is already there, but I haven't had time to update it yet.)
Thanks for the info; I've just updated the OmniWeb entry on the PNG browsers page. I know that PNG support first appeared in 2.0, and that version did not have alpha support, but I've had no information about later releases.
Could you please contact me and let me know what the earliest alpha-supporting version was that you're completely certain of? I'd also love to add some screen shots of 4.0b3 or 3.1rc2 running on my PNG-alpha test page and the linked MagnoliaAlpha and IceAlpha pages.
Apparently Mozilla's milestones page is not to be trusted, even when the second and third date columns are filled in. Sorry for the false alarm, but I did say "supposedly" when I submitted the story yesterday at 3am PDT.
The quoted Info-ZIP web page has been dead for a full year (and the oft-quoted artpacks.acid.org site is just an alias for cdrom.com). The actual one is at ftp://ftp.info-zip.org/pub/info zip/Info-ZIP.html and is actively maintained. (And if Walnut Creek's webmaster ever gets off his butt, perhaps someday we'll have an http link again, too.)
And despite the implication of yerricde and others, Info-ZIP/zlib/etc. do not infringe on Katz's patent. Jean-loup spent a considerable amount of time and effort writing an algorithm that avoided all known patents, which is why everyone now uses zlib for so many things. (That's also why the patents section of the comp.compression FAQ list is so complete. But then, who bothers to read FAQs anymore?)
The PNG and MNG sites have not moved (yet); we're discussing that right now, in fact. It looks like it will be possible to move them over (i.e., freesoftware.com's contract does not appear to prohibit them from hosting the trees), and it's probably a good thing to do, but there are a number of questions and uncertainties that need to be worked out first--timing not least among them.
In addition, the link you posted for Info-ZIP is incorrect. Right now, most of http://www.freesoftware.com/ either redirects to http://www.cdrom.com/ or mirrors it; either way, the Info-ZIP tree on the latter is a 10-month-old broken mirror, and therefore so is anything that mirrors or redirects to it. The correct URLs for Info-ZIP and zlib are:
There is no local HTTP access to this tree currently. There are, however, mirrors overseas that provide HTTP service. Check the respective home pages, and if they don't mention "freesoftware.com" somewhere on them, they are not up to date! --
PNG support in M10 is terrible. PNGs render inline, but slowly. Alpha seems to be binary instead of 8 bits, and gamma is ignored completely.
Alpha is indeed binary-only (see bug 3013)--and not on the fast track to improve much--but gamma is fully supported and works correctly. As for speed, I haven't noticed any particular problems there, but libpng 1.0.5 includes MMX code for fast PNG decoding on Windows, and libpng 1.0.6 (or 1.1.0?) will include corresponding code for Linux and other gcc/gas targets.
I started this, so I feel obligated to make a few comments.
First, while some of the license provisions are regrettable (most notably the ones that effectively exclude South America and much of Asia), the fact remains that just about any source is better than no source. There are plenty of people for whom having a professionally coded, general-purpose, 3D code base will be a huge boon regardless of the license provisions. For everyone else, the situation really hasn't gotten any worse--and yes, I am taking into account the other, truly Open Source VRML projects like Chris Morley's LibVRML97/lookat browser. I don't see a license like this drawing away more than a tiny trickle of OSS developers, if even that.
Second, while VRML certainly never took the world by storm and is distinctly less lively now than it was at its height a couple of years ago, it remains a very useful tool for prototyping, displaying and exchanging 3D objects. I've used it at work to create quick, animated mockups of internal projects, and at home to explore what an addition to my house might look like. I even used it to demonstrate some trig functions once. Was it necessary for that? No, but the ability to zoom way, way out really got the point across about asymptotes and infinities. Some of the best content I've ever seen has been 3D scientific visualizations--hurricanes, planetary magnetospheres, USGS elevation data, Mars Pathfinder, Tenochtitlan, you name it. And Floops, Driftwood, Dilbert and MODvr may never have had big audiences, but they were more compelling than almost any other content I've seen on the Net.
Finally, if you're looking for Snow Crash-like VR, there's no question that something like ActiveWorlds comes much closer to the mark than just about anything in VRML--if only because of the vast scale that's possible in a database-driven, custom 3D application like AW. But don't hold your breath waiting for a Linux client. The company only has a few developers, and last I checked, everything was very tightly tied to RenderWare. Possibly there's a Linux port of that (RW) in the works, but I haven't heard about it.
Anyway, while I don't think too much of the current Web3D efforts to create a VRML successor (X3D), I do appreciate that they've managed to get some source code out. Yes, it would be a whole lot cooler with a real OSS license (NPL, say), but it's a reasonable first step. And who knows, maybe blaxxun will ease up on the terms after getting some constructive (i.e., non-flaming) feedback. One can hope.
This article couldn't have come at a better time. The old standbys (e.g., the Kirch paper) are great for details, but this wraps it up in a nice, bite-size chunk that even management can understand. Icing on the cake for a certain internal memo...
Opera supports PNG natively since version 3.51 (just before Christmas). It has some problems with transparency, though; see the browsers page for details.
GIMP does support the PNG and the alpha channel...but it is sort of very difficult to use. I only succeeded doing it once some time back and I cannot for life of me remember how to do it so I can achieve the transparent feature under GIMP.
From the GIMP section of Chapter 4 (I mistakenly said Chapter 5 in another reply): open an RGB image, right click on it and select Layers -> Add alpha channel, and edit away. For example, select the Lasso tool, go to Dialogs -> Tool Options... -> Feather checkbox and set some feather radius (for the width of the variable-transparency part), then draw a loop around something, invert the selection (right button -> Select -> Invert) and erase (Edit -> Clear). Or you can do gradients or whatever tickles your pickle.
What you cannot do is any sort of transparency with palette images, as I recall. That may have changed in 1.1, but I haven't heard about it. The last time I checked, the PNG plug-in did not appear to have any transparency support at all, and the GIMP image model does not lend itself well to PNG's RGBA-palette mode.
There is no separate alpha channel in 8-bit (palette-based) images. Instead, the palette effectively has RGBA entries rather than the usual RGB entries, thanks to the one-to-one correspondence between the PLTE chunk and the tRNS chunk. (This is basically how GIF does transparency, too, except that its "tRNS chunk" only holds one entry and can only be fully transparent.)
Anyway, the upshot is that the compression engine sees only WIDTH x HEIGHT bytes (or fewer, if pixels are packed 2 or more per byte) regardless of how many palette entries are partially or fully transparent. And since PNG's compression engine is better than GIF's (by roughly the same factor as gzip over compress), it can be smaller than the "corresponding" GIF. Of course, that GIF would only be an approximation to the RGBA-palette PNG image.
...hence the title of my article (which was actually submitted on 24 February, I think, less than a month after the ping story).
Another minor factoid: I had the penguin (or "pnguin") until Tim O'Reilly stepped in and said that penguins only go with Linux books (even though all of their Linux books to date use horses, sigh...). Anyway, my second choice was a duck, but the designer who does the covers apparently decided that wasn't cute enough and gave me a rat instead. Bargh. I still have the first draft with a penguin on the cover, though... he was pretty cute, too.
Version 3 only supported PNG via third-party plug-ins. Adobe added native support to 4.0. It's not very good support (and in some ways it got worse in 5.0), but they're aware of it and are finally working on fixing it for 6.0.
I devoted 40% of chapter 5 to Photoshop 4 and 5.:-)
libpng 1.0.3 apparently resolves whatever problems the Imlib folks were seeing. It does have one typo (misplaced parenthesis on line 181 of pngrutil.c; should be just before the || operator, not the "> 8"), but I haven't heard of any obvious visual bugs that can be traced to it. Certainly I haven't seen any yet.
Folks, please check the toolkits page for a number of PNG-supporting Java options, including the Advanced Imaging API from Sun/Javasoft. JAIA EA1 and EA2 had read-only support, but write support is coming in the next release, I believe.
And I'll be sure to add a link to the godlike Justin's toolkit, too; I wasn't aware of that until now. (Bad Justin. I guess it was all that VRML hacking.:-) )
Actually, no. IE 4.0b1 had PNG support in the spring of 1997, and 4.0 final was released in October 1997. Navigator got PNG support in version 4.04 in November 1997, with no warning whatsoever.
Little-known fact: at least two or three Netscape folks were on the PNG mailing list within two or three weeks of the beginning of the project (January 1995), but obviously nothing much came of that.
You're in luck. All of PNG's samples are unsigned integers, and grayscale covers the widest depth range: 1, 2, 4, 8 and 16 bits. (RGB and RGBA are both either 8-bit or 16-bit samples, i.e., 24/32-bit or 48/64-bit.)
No, not yet. Partly that's because the MNG spec hasn't completely settled down, partly it's because the spec is fairly complex, and partly it's because there's no libmng yet. But the spec is very close to being frozen; the recent changes have had to do with defining a "lite" version (two, in fact--"low complexity" and "very low complexity"), which addresses the second issue. And as for the third, Gerard Juyn has offered his MNGeye code as the basis for a libmng, so it's just a matter of some folks finding time to work on that. Volunteers are more than welcome, of course!:-)
Btw, once the Mozilla/SeaMonkey imagelib code settles down, it should be much easier to add new formats (like MNG) to Mozilla and thereby to Netscape. Expect to see MNG support at least in unofficial releases within a year or so. (Right now it's a *bitch* just getting the damn thing to compile and run correctly, at least under Linux. But it's rapidly getting better.)
FWIW, the GD home page has said that since 1995. I had an entry for it on one of the PNG pages ("coming") for three years before axing it a few months ago. I think Thomas is off doing other things and hasn't bothered to update his personal web pages for quite some time.
Get a better browser, and you'll see PNGs. I don't have server control (cdrom.com), but I do use the client-side OBJECT method. When your browser supports that correctly, the PNG home site will "magically" convert into a mostly PNG/JPEG site.
That said, I haven't bothered to convert tiny web graphics like the web balls; I may use POV-Ray to do so with true anti-aliasing. Too bad its alpha-output support isn't very good.
Oh, and check the home page again for the big blue "PNG Images" section.
That's what the PNG home site is for! You can find PNG-supporting image editors at http://www.cdrom.com/pub/png/pngaped.html and image viewers at http://www.cdrom.com/pub/png/pngapvw.html (the supported OSes are indicated for each entry--look for "Windows 9x/NT" in your case). There are also other pages for converters, 3D apps, browsers, etc.
Slashdot Mirror
(from Roger Zelazny's Creatures of Light and Darkness, copyright 1969)
M17 schedule: I checked the Mozilla milestones page 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. (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
Could you please contact me and let me know what the earliest alpha-supporting version was that you're completely certain of? I'd also love to add some screen shots of 4.0b3 or 3.1rc2 running on my PNG-alpha test page and the linked MagnoliaAlpha and IceAlpha pages.
Thanks,
So very, very simple... But wait! It does say so:
http://www.mozilla.org/projec ts/seamonkey/milestones/
Apparently Mozilla's milestones page is not to be trusted, even when the second and third date columns are filled in. Sorry for the false alarm, but I did say "supposedly" when I submitted the story yesterday at 3am PDT.
And despite the implication of yerricde and others, Info-ZIP/zlib/etc. do not infringe on Katz's patent. Jean-loup spent a considerable amount of time and effort writing an algorithm that avoided all known patents, which is why everyone now uses zlib for so many things. (That's also why the patents section of the comp.compression FAQ list is so complete. But then, who bothers to read FAQs anymore?)
In addition, the link you posted for Info-ZIP is incorrect. Right now, most of http://www.freesoftware.com/ either redirects to http://www.cdrom.com/ or mirrors it; either way, the Info-ZIP tree on the latter is a 10-month-old broken mirror, and therefore so is anything that mirrors or redirects to it. The correct URLs for Info-ZIP and zlib are:
There is no local HTTP access to this tree currently. There are, however, mirrors overseas that provide HTTP service. Check the respective home pages, and if they don't mention "freesoftware.com" somewhere on them, they are not up to date!
--
(And for those who don't track Freshmeat, the zlib home page is now ftp://ftp.freesoftware.com/pu b/infozip/zlib/zlib.html. Please check that first before reporting bad links on other copies.)
Alpha is indeed binary-only (see bug 3013)--and not on the fast track to improve much--but gamma is fully supported and works correctly. As for speed, I haven't noticed any particular problems there, but libpng 1.0.5 includes MMX code for fast PNG decoding on Windows, and libpng 1.0.6 (or 1.1.0?) will include corresponding code for Linux and other gcc/gas targets.
First, while some of the license provisions are regrettable (most notably the ones that effectively exclude South America and much of Asia), the fact remains that just about any source is better than no source. There are plenty of people for whom having a professionally coded, general-purpose, 3D code base will be a huge boon regardless of the license provisions. For everyone else, the situation really hasn't gotten any worse--and yes, I am taking into account the other, truly Open Source VRML projects like Chris Morley's LibVRML97/lookat browser. I don't see a license like this drawing away more than a tiny trickle of OSS developers, if even that.
Second, while VRML certainly never took the world by storm and is distinctly less lively now than it was at its height a couple of years ago, it remains a very useful tool for prototyping, displaying and exchanging 3D objects. I've used it at work to create quick, animated mockups of internal projects, and at home to explore what an addition to my house might look like. I even used it to demonstrate some trig functions once. Was it necessary for that? No, but the ability to zoom way, way out really got the point across about asymptotes and infinities. Some of the best content I've ever seen has been 3D scientific visualizations--hurricanes, planetary magnetospheres, USGS elevation data, Mars Pathfinder, Tenochtitlan, you name it. And Floops, Driftwood, Dilbert and MODvr may never have had big audiences, but they were more compelling than almost any other content I've seen on the Net.
Finally, if you're looking for Snow Crash-like VR, there's no question that something like ActiveWorlds comes much closer to the mark than just about anything in VRML--if only because of the vast scale that's possible in a database-driven, custom 3D application like AW. But don't hold your breath waiting for a Linux client. The company only has a few developers, and last I checked, everything was very tightly tied to RenderWare. Possibly there's a Linux port of that (RW) in the works, but I haven't heard about it.
Anyway, while I don't think too much of the current Web3D efforts to create a VRML successor (X3D), I do appreciate that they've managed to get some source code out. Yes, it would be a whole lot cooler with a real OSS license (NPL, say), but it's a reasonable first step. And who knows, maybe blaxxun will ease up on the terms after getting some constructive (i.e., non-flaming) feedback. One can hope.
Greg Roelofs
This article couldn't have come at a better time. The old standbys (e.g., the Kirch paper) are great for details, but this wraps it up in a nice, bite-size chunk that even management can understand. Icing on the cake for a certain internal memo...
Check the W3C's current working draft for SVG (Scalable Vector Graphics).
Opera supports PNG natively since version 3.51 (just before Christmas). It has some problems with transparency, though; see the browsers page for details.
GIMP does support the PNG and the alpha channel...but it is sort of very difficult to use. I only succeeded doing it once some time back and I cannot for life of me remember how to do it so I can achieve the transparent feature under GIMP.
From the GIMP section of Chapter 4 (I mistakenly said Chapter 5 in another reply): open an RGB image, right click on it and select Layers -> Add alpha channel, and edit away. For example, select the Lasso tool, go to Dialogs -> Tool Options... -> Feather checkbox and set some feather radius (for the width of the variable-transparency part), then draw a loop around something, invert the selection (right button -> Select -> Invert) and erase (Edit -> Clear). Or you can do gradients or whatever tickles your pickle.
What you cannot do is any sort of transparency with palette images, as I recall. That may have changed in 1.1, but I haven't heard about it. The last time I checked, the PNG plug-in did not appear to have any transparency support at all, and the GIMP image model does not lend itself well to PNG's RGBA-palette mode.
There is no separate alpha channel in 8-bit (palette-based) images. Instead, the palette effectively has RGBA entries rather than the usual RGB entries, thanks to the one-to-one correspondence between the PLTE chunk and the tRNS chunk. (This is basically how GIF does transparency, too, except that its "tRNS chunk" only holds one entry and can only be fully transparent.)
Anyway, the upshot is that the compression engine sees only WIDTH x HEIGHT bytes (or fewer, if pixels are packed 2 or more per byte) regardless of how many palette entries are partially or fully transparent. And since PNG's compression engine is better than GIF's (by roughly the same factor as gzip over compress), it can be smaller than the "corresponding" GIF. Of course, that GIF would only be an approximation to the RGBA-palette PNG image.
...hence the title of my article (which was actually submitted on 24 February, I think, less than a month after the ping story).
Another minor factoid: I had the penguin (or "pnguin") until Tim O'Reilly stepped in and said that penguins only go with Linux books (even though all of their Linux books to date use horses, sigh...). Anyway, my second choice was a duck, but the designer who does the covers apparently decided that wasn't cute enough and gave me a rat instead. Bargh. I still have the first draft with a penguin on the cover, though...
he was pretty cute, too.
Version 3 only supported PNG via third-party plug-ins. Adobe added native support to 4.0. It's not very good support (and in some ways it got worse in 5.0), but they're aware of it and are finally working on fixing it for 6.0.
:-)
I devoted 40% of chapter 5 to Photoshop 4 and 5.
libpng 1.0.3 apparently resolves whatever problems the Imlib folks were seeing. It does have one typo (misplaced parenthesis on line 181 of pngrutil.c; should be just before the || operator, not the "> 8"), but I haven't heard of any obvious visual bugs that can be traced to it. Certainly I haven't seen any yet.
See either http://www.cdrom.com/pub/png/pngs.html or http://www.cdrom.com/pub/png/pngs-img.ht ml for some transparent PNG images (especially the bottom one), using either OBJECT or IMG, respectively. There will be at least three more as soon as I have time to add them to the web pages. Two are already available in the img_png subdirectory: IceAlpha-sml.png and RedbrushAlpha-sml.png, both by Pieter van der Meulen. (The third one is an excellent shot of an owl, and I may add a magnolia tree, too. All are 8-bit RGBA-palette images, btw.)
Oh, and http://www.cdrom.com/pub/png/pngpic2.html has more PNG images, though not with transparency.
Folks, please check the toolkits page for a number of PNG-supporting Java options, including the Advanced Imaging API from Sun/Javasoft. JAIA EA1 and EA2 had read-only support, but write support is coming in the next release, I believe.
:-) )
And I'll be sure to add a link to the godlike Justin's toolkit, too; I wasn't aware of that until now. (Bad Justin. I guess it was all that VRML hacking.
> I believe NS had it before IE.
Actually, no. IE 4.0b1 had PNG support in the spring of 1997, and 4.0 final was released in October 1997. Navigator got PNG support in version 4.04 in November 1997, with no warning whatsoever.
Little-known fact: at least two or three Netscape folks were on the PNG mailing list within two or three weeks of the beginning of the project (January 1995), but obviously nothing much came of that.
> I need 16bit unsigned greyscale.
You're in luck. All of PNG's samples are unsigned integers, and grayscale covers the widest depth range: 1, 2, 4, 8 and 16 bits. (RGB and RGBA are both either 8-bit or 16-bit samples, i.e., 24/32-bit or 48/64-bit.)
> Help, somebody! Do the browsers support MNG ???
:-)
No, not yet. Partly that's because the MNG spec hasn't completely settled down, partly it's because the spec is fairly complex, and partly it's because there's no libmng yet. But the spec is very close to being frozen; the recent changes have had to do with defining a "lite" version (two, in fact--"low complexity" and "very low complexity"), which addresses the second issue. And as for the third, Gerard Juyn has offered his MNGeye code as the basis for a libmng, so it's just a matter of some folks finding time to work on that. Volunteers are more than welcome, of course!
Btw, once the Mozilla/SeaMonkey imagelib code settles down, it should be much easier to add new formats (like MNG) to Mozilla and thereby to Netscape. Expect to see MNG support at least in unofficial releases within a year or so. (Right now it's a *bitch* just getting the damn thing to compile and run correctly, at least under Linux. But it's rapidly getting better.)
FWIW, the GD home page has said that since 1995. I had an entry for it on one of the PNG pages ("coming") for three years before axing it a few months ago. I think Thomas is off doing other things and hasn't bothered to update his personal web pages for quite some time.
Get a better browser, and you'll see PNGs. I don't have server control (cdrom.com), but I do use the client-side OBJECT method. When your browser supports that correctly, the PNG home site will "magically" convert into a mostly PNG/JPEG site.
That said, I haven't bothered to convert tiny web graphics like the web balls; I may use POV-Ray to do so with true anti-aliasing. Too bad its alpha-output support isn't very good.
Oh, and check the home page again for the big blue "PNG Images" section.
That's what the PNG home site is for! You can find PNG-supporting image editors at http://www.cdrom.com/pub/png/pngaped.html and image viewers at http://www.cdrom.com/pub/png/pngapvw.html (the supported OSes are indicated for each entry--look for "Windows 9x/NT" in your case). There are also other pages for converters, 3D apps, browsers, etc.