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: [http://zdnet.com.com/2100-1105_2-5298999.html] ''[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:- 1. '''Does Img::png use libPNG?''' ([DKF]: Yes.) 1. 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'' [http://www.libpng.org/pub/png/pngs-img.html] - 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: [GIF]: [http://mini.net/files/circuit.gif] [PNG]: [http://mini.net/files/circuit.png] [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)). ---- Peter Newman 23 August 2004: [RS]'s dodgy PNG, immediately above, is interesting. The dodgy PNG I created with Img::png (above further) also displays a light grey background when displayed in IE5 - when it's supposed to be transparent. And feeding that image to Image Magick's ''identify'', I get:- Image: dodgy.png Format: PNG (Portable Network Graphics) Geometry: 103x45 Class: DirectClass Type: true color with transparency Depth: 8 bits-per-pixel component Opacity: ( 0, 0, 0,255) #000000FF Colors: 339 2560: ( 0, 0, 0,255) none 1: (129, 75, 75, 0) #814B4B00 1: (133, 79, 79, 0) #854F4F00 1: (137, 82, 82, 0) #89525200 (...heaps of other colours omitted...) 13: (253,253,253,255) #FDFDFDFF 10: (254,254,254,255) #FEFEFEFF 55: (255,255,255,255) #FFFFFFFF Gamma: 1 Resolution: 72x72 pixels Filesize: 2.4kb Interlace: None Background Color: grey100 Border Color: #DFDFDF00 Matte Color: grey74 Dispose: Undefined Iterations: 0 Compression: Zip signature: 1abced1c92a7fa84da51ae93f12f02f045aa4f526927beb3c6f5879ae3e12bdc Tainted: False User Time: 0.050u Elapsed Time: 0:01 The interesting things are the ''background'', ''border'' and ''matte'' colours. I never specified any of these. So why did Img::png put them there? And my light grey background that's supposed to be transparent looks very like the ''grey74'' matte colour to me. Further, I'm not surprised the image viewer (or the programmer writing it,) is a little confused by this image. What's the meaning of the ''background'', ''border'' and ''matte'' colours as regards the transparent pixels. It appears to me as if some image viewers/programmers have decided that a ''matte'' layer comes between the image, and whatever is behind it. And others have decided that it doesn't. Presumably, reading the PNG spec would tell us whether it's the image viewer programmers who are getting it wrong, or whether it's Img::png writing out a dodgy or ambiguous spec. ---- Peter Newman 24 August 2004: It definitely looks like we have a '''bug in Img::png'''. Here's what Image Magick's ''identify'' says about [RS]'s ''circuit.png'':- Image: circuit.png Format: PNG (Portable Network Graphics) Geometry: 204x104 Class: DirectClass Type: palette Depth: 8 bits-per-pixel component Colors: 4 628: ( 0, 0, 0) black 156: (255,255, 0) yellow 19911: (192,192,192) silver 521: (255,255,255) grey100 Gamma: 1 Resolution: 72x72 pixels Filesize: 1.4kb Interlace: None Background Color: grey100 Border Color: #DFDFDF Matte Color: grey74 Dispose: Undefined Iterations: 0 Compression: Zip signature: 2f024e394c140df1deb777070036e8c7db844f54e9eb0651b014ef7d67b01cd3 Tainted: False User Time: 0.210u Elapsed Time: 0:01 Note the same ''grey74'' matte colour and ''#DFDFDF'' border colour that appear in my ''dodgy.png'' - even though I never specified any such colours. And while ''grey100'' is a reasonable default background colour - ''grey74'' and ''#DFDFDF'' seem to be very arbitrary choices. On my IE5, ''circuit.png'' displays with a light gray background - which looks very like the ''grey74'' matter colour that appears in my ''dodgy.png'' where it's supposed to be transparent. In other words, with ''circuit.png'' IE5 seems to be displaying the ''grey74'' matter colour where it's supposed to be displaying silver. Is it possible that Img::png forgot to initialise these values correctly, before writing out the png file. And as a result, the image viewers displaying them are getting confused. Since error handling with Web Browsers seems to be ''Don't complain, just do the best with what youve got'', maybe some browsers are electing to honour this (presumably invalid,) ''matte colour''. And others to ignore it. [[ [Category Graphics] | [Category Acronym] | [Category Package] ]]