Forum archive

PNG optimization - GIMP vs PNGOUT

Return to forum index

• The Gimp at 2005-03-23 06:58
  The following 87 byte PNG (reproduced here in hex) was produced by using GIMP. It's a single-color 1x11 pixel image with an alpha channel that makes it appear as a gradient when it is displayed against a background that has a different color. Can anyone think of a way of reducing the size of the file even further? I was unable to do that with PNGOUT.
  
  89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 00 00 00 01 00 00 00 0E 08 06 00 00 00 EE 43 76 5C 00 00 00 1E 49 44 41 54 08 D7 63 F8 FB E3 F1 5F 26 06 06 86 CF 4C 0C 0C 0C EF B0 10 EF 71 49 20 11 00 7E A5 10 0C 6D A8 E8 69 00 00 00 00 49 45 4E 44 AE 42 60 82
• Awesoken at 2005-03-23 13:41
  You can run OPTIPNG or PNGCRUSH on your file to turn it into 85 bytes. This image compresses best with "Fixed Huffman" because it is so small. PNGOUT only uses dynamic Huffman - that's why it can't compete. If I enabled the "Fixed Huffman" strategy, PNGOUT would also give an 85 byte file. In fact, I believe 85 bytes is the smallest possible file size for this particular image. : )
• The Gimp at 2005-03-24 21:24
  Thanks a lot, Ken!
• Martin at 2005-04-06 09:17
  I have many small PNGs (e. g. 80x15 pixels with only a few colors). Here's an example: http://img53.exs.cx/img53/2935/sendofix7ba.png
  Could those images be compressed further with the "fixed Huffman" strategy you mentioned? (I tried PNGcrush and OptiPNG with the image above, they didn't lower the filesize, but maybe with other images like that?) And if so, would you mind implementing such an option in PNGOUT? ^^
• Awesoken at 2005-04-06 12:37
  Actually, your 80x15 file compresses best with dynamic Huffman. I was able to knock off 1 byte using my randomized initial Huffman table hack (which is not in the public version) and running a few hundred trials with it:
  

  89504E470D0A1A0A0000000D49484452000000500000000F08030000004417B8
  
  BD0000000C504C54453E31A2FFFFFF6666667C70DAB3CAC95C00000066494441
  
  54785ED592410A00210C0333FAFF3F2F3D04A9D2C3622F0E45028521A81ACD68
  
  D04A08F51B66C54342C087246709BCF42A09610B16A2002BCEB18DD49018C724
  
  4C4D3884B0AC7BC342989A70DF10507D8716AE6C054EC0ED2B330DEFFDC34E42
  
  D8CC07F0A1058E54E334770000000049454E44AE426082

  
  
  I could implement options for fixed Huffman (aka: RFC-1951, BTYPE=01), but I don't think my algorithm would have any advantage over the other programs (advpng, advdef, optipng) in this mode. When I compress PNG files, I actually use a combination of all these programs until satisfied. Sure, implementing this in PNGOUT would make for less typing... but fixing it is not a priority for me right now.
• counting_pine at 2005-04-06 23:46
  I managed to knock two bytes off the original image by rearranging the palette, giving the coveted palette index 0 to the grey border.
  I don't know if any more can be knocked off with Ken's publicly unavailable compression methods.
  

  89504E470D0A1A0A0000000D49484452000000500000000F08030000004417B8
  
  BD0000000C504C54456666663E31A27C70DAFFFFFF25DB0E4C00000065494441
  
  5428CFD592410AC0200C048DF3FF3FB7392CED567228E6E2206641181675F443
  
  2B298CDF302B0E1202DA224239870E75644294C085448214EB920D6B784F4517
  
  7A1316212FEBB76121B426EC3704A2BE43099F2C054AC0EE2B3305E7FDC35646
  
  3B170DFB07386D837D9F0000000049454E44AE426082

  182 bytes
  
  By the way, a lot of programs (including bmp2png and OptiPNG) use the zLib Deflate algorithm, which automatically attempts Fixed Huffman compression. It doesn't usually get the best results, only when the file is "very, very small", or "quite small and very compressible".
  For example, Pinstripe.bmp, which comes with Win9x and is just a 32x32 image of vertical lines, compresses better with Fixed Huffman.
  (FYI Fixed Huffman can get sendofix.png down to 193 bytes, which is pretty close, but it's still a reasonably big margin, considering the small file size)
  
  I think, of all the main PNG optimisers, OptiPNG is the only one that tries Fixed Huffman. AdvDef and AdvPNG use the 7-zip Deflate algorithm, which doesn't seem to try it, and obviously PNGOut doesn't at present.
  
  Note that, although OptiPNG tries Fixed Huffman, its algorithm doesn't necessarily produce Fixed Huffman blocks of optimal size. This is probably only something that can be achieved with something like PNGOut's algorithm.
• Martin at 2005-04-07 00:13
  I don't really know what fixed and dynamic Huffman actually does, I just wondered if fixed Huffman could produce better results in general with small images. In any case, I'm happy with the compression rates PNGOUT already achieves :)
  
  BTW, here's some PHP I wrote to transform hexcode into (PNG) images:
  

  <?php
  
  $hex = '89504E470D0A1A0A0000000D49484452000000500000000F08030000004417B8
  
  BD0000000C504C54456666663E31A27C70DAFFFFFF25DB0E4C00000065494441
  
  5428CFD592410AC0200C048DF3FF3FB7392CED567228E6E2206641181675F443
  
  2B298CDF302B0E1202DA224239870E75644294C085448214EB920D6B784F4517
  
  7A1316212FEBB76121B426EC3704A2BE43099F2C054AC0EE2B3305E7FDC35646
  
  3B170DFB07386D837D9F0000000049454E44AE426082';
  
  
  
  header('Content-Type: image/png');
  
  $hex = preg_replace('/[^0-9a-f]/i', '', $hex); // remove every non-hex character
  
  $length = strlen($hex);
  
  for($i=0;$i<$length;$i+=2) {
  
    echo chr(hexdec(substr($hex, $i, 2)));
  
  }
  
  ?>

• Awesoken at 2005-04-07 03:39

  I managed to knock two bytes off the original image by rearranging the palette, giving the coveted palette index 0 to the grey border.

  Nice work! Was that an intelligent guess or just trial & error?

  I don't know if any more can be knocked off with Ken's publicly unavailable compression methods.

  I can answer that :))
  
  

  89504E470D0A1A0A0000000D49484452000000500000000F08030000004417B8
  
  BD0000000C504C5445666666FFFFFF7C70DA3E31A27787EFCB00000063494441
  
  54785ED592C10A401114050DFFFFCF8FC5D4BB6421776312476A3AA1E4432A43
  
  D88EA1EE78480838F59D792C1E7A1484300585B4012AD6A18DD0B0AFC6288C4D
  
  5884FCAC73C38D3034E1BE21D0F677A810332A3001B7AF4C15DEFB87A994743E
  
  96C208A2AD6716A60000000049454E44AE426082

  
  
  180 bytes - thanks to your updated palette.
• counting_pine at 2005-04-07 05:59

  I don't really know what fixed and dynamic Huffman actually does, I just wondered if fixed Huffman could produce better results in general with small images

  The difference between "Fixed Huffman" and "Dynamic Huffman" is that a "Fixed Huffman" block uses fixed Huffman codes, predefined by the specification, and a "Dynamic Huffman" block makes its own Huffman codes, and can use them to compress the data better.
  
  So, basically, "Dynamic Huffman" blocks normally allow better compression, but they need an overhead to include the Huffman codes. With small files, the Huffman codes take up too much room, so "Fixed Huffman" is smaller.
  
  
  

  Nice work! Was that an intelligent guess or just trial & error?

  Thanks :) It was a semi-intelligent guess based on thinking about the invisible filter byte at the beginning of each row (which happens to be always zero here).
  The border colour is the only one that's adjacent to the row filter byte, so I tried making it zero as well. The consequence is a nice run of zeros at the start and end of the image data:)