JPEG XL image format

[BearCooder]

Description

JPEG XL is a modern image format optimized for web environments. JPEG XL generally has better compression than WebP, JPEG, PNG and GIF and is designed to supersede them. JPEG XL competes with AVIF which has similar compression quality but fewer features overall.

Rationale

• Encode performance: JPEG XL encoding performance at speed/effort 6 is comparable to 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 clients. This can be compared with the encoding speed of AVIF which necessitates offline encoding which offers much less flexibility when it comes to delivering dynamically sized and compressed content.
• Decode performance: Depending on the settings used, JPEG XL can also be very fast to decode. Our mobile benchmarks show that especially for larger images we can reach parity with JPEG when using multiple threads to decode. This matches and in some cases surpasses the decoding performance of other new image formats.
• Progressive rendering: The JPEG XL image format supports progressive decoding, offering similar gains in perceived image load performance we are already benefitting from with JPEG.
• Image quality: Perhaps eve more importantly, JPEG XL offers great image quality at very competitive bitrates. Of course, there’s always cases where one image format delivers a better looking image than the other, or cases where one needs more bytes than the other to achieve the same quality but overall we’ve not found any issues with the image quality offered by JPEG XL.

A comment from jyrkialakuijala:

I observe 39 % win in a multi-corpus lossless compression test for JPEG XL vs. AVIF. In the same study I observe JPEG XL as a lossless compression leader of all image formats intended for the web, including WebP lossless, AVIF, and PNG. I observe that some research compressors (BMF and EMMA) can still do better (by 5-15 %), but they would be too slow for web use.

In the standardization experiments at ISO (Core Experiment 8.2 / WG1M90008), JPEG XL's lossless coding was tested against other lossless mage codings using FLIF -N, FLIF, WebP lossless, FUIF -R0, FUIF -R1, JPEG-LS2, ZopfliPNG, PNG-Pingo, JPEG 2000, JPEG-LS, JPEG XS, JPEG LLA, JPEG LL and Lossless JPEG. JPEG XL produced consistently the most dense results in all categories: 8 bit per channel non-photo, 8 bit per channel photo, and the more than 8 bit per channel category. In that experiment JPEG XL produced 45 % smaller files in the 8+ bit lossless category than any currently available web codec in the 8+ bit category (ZopfliPNG was the best currently available option for 8+ bit lossless Web transport -- FLIF is not available in the web, WebP lossless only up to 8 bits). In 8 bit categories, the 2nd and 3rd place in lossless density in the Core Experiment 8.2 went to FLIF and WebP lossless. Authors of ZopfliPNG, FLIF, FUIF, and WebP lossless participate in the development of JPEG XL and openly support JPEG XL as a way forward.

I observe a similar 25-40 % win for psychovisually lossless compression for JPEG XL vs. current AVIF encoders. Often the problems relate to textures and oversmoothing, and removal of small details. Compare MozJpeg, JPEG XL, and AVIF. The AVIF and JPEG XL are courtesy of the WebP/WebM team, Mozjpeg by eclipseo.

I observe a 'it-just-works' approach used in JPEG XL. You can literally just write cjxl input.png output.jxl and be happy with the results. No difficult decisions about colorspaces, no SDR/HDR decisions (same modeling in both cases), yuv444/422/420, no --tune=psnr/vmaf/ssim, no flag exploration.

Professional and prosumer photography workflows need more bit depth than AVIF is giving, preferrably 16 bits. Libjxl gives 24 bits of dynamics, twice that of AVIF's up to 12 bits. In this article the photographer slightly prefers 14 bits over 12 bits for his workflows: "If you want the absolute best quality in the shadows, shoot 14+ bit RAW files (ideally with lossless compression to save space). This is the best choice if you don’t care about larger files and shoot scenes with wide dynamic range (deep shadows)."

I observe higher resulting image quality in medium-to-high-BPP (above 0.5 BPP) for JPEG XL, including both Internet (0.5-2 BPP, histogram from this article) and digital camera (3-5 BPP) use cases.

I observe a that JPEG XL provides online lossless transcoding from JPEG to JPEG XL and back, with 16-22 % savings. This may simplifies transition as webmasters do not need to keep two copies of encoded images. Full JPEG XL encoding can be done with speeds similar to MozJpeg, whereas observed AVIF encoding speeds are slower and some practitioners (mozilla/standards-positions#522 (comment), mozilla/standards-positions#522 (comment)) find AVIF's encoding speed problematic.

JPEG XL provides saliency-ordered updating. After delivering the first scan of 8x8 subsampled rendering, it can give the rest of the image in an encode-time defined order. This means that a portrait can render eyes, nose, and mouth first, and then continue to other areas. When coupled with saliency-prediction ML models, it may be a powerful further improvement in user experience.

I observe JPEG XL's format decisions to be more geared towards high quality: more context modeling and less prediction, filtering to reuse information from adaptive quantization so that appropriate fine details and low contrast textures where sent are not impacted through filtering. Filtering strength control field in JPEG XL is at a relatively high 8x8 pixel resolution. Deblocking filtering "Gaborish" in JPEG XL runs the opposite filtering at encoding time, making it transparent: image features in the original that happen to look like blocking artefacts will not be impacted.

I am not aware of any published usage statistics of AVIF. I believe we are still in a time window where the shift to JPEG XL would cause very little if any confusion and doubled effort in the field. I observe two of the early AVIF supporters (Facebook and Cloudflare, in this thread) shifting their interest from AVIF towards JPEG XL.

I observe JPEG XL to have the lowest header overhead of modern image formats. My profile pic is a 28 byte JPEG XL image. Avoiding the header overhead has resulted in strange systems where the browser uses JavaScript to patch together an existing header with the image body, or spriteing together GUI elements, i.e., adding system complexity on another level.

I observe JPEG XL to have some more tendency to become artefacty before it comes forgetful, and for AVIF to become forgetful first and artefacty later. This may lead into user confusion if cracks and bolts start disappearing rather than user being otherwise informed about bad quality of image transport. For an example of bolts disappearing, see the thick red pole in the center of the image having four bolts in the original: AVIF and JPEG XL images from WebM/WebP team's codec comparison images. Mozjpeg from the older comparison by eclipseo preserves the bolts, but blurs them to some extent.

I consider the browsers are leading this and similar changes, and operating systems such as iOS and Microsoft Windows will come later. The same happened with Brotli and WOFF2, and will likely happen with AVIF and JPEG XL, too.

From : mozilla/standards-positions#522 (comment)

Facebook declaring to be in favor of JPEG XL support: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18

Specification

https://jpeg.org/jpegxl/documentation.html

Tests

No response

[foolip]

@BearCooder thanks for submitting a proposal! According to https://caniuse.com/jpegxl is behind a flag in both Chrome and Firefox, and these seem to be the implementation bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 (140 stars)
https://bugzilla.mozilla.org/show_bug.cgi?id=1539075

Quoting the issue template about the spec:

The feature should be defined by a standards-track specification from the following organizations:

• IETF (Standard Track)
• Khronos Group
• TC39 (Stage 2+)
• W3C (Recommendation Track)
• WHATWG

Looking at the spec and tests, it seems like https://jpeg.org/jpegxl/documentation.html doesn't link to a spec, by which a mean a document one can read in order to implement JPEG XL interoperably with other implementations. I know it's not in one of the listed standards orgs, but is there a public spec at all?

And for tests:

Tests for the feature in web-platform-tests on wpt.fyi, or in Test262 on test262.report.

Is there a JPEG XL test suite?

[gsnedders]

Looking at the spec and tests, it seems like https://jpeg.org/jpegxl/documentation.html doesn't link to a spec, by which a mean a document one can read in order to implement JPEG XL interoperably with other implementations. I know it's not in one of the listed standards orgs, but is there a public spec at all?

ISO/IEC 18181

Is there a JPEG XL test suite?

For other image formats we only have a very surface level set of tests in WPT, mostly dealing with integration, so there's also the question of "if this were accepted, what tests would we feel are appropriate".

[jsnkuhn]

This is super awkward but there have been some developments on the chrome bug over the weekend that probably should be pointed out here. Looks like they are removing support for JXL altogether?

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84

Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons:

• Experimental flags and code should not remain indefinitely
• There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
• The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
• By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome

[BearCooder]

There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL from https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84

Well this statement is astonishing..

[foolip]

In the State of CSS 2022 question about browser incompatibilities, there were 3 mentions of JPEG XL. They were:

• JPEGXL please! Animated AVIF please. We desperately need better standard image formats, especially on Safari which takes forever.
• image-set() has terrible supporty making it harder to use AVIF and JPEG XL. Nesting is also sorely needed
• :has, jpegxl & avif, subgrid

This was not enough to make the top list in #248.

Since the survey was about CSS I don't think much can be made of the small number of responses, but I'm commenting on all proposals where I could find something in the State of CSS 2022 results.

[nairnandu]

Thank you for proposing the JPEG XL for inclusion in Interop 2023.

We wanted to let you know that this proposal was not selected to be part of Interop this year, as we did not have consensus for doing so. This should not be taken as a comment on the technology as a whole.

For an overview of our process, see the proposal selection summary. Thank you again for contributing to Interop 2023!

Posted on behalf of the Interop team.