>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 much 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 supports progressive decoding, offering similar gains in perceived image load performance we are already benefitting from with JPEG. This is a feature lacking in the other new image formats which are all derived from Video codecs where such features makes little sense to support.
>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.
Blink Tracking Bug [2] currently behind a flag ,Firefox on both [1] and [3], currently in about:preferences#experimental on Firefox Nightly. If I remember correctly it is supported on Edge behind a parameter as well. I thought it was all very quiet after the standard was published, turns out both Chrome and Firefox intent to support it.
AFAIK, neither Webkit nor Safari has any plan or intention to support JPEGXL. I think ( someone correct me if I am wrong ) Safari uses macOS image decoding library. So supporting JPEGXL may come from an OS update and not browser?
Finally, an open standard, Royalty Free, open-source reference implementation, and it is nearly better than all other alternative. As an image format on the web it is quite possibly close to perfect [4]. It is exciting and I hope JPEG XL will succeed.
[4] I remember the conversion from a little more than 6 months ago current encoder is not optimised for image quality below bpp 1.0, those are going to be the focus once all the initial reference encoder and decoder standards and issues are done. So in case anyone wondering it doesn't look as good as other competitors ( but still a lot better than JPEG ), those improvements are coming later.
The only power Safari devs basically have is to decide which OS-supported formats to enable/allow and which ones to disable (e.g. JPEG 2000 is enabled but HEIC isn't).
So getting JPEG XL supported in Safari will most likely first require it to be supported in MacOS and iOS. If you have an Apple device and would like it to get JPEG XL support, then feel free to open a Feedback Assistant ticket (there's an OS-level application to do that) to make a feature request. (I did that 5 weeks ago but haven't heard back yet)
>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 much 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 supports progressive decoding, offering similar gains in perceived image load performance we are already benefitting from with JPEG. This is a feature lacking in the other new image formats which are all derived from Video codecs where such features makes little sense to support.
>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.
Blink Tracking Bug [2] currently behind a flag ,Firefox on both [1] and [3], currently in about:preferences#experimental on Firefox Nightly. If I remember correctly it is supported on Edge behind a parameter as well. I thought it was all very quiet after the standard was published, turns out both Chrome and Firefox intent to support it.
AFAIK, neither Webkit nor Safari has any plan or intention to support JPEGXL. I think ( someone correct me if I am wrong ) Safari uses macOS image decoding library. So supporting JPEGXL may come from an OS update and not browser?
Finally, an open standard, Royalty Free, open-source reference implementation, and it is nearly better than all other alternative. As an image format on the web it is quite possibly close to perfect [4]. It is exciting and I hope JPEG XL will succeed.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1707590
[4] I remember the conversion from a little more than 6 months ago current encoder is not optimised for image quality below bpp 1.0, those are going to be the focus once all the initial reference encoder and decoder standards and issues are done. So in case anyone wondering it doesn't look as good as other competitors ( but still a lot better than JPEG ), those improvements are coming later.