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.
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.