png
PNG is an initialism 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 and Pixane Tcl packages support this format. TkPng offers a self-contained (only depends on zlib) implementation.
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. See [L1 ] for documentation.
DKF: Tk now has PNG support, based (strongly) on tkpng. Will form part of 8.6 (slipped the 8.6b1 release though).
AMG: Initialism? I thought it was an acronym. My understanding is that the difference between initialisms and acronyms is that each letter of an initialism is pronounced separately whereas acronyms are run together like words. FBI is an initialism, NATO is an acronym. I've always pronounced PNG as "ping", making it an acronym. I guess if you call it "P-N-G", it's an initialism.
Apparently, this image format is riddled with bugs: [L2 ]
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.)
Duoas Just as a side note: GIFs are not limited to 256-colors. You can make TrueColor GIFs easily. The problem is that everyone believes that they are limited to 256 colors, and a lot of application code (most notably in browsers) will actually add a short pause (typically 1/10th second) between image blocks when no pause is specified. An equivalent (colormapped) PNG, however, still has a far superior compression ratio than any GIF. (Anywhere from 5% to 25% better [usually 15% to 20% in my experience].)
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 [L3 ] - 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)). VK - Mozilla 1.7.5, Win2k, behaves exactly same, i.e. all is good.
DJE When I make PNG image files using img::png, to make the colors look about the same in firefox or ImageMagick, I set the gamma to 0.685 using ImageMagick, but the png looks correct in the gimp without this adjustment.
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:01The 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:01Note 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 you've got, maybe some browsers are electing to honour this (presumably invalid,) matte colour. And others to ignore it.
AF in pngs alpha information is stored in a separate place from the rest of the image information so if a renderer doesn't support the alpha chunk you will see all of the image pixels.
Peter Newman 25 August 2004: To my knowledge, IE5, IE5.5 and Mozilla all display transparent images. One can check this out by viewing the transparency test images on the PNG web site - and in my testing, they all display them correctly.
The images that aren't being displayed correctly, are png's written out by Img::png. One is transparent, the other isn't. And in both cases a light grey (which appears to me to be grey74) is displayed where (in the case of dodgy.png, it should be transparent - and in the case of circuit.png, it should be silver).
I don't believe the fault is with the renderer; it's with Img::png. After all, circuit.png has no transparency. So the renderer's lack of support of support for transparency/alpha doesn't explain why it arbitrarily replaces silver with grey74.
I never specified the grey 74 matter colour, #DFDFDF border colour or the grey100 background colour. And I doubt that RS specified those colours either. But Img::png has written them out, and it appears to be confusing the renderers, causing some of them to trash the image.
RS: No, I produced the image as described on Playing with circuits - the only explicitly given colors were yellow and white, the rest (canvas background, lines etc. in black) were just Tk defaults.
AK: Regarding the usage of libpng in in img::png - For 1.3 I updated libpng to the most current version, 1.2.6rc5, fixing the latest crop of security bugs. I cannot comment on the background, matte, etc. stuff. While I am doing releases and make sure it compiles, etc. I haven't looked that much at the code implementing the various formats. However if someone finds a bug I will be glad to accept fixes. Just enter them in the tkimg bug tracker at SF. And please, please provide testcases which demo the bug, and that the fix is correct. Tkimg has a testsuite, but it is very small, marginal IMHO. I would like for it to become larger.
Peter Newman 25 August 2004. Thanks AK. I'll put that bug report in. Though might do a bit more research first, to try and nail it down better.
Michael Heca 2004-09-27: TkImg has a bug in transparency handling. All alpha values are composite on black image. I put bug and fix on sourceforge.
DKF: There are two general phases to alpha compositing in Tk's photo image guts. The first kind is what happens when images are overlaid on top of an existing image, and the second is when an image is drawn on the screen. And as far as I can tell, Tk now gets it right (I've looked at some of the literature on alpha compositing, so I think I am qualified to say that Tk gets this right now) but I don't know if the released versions get it right yet. Image compositing is important, but not so important as to force an interim or patch release. :^D
Michael Heca: Tk does it right, but Tkimg uses composite mode when copying image to Tk photo.
alove 21 Apr 2005 -- A few people here asked why the use of PNG format is not widespread. The reason is, Internet Explorer does not fully support PNG transparency. Go to this site http://entropymine.com/jason/testbed/pngtrans/ using IE and have a look at the tests -- none of the images show any transparency. Specifically, to quote the Wikipedia, "Microsoft Internet Explorer (for Windows) supports binary transparency but not alpha channel transparency." ( http://en.wikipedia.org/wiki/PNG ). This is true of all IE browser versions. All other browsers have full PNG support so it's somewhat of a mystery why Microsoft does not.
There are rumors that the next Internet Explorer browser due out this summer will support PNG alpha transparency but that remains to be seen.
For an in-depth explanation of PNG and its support in Photoshop, web browsers and comparison to the GIF format, check out this link: http://user.fundy.net/morris/redirect.html?photoshop27.shtml .
Note that Img contains the package pngtcl, which is a Tcl wrapper around the PNG C library.
AMG: I'm having trouble with this PNG produced by The GIMP.
Tk's built-in PNG support (post-8.6b1) gives me this error message when I try to read it: "unfinalized data stream in PNG data". Is this a bug in Tk or The GIMP? I don't know enough about PNG to debug this problem.
DKF: Damn! I'd forgotten about the possibility of multiple IDAT sections, and so put a sanity check in the wrong place. Now fixed in the HEAD.
AMG: Thanks for the fix! Unfortunately, HEAD doesn't currently build in MinGW. I'd back-port your fix into the version that was previously working for me, but I don't have that source tree on this computer. See the bug report on Sourceforge [L4 ].
AMG: Update. The build works now. I think my virus scanner hosed me the first time through. I confirmed that DKF's fix works: the above image loads fine.
TOMK: Note that you can now write PNG files without using Tk (see Write PNG File (without using Tk)).