Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PNG + xz ?
Posted Mar 1, 2013 18:57 UTC (Fri) by daniel (subscriber, #3181)
Posted Mar 2, 2013 14:50 UTC (Sat) by endecotp (guest, #36428)
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.
Posted Mar 3, 2013 22:13 UTC (Sun) by tialaramex (subscriber, #21167)
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.
Posted Mar 5, 2013 12:21 UTC (Tue) by endecotp (guest, #36428)
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
IDAT length with method 2 (fm 1 zl 4 zs 0) = 51462
IDAT length with method 3 (fm 5 zl 4 zs 1) = 71769
IDAT length with method 4 (fm 0 zl 9 zs 1) = 34941
IDAT length with method 7 (fm 0 zl 9 zs 0) = 32868
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
Posted Mar 7, 2013 18:34 UTC (Thu) by huftis (subscriber, #58900)
Posted Mar 7, 2013 18:50 UTC (Thu) by huftis (subscriber, #58900)
Posted Mar 1, 2013 21:24 UTC (Fri) by rillian (subscriber, #11344)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds