jpegoptim VS mozjpeg

I think it's likely the size is in the images - could you possibly call something like jpegoptim on the images as part of the build phase?

Maybe invoke jpegoptim as a subprocess, since it does lossless optimization of JPEG compression and I don't know of any crates that do that for JPEG.

TBH, the library I am using only supports a few color spaces and it does not include XYB and I have not looked into it much further. Also as you can see I did not really bother to add colorspace settings in general but I might do it later.

[1] https://libjxl.readthedocs.io/en/latest/api_encoder.html#_CP...

[2] https://github.com/mozilla/mozjpeg/blob/6c9f0897afa1c2738d72...

[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