Efficient-Compression-Tool

While not very popular, ECT [1] is (still?) the best solution in this space and has been my go-to tool for this purpose. [1] https://github.com/fhanau/Efficient-Compression-Tool

Pulling on this thread, there are a few people who have looked at the ways zopfli is inefficient. Including this guy who forked it, and tried to contribute a couple improvements back to master: https://github.com/fhanau/Efficient-Compression-Tool These days if you’re going to iterate on a solution you’d better make it multithreaded. We have laptops where sequential code uses 8% of the available cpu.

For the usual case of DEFLATE-based formats (PNG, ZIP) and JPEG, ECT [1] is the best available tool; to my best knowledge it dominates the entire Pareto frontier in this area, beating Zopfli and ADVPNG/OUT for most cases. If this software is still being maintained, it would be a good choice to switch to ECT now. [1] https://github.com/fhanau/Efficient-Compression-Tool

Would be interesting to see how all those jpegs fared if run though ECT (https://github.com/fhanau/Efficient-Compression-Tool). I’ve found it can save a surprising amount of space sometimes.

You’ll want to add ECT to the comparison. https://github.com/fhanau/Efficient-Compression-Tool

As is unfortunately typical for tutorials like this, the best and most effective PNG compressors like oxipng or ECT [1] are strangely left off. I compressed the original PNG shown on the site with ECT. It took only 6.5 seconds on my old laptop, and resulted in a file 95.7% of the size of their pngcrush result. I don't see why you'd want to leave 4-5% more efficiency on the table in a case like this. Similarly, I reproduced their pngcrush result on the same laptop. It took 10.834 seconds. Getting a better result doesn't even take more time! Commands: ect --strict -9 pngcrush -brute [1] https://github.com/fhanau/Efficient-Compression-Tool

There are a myriad of PNG (and in general DEFLATE) optimizers and pingo hosts its own benchmark [1]. I believe ECT [2] is the only tool comparable to pingo in terms of compression ratio and speed. But pingo still lacks a license statement and it's even unclear whether you can use this for any purpose at all, probably because it is still "experimental", so if you don't like that you can try ECT instead. > One thing I didn't check is that you might pay that in decoding time, I've never seen anybody talking about that though. PNG and in general DEFLATE-based formats are mostly free from this concern because they are comparably simple. The maximum "overhead" you can intentionally trigger is a very large LZ77 window and a very deep prefix code tree; the former is however capped to 32 KB in DEFLATE, and the latter will mostly result in an infer