| |||||||||||||
PNGPNGPosted Mar 1, 2013 10:33 UTC (Fri) by epa (subscriber, #39769)Parent article: Google releases a better compression algorithm
So... how does one use it to make PNG files? Just rebuild libpng against zopfli, or what?
(Log in to post comments)
PNG + xz ? Posted Mar 1, 2013 18:11 UTC (Fri) by rzm (guest, #116) [Link]
I wonder if anybody tried to replace gzip in PNG with something else, e.g. xz.
PNG + xz ? Posted Mar 1, 2013 18:57 UTC (Fri) by daniel (subscriber, #3181) [Link]
Keep in mind that as images, pngs require a signal processing approach for optimal compression. In other words, first apply some fancy filter to partition most of the coherent signal content into a relatively low population of distinct symbols, then rzip that (or use whichever lossless compressor suits you).
PNG + xz ? Posted Mar 2, 2013 14:50 UTC (Sat) by endecotp (guest, #36428) [Link]
> Keep in mind that as images, pngs require a signal processing
> approach for optimal compression.
That's what I thought, until I did some experiments. My examples were map tiles, much like you'd get from OSM, Google Maps etc. It turned out that just gzipping the raw image data (24bpp) got slightly better results than with PNG's filtering. (And "no filtering" is not something that pngcrush tries, IIRC.) I then tried bzip2ing the raw image data and got even better results.
Less surprisingly, JPEG with a high quality setting gets visually-indistinguishable results and significantly smaller file sizes.
If you are motivated to improve compression by e.g. bandwidth bills, and especially if your data might be non-typical in some way, it seems that it is well worth experimenting and trying everything.
PNG + xz ? Posted Mar 3, 2013 22:13 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
Filter type 0, method 0 is the unfiltered data. Yes, pngcrush tries this, it tries each of the methods in type 0 filters (the only type so far defined) one at a time.
There's almost certainly an error in either your methodology or your line of reasoning from your results. Since you said you worked with OSM-like map data I'd guess you've fed a bunch of more or less totally blank map tiles (oceans, unmapped regions) in and what you're left measuring is solely the overhead from PNG's metadata.
PNG + xz ? Posted Mar 5, 2013 12:21 UTC (Tue) by endecotp (guest, #36428) [Link]
> Filter type 0, method 0 is the unfiltered data. Yes,
> pngcrush tries this
You are right; I was confused. I was misled by the fact that the pngcrush output lists a whole series of "methods" that start with method 1:
IDAT length with method 1 (fm 0 zl 4 zs 0) = 38507
but this "method" is not the same as the "filter method", which is the "fm" number inside the ().
It remains true that for these images the PNG pre-processing does not help. If you're curious, I have put an example tile here: http://chezphil.org/tmp/maptile.png .
> I'd guess you've fed a bunch of more or less totally blank map tiles
No.
PNG + xz ? Posted Mar 7, 2013 18:34 UTC (Thu) by huftis (subscriber, #58900) [Link]
Pngcrush just isn’t a very good PNG optimizer. Using OptiPNG or TruePNG, I managed to reduce the file size of your example PNG file by about 26% (from 33.5 KiB to 24.6 KiB).
PNG + xz ? Posted Mar 7, 2013 18:50 UTC (Thu) by huftis (subscriber, #58900) [Link]
And running PNGZopfli on the result of the TruePNG output gives a file size of only 23.4 KiB. Note that this is with the various max settings of both TruePNG and PNGZopfli, and running this takes a long time, but even with the (very fast) default settings we get a comparable file size – 23.5 KiB.
PNG + xz ? Posted Mar 1, 2013 21:24 UTC (Fri) by rillian (subscriber, #11344) [Link]
It would help, and PNG even has an enumeration field for the compression algorithm used.
The problem is it would incompatible with every other png decoder out there. Considering it took 10 years to get the current format widely adopted, that's a very expensive proposal.
Which, of course, is why better deflate compressors like zopfli are interesting.
|
|||||||||||||
