Enhancement: add experimental support for the JPEG-XL format, requires libvips compiled with support for libjxl, prebuilt binaries will not support this

[Juraj-Masiar]

What are you trying to achieve? -> smaller images

Have you searched for similar feature requests? -> Yes, see also #2245

What would you expect the API to look like? -> Same as other formats.

What alternatives have you considered? -> AVIF, but JPEG-XL has several advantages

Is there a sample image that helps explain? -> nope

More info:
https://jpeg.org/jpegxl/
https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18
mozilla/standards-positions#522
https://caniuse.com/jpegxl

There is some initial implementation in Squoosh:
https://github.com/GoogleChromeLabs/squoosh

I know, it's soon, but the format spec. is finished so it's ready to be implemented. Also the comment from Facebook employee in the bugzilla thread has some good points regarding this formats (bright) future in FB.

[lovell]

The forthcoming libvips v8.11.0 will add experimental support for this format via the libjxl reference library.

https://gitlab.com/wg1/jpeg-xl

This library is being developed in private and the commit log is mostly "Update JPEG-XL with latest changes" which makes debugging tricky, so sadly this is not quite ready for the prime time yet.

Integrating with sharp would require at least the following upstream issues to be addressed:

• Develop in public - see https://gitlab.com/wg1/jpeg-xl/-/issues/220
• pkg-config with static builds - see https://gitlab.com/wg1/jpeg-xl/-/issues/224
• EXIF/XMP metadata support - see https://gitlab.com/wg1/jpeg-xl/-/issues/208
• Allow use of external lcms2 - see https://gitlab.com/wg1/jpeg-xl/-/issues/124
• Potential DoS vulnerability - splines: possible memory exhaustion in ComputeSegments libjxl/libjxl#576
• OSS Fuzz issue 39156 Heap-buffer-overflow in jxl::...

[veluca93]

FYI, we just migrated today to a public repo for development: https://github.com/libjxl/libjxl

[whyboris]

I'm looking forward to this feature.

I was able to get the latest version of Electron to display JPEG XL (or jxl as it's also called):

app.commandLine.appendSwitch('enable-features', 'JXL');

When sharp lets me use jxl I'll be able to better handle my image-heavy application:

https://github.com/whyboris/Video-Hub-App 🚀

JPEG XL decreases storage by 22% and "actually decodes faster than JPEG" source 🥇

Thank you for your work 🙇

[soluml]

It's been awhile since the last comment, has there been any update on this?

Looks like Libvips has added support (with caveats): libvips/libvips#2181

Is there any other dependencies upstream blocking this from moving forward? Are we just needing a PR at this stage?

[lovell]

@soluml Please see the list of linked issues in my comment above #2731 (comment) as these are all dependencies that must be implemented or addressed first. If you are able to help work on these in libjxl then please do so.

[soluml]

Thanks for the quick reply!

On the potential DOS issue (576), that seems to be resolved per the thread.

On external LCMS2 issue (124), per the thread at the bottom, the lcms2 issue looks to be resolved: "only the vmaf part is left". So is this resolved as well?

That leaves EXIF/Metadata support (208) which looks to be on libvips if I'm following the thread correctly. It seems for most web uses, stripping exif/metadata is a good idea anyway so I don't know if an alpha implementation of JXL could be considered in the interim?

[TheJaredWilcurt]

Probably worth closing the JXL GitLab issues, and recreating them on GitHub for better tracking and prioritization. And updating the links in @lovell's comment.

[lovell]

Commit a7fa701 adds experimental support for JPEG-XL when used with a globally-installed libvips compiled with support for libjxl.

Please note that the prebuilt binaries will not include support for JPEG-XL. If the situation as documented by https://caniuse.com/jpegxl changes significantly then we can revisit this.

[lovell]

v0.31.3 now available with support for a globally-installed libvips compiled with support for libjxl.

If you'd like support for this in the prebuilt binaries, please direct your energy and constructive feedback towards web browser vendors rather than asking here.

[gadicc]

@lovell, thanks for your stellar work here.

Might we be able to re-visit this now that Safari includes JPEG-XL support[1]? According to BrowserStack, Safari is the 2nd most popular browser with a 24.36% market share[2]. Pre-built binaries would be immensely helpful in serverless environments where we can't install our own global binaries.

With Google it seems a bit of a chicken-or-the-egg issue; but of course, that's been discussed much elsewhere. Presumably, however, the easier it is for developers to adopt this technology, the more use we'll see. And there are some great wasm libraries to convert or render in unsupported browsers.

Thanks again for being so ahead-of-the-curve here... it was wonderful to find this issue already solved last year! 💯

[1] Version 17. Shipped on iOS; Tech Preview on Desktop.
[2] https://www.browserstack.com/guide/understanding-browser-market-share#:~:text=Overall%20Browser%20Market%20Share%202023,-Browser%20Market%20Share&text=A%20recent%20market%20study%20by,the%20remainder%20of%20the%20list.