One 'elephant in the room' question that is perhaps uncomfortable but I think it needs to be asked nevertheless, is if and how this "weighing the data" was done in a fair and transparent way without being influenced by conflicts of interest. I observe that several people within the Chrome organization are proverbially wearing two hats: one is to "help the web to evolve" as a developer of the single most important web browser, the other is to push the adoption of codecs they helped create. These two interests can of course be perfectly aligned (as is the case with the AV1 video codec, for example), but they can also conflict.
How can we make sure that this particular decision on JPEG XL gets made in a fair and transparent way? Because as it is right now, there is definitely a perception that this is an instance of the "not invented here" syndrome and that AVIF proponents within Chrome are essentially being prosecutor, judge and executioner at the same time. Obviously I am a JPEG XL proponent myself so I am biased myself. My personal opinion is that both formats complement one another: AVIF is a great replacement for GIF and WebP while JPEG XL is a great replacement for JPEG and PNG, and both bring substantial improvement to the web platform. Wouldn't it be wise to invite external experts — who have no particular 'horse in the race', so to speak — to investigate this question, review the existing data, gather their own data, weigh it, and suggest the best way forwards? I think this would be a better approach to make sure that Chrome in the end "does the right thing". Best, -Jon. On Friday, November 11, 2022 at 4:58:28 PM UTC+1 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/e23a4b38-11ca-4426-991a-321e24f5f145n%40chromium.org.
