An initialization of Portable Network Graphics, PNG is a graphical file format designed to be patent free. Find more info at http://www.libpng.org/ . Files most frequently are found with the name extension .png .
It features lossless compression (see zlib).
The Img package supports this format.
See also: Writing PNG files, Writing PNG Comments, Reading PNG image dimensions, Reading PNG Comments, Reading PNG Timestamps.
As of 22 May 2004, the png package is a tcllib module that incorporates the above functions plus a few more. Documentation can be found at http://tcllib.sourceforge.net/doc/png.html
Apparently, this image format is riddled with bugs: [L1 ]
escargo 7 Aug 2004 - Not the image format, but the PNG library, known as libPNG, that implements functions for accessing and manipulating PNG files. Since the flaws are (at least primarily) buffer overruns because of inadequate bounds checking, Tcl code should not be affected by them.
Peter Newman 8 August 2004:-
- Does Img::png use libPNG? (DKF: Yes.)
- If it does, has anyone really checked that Img::png is indeed not affected by this bug? In other words can I, as a Tcl developer, release software that uses Img::png - in the certain knowledge that it isn't affected by that bug? (DKF: No, but you can build Img with the latest libpng and (hopefully) avoid the bug that way.)
Peter Newman 8 August 2004: png is also riddled with bugs in another sense. In that while the very latest Web Browser versions (released in the last year or two,) will generally handle transparent pngs correctly - very few general purpose graphic image viewers will. In fact, I haven't yet found one. (Even the latest version of the otherwise excellent XnView just doesn't want to know.)
The exception is Tcl however. Using the Tcl tools like canvas and Img - you can build an image viewer that displays transparent pngs correctly - as A little image viewer - when fed the transparency test images from the png web site, proves.
One of the major motivations for using pngs, is to avoid the GIF patent problems. But since I understand that this GIF patent has now expired - and since probably the majority of currently in use programs that could be asked to display transparent pngs won't do so properly (including Netscape Navigator (the last version before Mozilla) - and Internet Explorer 5) - it suggests to me that if you're using transparent pngs, maybe you should be using transparent GIFs instead.
They'll reach a wider audience - though png still has the advantage that it handles True Colour images - whereas GIF is palleted 256 colours max.
DKF: PNG actually lets you specify 32-bit RGBA (with a full alpha channel) so it is way more sophisticated than GIF (256 colours, of which one may be nominated to be transparent.)
LV I'm uncertain how one would define bug so that it included the case where applications which do not use all the options of a library that exist...
Peter Newman 11 August 2004: Yeah I agree. I just used the term riddled with bugs because the person before me had used that term. But it's a drawback or problem with using pngs. And from the end-user's point of view, it looks like a bug. Most image viewers that can't handle transparency (which is every Windows freeware/shareware image viewer I tried, other than the Gimp,) display the transparent bits in black. They do that with transparent tgas (targa) too.
And you can still claim it's a bug - since if the product claims to support pngs, but can't handle transparent ones, then it's surely buggy and incomplete. Bill Gates would call it a feature... A lawyer would call it false advertising...
LV Well, I would agree that libraries or programs claiming they support png , and that don't specify limitations, have a bug if they don't support all the standard. But I would not say that the image format itself has a bug in that case.
I've always wondered why pngs have never really caught on - despite their advantages over GIFs, and their widespread approval. You rarely get them on the net - except perhaps on hard-core Linux sites. Perhaps this poor support - though it's not png's fault (*) - is the reason. (*) Or is it? Maybe many opt out of supporting png transparency because libPNG makes it too complicated or something? I'm not saying libPNG does this. I was just wondering.)
And finally it may well be a bug with libPNG. See the png web site page entitled Miscellaneous Transparent PNG Images using IMG Tags [L2 ] - where it says:-
...This set is provided courtesy of Stefan Schneider. If the two images on the right are transparent but the one on the left has a black background, the browser was probably compiled with a buggy version of libpng. The bug is fixed in libpng 0.96 and later, and a trivial patch is available (for browser implementors, that is) for earlier versions of libpng.
Peter Newman 11 August 2004: I made the claim above that Tcl'ers don't have problems displaying transparent pngs - because the Tcl tools handle this correctly. But this may not be 100% true.
A little image viewer displays the transparent test images from the png web site correctly. But I created a transparent png - using Img::png - that displays correctly in A little image viewer - but not in Internet Explorer 5 - even though Internet Explorer 5 displays the png web site transparency test images correctly.
But whether the problem's with Internet Explorer 5 - or whether it's with Img::png - I don't know.
DKF: The PNG format is very complex (too complex for me to explain now; read the spec if you want to find out) with support for features that only require optional comprehension by reading code, and there are actually multiple mechanisms for doing transparency (IIRC, one is GIF-like and one is a full alpha-channel). In particular, the chunk type for non-trivial alpha channels is nothing close to universally supported (one of the conspicuous omissions is the Win API which has a PNG reader built in in the same place as its BMP reader but does not seem to know about advanced transparency.)
RS In Playing with circuits it was found that PNG images produced with Img may come out very bad on Mozilla (Netscape and IE 5 do it right). Check these two, both produced with Img 1.3:
MNO I assume this must be version or OS dependent - Mozilla 1.7.1 on Win2k renders both images virtually identically (the only difference being that the PNG has a lighter background, but I see this also in IE (5.5)).