Open kurtextrem opened 5 months ago
My understanding is that the jpegli encoder discards more data from the blue part of the visual spectrum to achieve smaller files. To achieve this it uses a somewhat non-standard approach, converting RGB pixel values to a custom colour space (XYB) and storing them as if they were YCbCr, attaching an ICC profile with the relevant curves for a decoder to convert back again.
This means all decoders given such images would need to properly support ICC profiles, something that is still not the case today. This would also preclude the use of wider gamut RGB profiles such as P3.
as well as a lib/jpegli/libjpeg.so.62.3.0 shared library that can be used as a drop-in replacement for the system library
Those wishing to use this should be able to do so today with a globally-installed libvips, although I cannot provide any help or support.
If the prebuilt binaries were ever to include this, it would be instead of mozjpeg rather than in addition to. This means it would require that the upstream jpegli library have a "switch" to use standard libjpeg YCbCr colour encoding, a feature I don't see today.
I got the info that Jpegli only uses XYB optionally nowadays, and all comparisons that Google has done were without the XYB ICC color space. jpegli does the same as other encoders, just quantized differently. i.e., no decoding compatibility burned.
Jyrki will also reply here as soon as he has the time.
Ah OK, happy to stand corrected, the documentation for jpegli is rather sparse and I might be mixing it up with bits of JPEG-XL.
Today's Google announcement
https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html
For people following this issue, as far as I can tell, if you build your own libvips and replace the jpeg libs during building of libvips, you can make sharp use jpegli already (implicitly).
How to replace JPEG lib? Can you give command to give while building libvips?
I think something like this should do it:
sudo cp ./libjpeg.so.62.3.0 /usr/lib/ # make sure libjpeg.so.62.3.0 is the one from the jpegli build
sudo ldconfig
and then build libvips. not 100% sure though (and make sure to make a backup of the current libjpeg in case you try it outside of a docker container or so)
Jpegli is not using XYB by default. Most of the substantial savings are by variable dead zone quantization and more precise intermediate computations. Using XYB will give an additional ~10 % savings in mid-to-high quality.
@jyrkialakuijala Thanks for the info. Given jpegli is intended as a "drop-in replacement" for libjpeg(-turbo), is there any plan to add support for the jpeg_c_*_param_supported()
extensibility framework functions, as provided by mozjpeg via https://github.com/mozilla/mozjpeg/pull/118? This would allow libvips and therefore sharp to switch jpegli features on/off in an ABI-compatible manner in the same way that we can currently switch mozjpeg features on/off.
Feature request
What are you trying to achieve?
The JPEG XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere. - source: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front.
Why is it worth adding
Google did a visual study using jpegli, made public in 2024: https://github.com/google-research/google-research/tree/master/mucped23
Further blog posts (from last year, could be that jpegli advanced by now):
How to integrate
Jpegli is included in the JXL repo: https://github.com/libjxl/libjxl/blob/main/lib/jpegli/README.md:
libvips discussion: https://github.com/libvips/libvips/discussions/3871
When you searched for similar feature requests, what did you find that might be related?
https://github.com/lovell/sharp/issues/2731
What would you expect the API to look like?
Probably an option like
[options.mozjpeg]
->[options.jpegli]
.What alternatives have you considered?
see above; jpegli is an alternative to mozjpeg, while being faster and achieving better quality.