Better png optimization by sequential use of compressors

[jul059]

png files could be better optimized by sequentially using different tools on the same file instead of running them separately and using the smallest file size.

For example the attached file compresses to the following:

original: 649,793 bytes
pngout: 616,879 bytes
ECT: 542,926 bytes
pngout + ECT: 542,807 bytes

I think ECT should always be run last because it has the better deflate compression algorithm. Also, most tools have the default behaviour of not writing the file if it is larger than the source file so this should never cause any issue. Running pngout + ECT should always result in a file with a size that is at most the smallest of pngout or ECT.

Additionally, another very fast tool that can be run after every png optimization is Deflopt:

pngout + ECT + Deflopt: 542,695 bytes

commands used:
pngout /s0 /k0
ECT -9 --strict --mt-deflate=3
deflopt

greenland_grid_velo.zip

[pts]

Thank you for suggesting these enhancements!

It's impressive and suspicious how much better ECT is than pngout. If you convert the output of these (especially ECT) to PPM format, do you get bitwise identical files?

Please note that these combinations are already achievable if you specify custom CMD_PATTERN (containing 2 command invocations) in --use-image-optimizer=CMD_PATTERN. If you get something working, feel free to send a pull request.

[jul059]

Thank you for suggesting these enhancements!

It's impressive and suspicious how much better ECT is than pngout. If you convert the output of these (especially ECT) to PPM format, do you get bitwise identical files?

Please note that these combinations are already achievable if you specify custom CMD_PATTERN (containing 2 command invocations) in --use-image-optimizer=CMD_PATTERN. If you get something working, feel free to send a pull request.

Yes, binary comparison of ppm files shows identical files, See screenshot (means "No difference found"). First file was the original, second was the pngout + ECT + Deflopt.

The optimized zopfli implementation in ECT definitely has something to do with this. I've been using ECT for a while both on png files and gzip files, and never had any issue.

Thanks for the info on how to use multiple compressors.

[rbrito]

@pts, if you are suspicious about the performance of ECT, then you should see how a compressor called pingo works. It beats, hands down (both in speed and in compression), everything that I tried so far, about 99% of the time. And it is much faster for the compression that you get.

(I actually use some "chained" calls of optimizers like optipng followed by advpng and advdef or pngout+advdef and pingo rarely is beaten by one of these).

Alas, it is not Free Software... Anyway, it is here: https://css-ig.net/pingo

[rbrito]

Regarding "chained" optimizers, here is something that I have been doing for quite some time:

rbrito@ac42013

(The commit above may disappear if/when I do a rebase on my experimental branch).

[pts]

Cool, thanks for sharing your settings! I think the defaults of pdfsizeopt are fine for the general use case. Feel free to send a pull request if you want to make your PNG optimizer settings easily available for all pdfsizeopt users.

FYI You may want to use && instead of ; to join commands. The former will fail properly if the first command fails. It also works on Windows.

[ghost]

@pts, if you are suspicious about the performance of ECT, then you should see how a compressor called pingo works. It beats, hands down (both in speed and in compression), everything that I tried so far, about 99% of the time. And it is much faster for the compression that you get.

Could you please tell me how did you manage pingo to work with pdfsizeopt? Preferably - to optimize both png and jpg.

[zvezdochiot]

@AlexMatiash say:

and jpg.

pdfsizeopt does not optimize jpeg and jp2 at all. To optimize jpeg and jp2 to pdf refer to @rbrito scripts. Or use the decompress routine in cpdf/qpdf/pdftk to remove and replace jpeg and jp2.