I was taken by surprise when the resulting file was larger than a standard libpng implementation would produce. When I converted the original to a Windows BMP and tried again the output file was much smaller. I'm intrigued to find out what's going on in this case.
55908 -- original image (Adobe ImageReady with gAMA and tEXt chunks)
67793 -- PNGOUTWin (default settings)
49046 -- IrfanView 3.99 without the plugin
45778 -- IrfanView 3.99 using the PNGOUT plugin (default settings)
45740 -- PNGOUTWin (default settings) from a 24-bit Windows BMP
Awesoken at
Re: PNGOUTWin - a strange anomaly
If you right-click or hover over the line in PNGOUTWin, it shows the settings used. PNGOUT command line generates the same behavior if you specify the new /ks option. It looks like my autodetection code is thinking the file has 1023 (or probably more) Huffman blocks. Either Adobe ImageReady is somehow using that many blocks (with much less overhead than PNGOUT), or I have a bug with my autodetection code. I will look at the file later.
counting_pine at
Wow - 1251 Fixed Huffman blocks, 86 Dynamic Huffman blocks. 1337 (!) in total. I guess since most of the blocks are fixed Huffman, their header is much smaller so you can have loads of them without much overhead.
Since the height is 668, it looks like it's using 2 blocks for each row, and one extra, presumably just to be the "last block". Stupidly, the second block in each row is completely empty.
Nice going, Adobe.
Kerrypng at
I found another problem image. This one is RGB with gAMA and cHRM. No software identification, but I don't think it's GIMP:
24768 -- IrfanView 3.99 using the PNGOUT plugin (default settings)
24720 -- PNGOUTWin (default settings) from a 24-bit Windows BMP
24125 -- Web Image Guru
I checked them with TweakPNG -- they're all RGB with 482 colors. I'm using PNGOUTWin 1.0.1 - Build 61206, 12/11/2006. Is this down to more pesky irregularities in the huffman blocks? If so, will there be a new build soon?
EDIT: I forgot to mention that I always have Web Image Guru set to F0 for RGB -- no filters.
Edited by Kerrypng at
counting_pine at
It looks like another PNG compressed with Adobe's award-winning compression software - 1471 blocks this time. PNGOUT has no quick way of telling that 1471 blocks is a ridiculous amount for this file, and can't compress small blocks very efficiently, so I suggest for files like this you use the "Custom" block split threshold. Set it to 256 - this is the default for non-PNG files, so it should give the same result as if you convert it to a BMP beforehand.
Kerrypng at
I emailed David at ardfry.com about this. He and Ken are working on a remedy. I don't actually need to work from Adobe originals, but I would be interested to know how to discover the true number of blocks in a file. When I hovered the mouse over the line in PNGOUTWin, as Ken suggested, it said "Huffman Blocks: 1024".
counting_pine at
PNGOUTWin only supports up to 1024 blocks, which is usually more than enough to optimally compress a PNG file. If your PNG has fewer blocks than that, then PNGOUTWin can tell you how many there are. Otherwise, if it's more, then there's a good chance it's compressed by Adobe, in which case it looks like the number of blocks is twice the height, plus one.
But if you want a definitive answer, your only real option is to decompress the file yourself and count the blocks. Ken suggests one method, here:
Awesoken said at
Is there any other way to get the number of blocks?
No, not in PNGOUT. If you want a utility that simply displays the number of blocks, you'll have to write it yourself. An easy way to do that would be to take my KPLIB.C (a recent version is included with POLY2VOX), and simply print "numhufblocks" after using kpzload() to load the image.
Kerrypng at
Thanks for quoting Ken's block counting method. It appears that Adobe Photoshop for the Mac generates blocks differently to the Windows version. PNGOUTWin reduces the file sizes. You can find examples here:
When Microsoft released a version of Internet Explorer for the Mac, a long time ago, it supported PNG alpha transparency. Meanwhile, Windows versions of Internet Explorer failed to support alpha transparency right up to the recent release of IE7. The same kind of schizophrenia seems to be going on with Adobe.
I went looking for more example photoshop images. I found Russian site selling plug-in filters for Adobe Photoshop. The following image doesn't contain the usual gAMA and cRHM chunks:
http://photoshop.msk.ru/asps/ma.png
At first I thought it was simply a regular Photoshop file with all ancilliary chunks removed, but the hover check said 10 Huffman blocks. So it's a mystery file. Neither PNGOUTWin or the standard libpng implementation can output the image in a file that small.
counting_pine at
I don't know what generated the file, but the compression method it used only used frequency based Huffman compression (no pattern matching). The blocks each contain 32767 bytes (except the last one). It looks like zlib was used for the compression - you can get the same size file by running optipng -zc1 -zm9 -zs2 -f5 on it.
This is one of those files that compress better without the standard pattern matching algorithms, because there isn't much repetition in the file, and using the length/distance codes only upsets the frequencies of each literal code value, making it less compressable.
In any case, PNGOUTWin also lets you use Huffman compression - in the trials dialog, check the "Huffman only" KSFlate strategy box. It compresses the file better than the original, and actually runs quicker.
Kerrypng at
I checked "Huffman only" in the KSFlate strategy box and reduced the file size by a slender margin to 158031 bytes. So although this image is used to illustrate a Photoshop filter, it looks like they compressed it with Optipng, or something similar, to save bandwidth. Thanks for checking it out.
Kerrypng at
Build 61229, released on 12/31/2006, solved the Adobe Photoshop block-bloat problem. Try the hover display with the two regular Photoshop images in this thread. The "ma.png" example, which required "Huffman only," isn't a fair test for the default settings.