JPEG XL is the future of all image formats.
Reference implementation here:
I copied the description text from chromestatus.com https://www.chromestatus.com/feature/5188299478007808 here:
JPEG XL is a new royalty-free image codec targeting the image quality as found on the web, providing about 60% size savings when compared to original JPEG at the same perceptual quality, while supporting modern features like HDR, animation, alpha channel, lossless JPEG recompression, lossless and progressive modes. It is based on Google's PIK and Cloudinary's FUIF, and is in the final steps of standardization with ISO.
The main motivations for supporting JPEG XL in Chrome are:
- The improvement in image quality vs image size, about 60% file size savings for the same visual quality (lossy compression of larger originals) when compared to JPEG at the qualities found on the web.
Improved visual latency by both smaller download sizes and supporting progressive decoding modes.
- Support for HDR, animation and progressive all together in the same image codec.
- Support for lossless-recompressed JPEGs
- Ecosystem interest in JPEG XL: Several Google teams evaluated using JPEG XL for storing and delivering images, as well as outside of Google: including CDNs interest in storing lossless-recompressed JPEGs as JPEG XL and converting to JPEG on request is the browser doesn't support JXL. Facebook is exploring to use JPEG XL.
Some more links about JPEG XL:
Committee draft of the JPEG XL spec: https://arxiv.org/abs/1908.03565
Search for JPEG XL issues on chromium.org: https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EImage%20jpeg%20xl&can=2
JPEG XL tracking bug on chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058
Intent-to-prototype chromium.org blink-dev group discussion thread: https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k
https://www.chromestatus.com/features#tags%3Ajxl shows both the content encoding and image encoding possibilities for JPEG XL. After reflecting on the advice from W3C HTTP WG members <https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0102.html> we are prioritizing image coding over content encoding.
Respective Bugzilla entries:
Initial bug with some discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
Initial implementation of JXL in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1707590
See also the thread at https://lists.webkit.org/pipermail/webkit-dev/2021-May/031844.html
As noted there, for the Apple WebKit ports, image format support depends on OS library support, and those libraries do not currently support JPEG XL.
Erik Andre from the Images Infra team at Facebook here. I'd like to share a bit of our view on JPEG XL in the context of new image formats (e.g AVIF, JPEG XL, WEBP2, ...) and how browser adoption will let us move forward with our plans to test and hopefully roll out JPEG XL.
After spending the last 5 months investigating and evaluating JPEG XL from both a performance and quality point of view, it's our opinion that JPEG XL has the most potential of the new generation of image formats that are trying to succeed JPEG.
This opinion is based on the following findings:
* JPEG XL encoding at speed/effort 6 is as fast as JPEG encoding (using MozJpeg with Trellis encoding enabled). This means that it's practical to encode JPEG XL images on the fly and serve to client. This can be compared with the encoding speed of AVIF which necessitates offline encoding which offers less flexibility when it comes to delivering dynamically sized and compressed content.
* Depending on the settings used, JPEG XL can also be very fast to decode. Our mobile benchmarks show that we can reach parity with JPEG when using multiple threads to decode. This matches and in many cases surpasses the decoding performance of other new image formats.
* The JPEG XL image format offers flexible support for progressive decoding, allowing quick preview to be rendered based on just the DC components, or multiple intermediate images without being limited to a fixed set of scans chosen at encode time (i.e progressive JPEG scans).
Having browser support from all the major browsers is going to make our lives a lot easier in upcoming WWW experiments and ensure that we can deliver a consistent experience across platforms and browsers.
Note there's been action in bug #233113 and bug #233325. This doesn't cover PlayStation or FTL Windows yet, but it's enough to make JPEG XL readily available to the non-Apple ports.
Question: does libjxl handle color management for us? I've never really understood what color management is tbh, but I know we have X11-specific LCMS integration that's required in PNGImageDecoder.cpp and JPEGImageDecoder.cpp, and I wonder if libjxl handles that for us, or if it's just not required with JPEG XL? (I'm not pleased that we added PNG and JPEG color management that's incompatible with Wayland. That wasn't forward-thinking.)
(In reply to Erik Andre from comment #5)
> After spending the last 5 months investigating and evaluating JPEG XL from
> both a performance and quality point of view, it's our opinion that JPEG XL
> has the most potential of the new generation of image formats that are
> trying to succeed JPEG.
Just wanted to let you know your comment helped me understand the interest in JPEG XL. I remember JPEG 2000 and was keen to avoid a repeat (we are probably stuck supporting JPEG 2000 indefinitely).
No, libjxl cannot handle color management for you, for the simple reason that libjxl has no way of knowing the display color space. So it is the same as with any other image format in that respect: you get uncompressed pixel values and an ICC profile, which together define a decoded image. To show those pixels on a screen, you have to convert them from the image color space (given by the ICC profile) to the display color space (which is how the screen will interpret pixel values). You cannot simply assume that the display color space will be sRGB; wider gamut screens are common (e.g. Display P3), and also HDR screens are becoming more common (e.g. Rec.2100 PQ or HLG).
That said; if you happen to know the display color space, using JxlDecoderSetPreferredColorProfile() you _can_ ask the libjxl decoder to try to do the color management for you, i.e. to return pixels that are already in that color space. This is only possible for certain display color spaces (the ones that can be described by a JxlColorEncoding, which includes most color spaces used in practice like sRGB, AdobeRGB, Display P3, DCI-P3, Rec.2100, etc; it doesn't include more complicated color spaces though that e.g. use lookup tables), and even then it is not guaranteed that libjxl will be able to return pixels in the requested space: it can only do that in the case of lossy images (which use an internal absolute color space called XYB) and in the case of lossless images that are in a JxlColorEncoding color space; it cannot do that in more complicated cases like CMYK or weird arbitrary-ICC-profile cases.
Anyway, in practice you should just take the pixel data and the ICC profile returned by the libjxl decoder and do the same thing with it as with any other image. It can be optimized a bit in case you happen to know the display space - using JxlDecoderSetPreferredColorProfile() you can make it very likely that the returned ICC profile happens to be identical to the display space, so your CMS gets a no-op case (pixel values don't need to be converted at all) - but that's an optimization I wouldn't bother to implement in an initial implementation of jxl support (since likely it requires quite a bit of nontrivial code plumbing for you to actually know the display space).
(In reply to Jon Sneyers from comment #9)
> Anyway, in practice you should just take the pixel data and the ICC profile
> returned by the libjxl decoder and do the same thing with it as with any
> other image.
Very interesting. Currently WebKit image decoders use ICC profiles only for PNG and JPEG, not for any other image format. And it does so only when running on X11, not on Wayland or Windows or any other platform. (Reminder: Apple ports do not use WebKit image decoders.) Sounds like we have some room for improvement there....
(In reply to Michael Catanzaro from comment #10)
> Very interesting. Currently WebKit image decoders use ICC profiles only for
> PNG and JPEG, not for any other image format. And it does so only when
> running on X11, not on Wayland or Windows or any other platform. (Reminder:
> Apple ports do not use WebKit image decoders.) Sounds like we have some room
> for improvement there....
Reported: bug #233364.