[Feature Request] Support for jpegli

[Stanzilla]

Is your feature request related to a problem? Please describe.
Support for the jpegli encoder for jpgs

Describe the solution you'd like
Integration of https://github.com/libjxl/libjxl/tree/main/lib/jpegli

Does other service/app have this feature?
Not yet

Additional context
See https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html

[tomByrer]

The announcement made it to Android Contrail & a few forums. Seems like it is poised as a replacement for MozJPEG, rather than a new format like JPEGXL. It just seems to use different colorspace shifting & does math calculations in floats like JPEGXL.

I don't see any new features like background transparency. Though I'm sure @jakearchibald would be interested to see how the 'progressive' image reveal works out?

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.

At [high quality], mozjpeg no longer beats WebP, though jpegli still does

Decode speed: Sequential JPEG is unbeatable in terms of decode speed... Progressive JPEG (e.g. as produced by mozjpeg and default jpegli) is somewhat slower to decode, but still fast enough to load any reasonably-sized image in the blink of an eye. JPEG XL is somewhere in between those two.

things look quite [with Larger, camera-sized] images. WebP, mozjpeg, and AVIF are worse than libjpeg-turbo (for these images, at this quality point). HEIC brings significant savings over libjpeg-turbo, though so does jpegli, at a much better speed. JPEG XL is the clear winner,

https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

---

Thread at Sharp: lovell/sharp#4018 (comment)

[surma]

Afaiu (please correct me if I'm wrong!) it is a new format, but partly backwards compatible. Meaning, every jepgli file can be decoded by a jpeg decoder, but you lose some data there. e.g. a legacy decoder won't spit out a 10-bit image, while a jepgli decoder would.

[mathiasbynens]

Afaiu (please correct me if I'm wrong!) it is a new format

The announcement blog post says it’s a new encoder for the existing traditional JPEG format:

All the new methods have been carefully crafted to use the traditional 8-bit JPEG formalism, so newly compressed images are compatible with existing JPEG viewers such as browsers, image processing software, and others.

[jyrkialakuijala]

Jpegli is both a new encoder and a new decoder.

They can be used traditionally as drop in replacements of MozJPEG and libjpeg-turbo. When done so, they will give ~35 % quality improvement in the high end and 10-20 % in the more usual quality.

You can choose to use only the encoder, or only the decoder.

With both, you can choose to use the traditional 8-bit framebuffer interface, or an extension of a 16-bit framebuffer. Using the 16-bit framebuffer does not lead extension metadata to be added to the stream, the additional bits are carefully encoded into the stream. Every high quality encoding and decoding decision benefits from using the 16-bit framebuffer interface, even if the encoding or the decoding was done then in 8 bits, the quality will be slightly better.

16-bit decoding is especially attractive for HDR uses, where 8-bit striping can be more disruptive.

Jpegli encoding allows for XYB ICC v4 color profile to be emitted. This makes the resulting JPEG less compatible with legacy systems and will cause false colors (usually green) to be rendered when the decoder does not know how to interpret ICC v4 (defined in 2012). Many such systems exists, especially for thumbnailers and for image uploading in social media web services. Where appropriate -- considering the legacy compatibility issues -- XYB can give an additional ~10 % more compression density or quality.

Jpegli achieves most of the savings by psychovisually derived (based on butteraugli!) spatially variable dead-zone quantization and by more careful computation and less intermediate quantization at each stage of processing.

[QINGCHARLES]

All the major Web browsers support ICCv4 on desktop and mobile, correct?

+1 for jpegli support in Squoosh.

[Bustycat]

Jpegli encoding allows for XYB ICC v4 color profile to be emitted. This makes the resulting JPEG less compatible with legacy systems and will cause false colors (usually green) to be rendered when the decoder does not know how to interpret ICC v4 (defined in 2012). Many such systems exists, especially for thumbnailers and for image uploading in social media web services. Where appropriate -- considering the legacy compatibility issues -- XYB can give an additional ~10 % more compression density or quality.

This greatly explains why I saw greenish colours somewhere especially with thumbnails. Unfortunately it would be more difficult to ask those softwares (even Finder of macOS and Painter of Windows) to correctly apply with ICC v4.

[QINGCHARLES]

Squoosh = Google
Jpegli = Google

Squoosh + Jpegli = 2026?😿

[YuushaExa]

We really need Jpegli support.