Given that AVIF is about 100 times more computationally intensive to encode than JPEG XL for the same quality, have you calculated how many excess tons of carbon dioxide will be emitted thanks to this decision? That would appear to be a significant cost borne by everyone outside of Google.
On Friday, November 11, 2022 at 7:58:28 AM UTC-8 jimba...@google.com 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/7db759b8-b455-41b9-876e-97e9763fc3efn%40chromium.org.
