For the "decoding speed" graphs, it should be noted that a recent commit fixed a performance regression for JXL decode: https://chromium-review.googlesource.com/c/chromium/src/+/4031214 "For large images, this gives a 3x speed-up when decoding." On Friday, December 2, 2022 at 10:57:35 AM UTC-7 Yaowu Xu wrote:
> Following Jim’s previous note, here is a link to tests > <https://storage.googleapis.com/avif-comparison/index.html> AVIF > engineers ran comparing AVIF to JPEG, WebP and JPEG-XL. The tests provide > all the necessary code, test sets and parameters to reproduce the test > results. Developers are welcome to ask questions and submit feedback to > avif-f...@googlegroups.com. > > > Apologies for the delay in providing this information. We wanted to be > sure that everyone would be able to duplicate and verify these results for > themselves before posting. > > > On Friday, November 11, 2022 at 7:58:28 AM UTC-8 Jim Bankoski wrote: > >> Helping the web to evolve is challenging, and it requires us to make >> difficult choices. We've also heard from our browser and device partners >> that every additional format adds costs (monetary or hardware), and we’re >> very much aware that these costs are borne by those outside of Google. When >> we evaluate new media formats, the first question we have to ask is whether >> the format works best for the web. With respect to new image formats such >> as JPEG XL, that means we have to look comprehensively at many factors: >> compression performance across a broad range of images; is the decoder >> fast, allowing for speedy rendering of smaller images; are there fast >> encoders, ideally with hardware support, that keep encoding costs >> reasonable for large users; can we optimize existing formats to meet any >> new use-cases, rather than adding support for an additional format; do >> other browsers and OSes support it? >> >> After weighing the data, we’ve decided to stop Chrome’s JPEG XL >> experiment and remove the code associated with the experiment. We'll work >> to publish data in the next couple of weeks. >> >> For those who want to use JPEG XL in Chrome, we believe a WebAssembly >> (Wasm) implementation is both performant and a great path forward. >> >> >> Jim >> >> >> On Monday, October 31, 2022 at 11:01:44 AM UTC-7 ash...@scirra.com wrote: >> >>> Apologies for bringing back an old thread, but I thought it was >>> important to bring this up here. >>> >>> I was surprised to read that Google are abandoning their efforts to >>> implement JPEG-XL: >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 >>> >>> As I understood it, JPEG-XL brought significant improvements over >>> existing image formats, and had a lot of interest in the technology world. >>> However the reasons cited were apparently lack of benefits and lack of >>> interest. >>> >>> I for one was interested in this format and the improvements it would >>> bring, and it seems many others are disappointed too. Can Google explain >>> how they came to this conclusion? How are they evaluating the benefits and >>> interest? Even this intent to prototype lists many of the purported >>> benefits and the extent of the interest, which makes this reversal >>> particularly hard to understand. >>> >>> >>> >>> >>> On Tue, 30 Mar 2021 at 20:20, 'Moritz Firsching' via blink-dev < >>> blin...@chromium.org> wrote: >>> >>>> Contact emails >>>> >>>> >>>> *de...@chromium.org, firs...@google.com, lo...@google.com, >>>> jy...@google.com*Explainer >>>> >>>> >>>> *https://jpeg.org/jpegxl/ >>>> <https://jpeg.org/jpegxl/>http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf >>>> >>>> <http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf>*Specification >>>> >>>> >>>> *https://arxiv.org/abs/1908.03565 <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 >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EImage>* >>>> 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 <https://www.chromestatus.com/features#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 >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1539075>Edge/Safari - no >>>> signals yetGecko: No signalWebKit: No signalWeb 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 >>>> <http://encode.su>, r/jpegxl, <https://reddit.com/r/jpegxl/> discord >>>> <https://discord.com/channels/794206087879852103>, ...*Is this feature >>>> fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> >>>> *No, but planning to have complete tests before shipping. *Tracking bug >>>> >>>> >>>> *https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 >>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1178058>*Launch >>>> bug >>>> >>>> >>>> *https://bugs.chromium.org/p/chromium/issues/detail?id=1178040 >>>> <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 >>>> <https://www.chromestatus.com/>. >>>> >>>> -- >>>> >>> 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/CAMM7wxZEBJ8uf5OB%3DR1j2J6w5OF8OT1o%2B%2BN4t8G_brOo-Zgh_w%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMM7wxZEBJ8uf5OB%3DR1j2J6w5OF8OT1o%2B%2BN4t8G_brOo-Zgh_w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34e5190e-530f-46c4-827b-36c6373ee816n%40chromium.org.
