Efficient-Compression-Tool VS mozjpeg

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.

Ah, I misunderstood you there, yes you can build it from source but there are also Windows binaries available on https://github.com/fhanau/Efficient-Compression-Tool/releases/

Did you think about adding support for newer image formats? Video shouldn't be a problem because you already support .mkv and AV1 works within it. How would implementation work? Does ES-DE use libraries from the OS and makes this support easier for that? My biggest gripe are those big .png files. I optimized them with ect but it won't be as good as newer formats can be.

If png size is a concert of yours: 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 Huffman tree; the former is however capped to 32 KB in DEFLATE, and the latter will mostly result in an inferior compression (a long prefix code means a larger file).

[1] https://css-ig.net/benchmark/png-lossless

[2] https://github.com/fhanau/Efficient-Compression-Tool

I personally prefer ECT, since that gave me the best results when I tested it several years ago.

ECT is the new stuff that is much faster and more efficient than zofpli

Efficient Compression Tool Basically the best FOSS for lossless compression for .png and .jpeg, although not the quickest.

I get the same issue. However, it seems that using ECT on the images fixes the issue: https://github.com/fhanau/Efficient-Compression-Tool

[2] https://github.com/mozilla/mozjpeg

It would be nice if the author would add mozjpeg[1] to the comparison. At certain sizes, it can produce smaller sizes than WebP, and because it is still a jpeg, it has a much better compatibility story, which the author alluded to.

[1]https://github.com/mozilla/mozjpeg

image-shrinker is a simple, easy to use open source tool for shrinking images. Under the hood it uses pngquant, mozjpg, SVGO, and gifsicle. You can also install these tools individually if you need to compress some images. I often use pngquantafter exporting PNGs for web projects from Figma or similar tools. I literally run it like this:

> MozJPEG is a patch for libjpeg-turbo. Please send pull requests to libjpeg-turbo if the changes aren't specific to newly-added MozJPEG-only compression code.

https://github.com/mozilla/mozjpeg#mozilla-jpeg-encoder-proj...

FWIW, Mozilla has been maintaining their own fork for quite a while now[1]

AFAIK most Linux Distros have been using libjpeg-turbo as a drop-in replacement for libjpeg, after some drama in ~2010 where libjpeg came under new management, decided to break ABI/API several times over and add incompatible, non-standard format extensions[2].

[1] https://github.com/mozilla/mozjpeg

[2] https://en.wikipedia.org/wiki/Libjpeg#History

No.

See https://github.com/mozilla/mozjpeg

Also, there is a fairly big problem with JPG that the ‘quality’ setting is not calibrated. That is you might look at one image and think it looks fine (which is subjective, depends on what you want to use the image for…) with a quality of 60%, but then you compress a million images at that rate, delete the originals, then you find that many of them look really awful. Not only that but there are images you could have compressed more and still been happy with the output.

If you are publishing images for the web consider using WebP which is consistently better, well supported now, and has a calibrated quality knob.

https://github.com/mozilla/mozjpeg's cjpeg tool is the command line version of the mozjpeg library, itself a fork of libjpeg-turbo. Mozjpeg performs lossless JPEG optimization. There are plenty of others out there.

Use the Mozilla JPEG Encoder, which implements several tricks for smaller file size / better visual quality. The result is still JPEG standard compatible that other software can decode.

Guetzli was already mentioned and roughly does what you are talking about.

MozJPEG [1] includes several quantization tables that are optimized for different contexts (see the quant-table flag and source code for specific tables[2]), and the default quantization table has been optimized to outperform the recommended quantization tables in the original JPEG spec (Annex K).

It's also worth noting that MozJPEG uses Trellis quantization [3] to help improve quality without a per-image brute force quantization table search. Basically rather than determining an optimal quantization table for the image, it minimizes rate distortion on a per-block level by tuning the quantized coefficients.

[1] https://github.com/mozilla/mozjpeg

[2] https://github.com/mozilla/mozjpeg/blob/5c6a0f0971edf1ed3cf3...

[3] https://en.wikipedia.org/wiki/Trellis_quantization

They're still being used. A newer, optimized JPEG encoder, mozJPEG[0], seems to use progressive encoding by default. I suspect with faster internet speeds, most images download and decode so fast that the cool 'enhance' animation doesn't happen anymore.

[0] https://github.com/mozilla/mozjpeg