Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

[Moritz Firsching]

Contact emails

de...@chromium.org, firs...@google.com, lo...@google.com, jy...@google.com

Explainer

https://jpeg.org/jpegxl/

http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

Specification

https://arxiv.org/abs/1908.03565

Summary

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.

This feature enables image/jxl decoding support in the blink renderer.

Blink component

Blink>Image

Motivation

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.

Initial public proposal

Support decoding image/jxl behind a feature flag which is turned off by default on all platforms. 

Search tags

jxl

TAG review

Not applicable for image decoders

TAG review status

Not applicable

Risks

Interoperability and Compatibility

JPEG XL is in the final stage ISO standardization. 

Firefox has an open bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075

Edge/Safari - no signals yet

Gecko: No signal

WebKit: No signal

Web developers: high interest/many stars in the tracking bug, and there was a separate external crbug requesting the feature. 

A lot of interest on encode.su, r/jpegxl, discord, ...

Is this feature fully tested by web-platform-tests?

No, but planning to have complete tests before shipping. 

Tracking bug

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

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1178040

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5188299478007808

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

Thanks for working on this! I'm excited about the possibilities around progressive loading.

It may be interesting to work with the Loading team on complementary image loading primitives that would enable us to get the full benefits from this (e.g. to enable high-quality zooming-in, while reusing already downloaded image bytes)

It may be useful to file for signals at some point: https://bit.ly/blink-signals

[Yoav Weiss]

Belatedly realized that I failed to provide advice to y'all about content negotiation and `<picture>` support.

A lot of what I suggested [1] [2] to the AVIF folks would similarly apply to JXL - basically we want to ensure that both server side and client side selection is possible such that supporting browsers would be served with JXL and non-supporting browsers with other formats that they do support.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/adc4e284-03ae-4431-a4e3-eae4046db821n%40chromium.org.

[Anne van Kesteren]

On Tue, Mar 30, 2021 at 9:20 PM 'Moritz Firsching' via blink-dev
<blin...@chromium.org> wrote:
> Specification
>
> https://arxiv.org/abs/1908.03565

I'm not really sure what the best place to raise this, but raising
this on blink-dev as Chromium seems to be the furthest along with JPEG
XL.

To what extent are
https://w3ctag.github.io/design-principles/#new-data-formats and
https://github.com/annevk/orb/issues/3#issuecomment-779630945 being
considered here? This is the first new format with a new signature
that I know of so ideally we use this opportunity to not further
increase the bad security behavior of the past. As written there I
think at minimum we should require a MIME type in the img element
processing model (similar to SVG) and at best we would also require
CORS (similar to module scripts).

[Yoav Weiss]

On Fri, May 7, 2021 at 11:17 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Mar 30, 2021 at 9:20 PM 'Moritz Firsching' via blink-dev
<blin...@chromium.org> wrote:
> Specification
>
> https://arxiv.org/abs/1908.03565

I'm not really sure what the best place to raise this, but raising
this on blink-dev as Chromium seems to be the furthest along with JPEG
XL.

To what extent are
https://w3ctag.github.io/design-principles/#new-data-formats and
https://github.com/annevk/orb/issues/3#issuecomment-779630945 being
considered here? This is the first new format with a new signature
that I know of

Why is a new signature a requirement for starting to enforce MIME types?

 

so ideally we use this opportunity to not further
increase the bad security behavior of the past. As written there I
think at minimum we should require a MIME type in the img element
processing model

That seems reasonable, but I'd like to hear from folks about the potential deployment hurdles it may pose for serving the format from servers that don't translate e.g. the .jxl extension to the right MIME type.

It may make sense to seed popular servers with that MIME type mapping as early as possible.

(similar to SVG) and at best we would also require
CORS (similar to module scripts).

A CORS requirement would be a significant deployment hurdle, as it would mean that e.g. image CDNs wouldn't be able to automatically serve JXL to supporting browsers unless the markup is modified to match.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78i7E-KZPpURYgsc78LyasgnJm4aiujSgxetg7bAeYH_vg%40mail.gmail.com.

[Luca Versari]

How is JPEG XL the first new format with a new signature? My understanding is that AVIF's signature is also a new one.

WebP's too, but I suppose that WebP predates these other technologies.