Thats a very comprehensive analysis, and I do not understand why it is being ignored.
Unfortunately, it seems like google do not want to participate in any discussion about this. They have now closed any discussion on the issues as "wontfix", despite hundreds of direct complaints on that particular forum. Many have been enthusiastic about it and have already invested much time and effort into supporting jpegXL. Unfortunately googles market position allows them to quash any codec they desire simply by not supporting it. I have registered a complaint with the Directorate General for Competition at the European Commission. Hopefully they will encourage Google to open a dialogue with the community about this decision. I suggest that others contact their equivalent representatives and make the same complaint. On Wednesday, 14 December 2022 at 17:45:07 UTC+2 Jon Sneyers wrote: > Here are my thoughts on the comparison performed by the AVIF team: > > https://cloudinary.com/blog/contemplating-codec-comparisons > > I'll copy my conclusion here: > > *The AVIF team provided a good starting point for doing a data-driven > comparison of image formats that can help to clarify the desirability of > adding new formats to the web platform. The compression results obtained by > the AVIF team do confirm the results we obtained through subjective > experiments and our own evaluations based on objective metrics. According > to the subset1 results > <https://storage.googleapis.com/avif-comparison/subset1.html>, the encoding > speed of JPEG XL s6 is similar to that of AVIF s7 and at these settings, 9 > out of the 13 metrics favor JPEG XL. Roughly speaking, at ‘web quality’, > according to the best available metric, AVIF gives a compression gain of > about 15% over mozjpeg > <https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-moz_t-1_avif-s6_moz-s0_ssimulacra2__bpp-0.1-3.0.png> > (or > more at the very low end of the quality spectrum), and JPEG XL gives a > compression gain of about 15% over AVIF > <https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-1_avif-s7_jxl-s6_ssimulacra2__bpp-0.1-3.0.png> > (except > at the very low end of the quality spectrum). These are the results > obtained by the AVIF team, and they do show the value of JPEG XL.* > > *In this contribution, I hope to have made some constructive suggestions > on how to further improve the comparison methodology, and on how to > interpret the results in the most meaningful way. Through constructive > dialogue, we can together make progress on our shared goals: making the web > faster, improving the user experience, and promoting royalty-free codecs!* > > In other words, I think there has been an unfortunate misinterpretation of > the data (essentially: because of aggregating in a way that focuses too > much on a not-so-relevant part of the plots), which has unfortunately lead > to an incorrect decision. I just hope this mistake can still be corrected, > preferably before M110 gets released. > > > > On Tuesday, December 13, 2022 at 5:19:40 PM UTC+1 Markus K. wrote: > >> I find it very concerning that this decision is has evidently been based >> on this bogous data: >> https://storage.googleapis.com/avif-comparison/index.html >> >> 1. The speed comparison is based on a buggy and outdated JPEG >> XL implementation. >> 2. The filesize comparison is based on a metric that JPEG XL was not >> tuned for. >> >> On top of that we seem to have completely misjudged ecosystem and >> industry demand for JPEG XL . >> And there seems to have been no consideration for certain features, which >> I don't want to reiterate here, that AVIF just doesn't support. I think >> there is a place for JPEG XL alongside AVIF. >> >> I would suggest to halt the removal of the JPEG XL experiment in Chromium >> until this is addressed to prevent further harm based on bad science. >> >> On Sunday, December 4, 2022 at 7:00:22 PM UTC+1 ⸻ “How Things Work” >> wrote: >> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 - Also >>> requesting a reconsideration of.JXL as a format due to cross-industry >>> interest from companies & consumers alike. Also on the grounds of it being >>> hindered by being buried behind an obscure flag within beta builds :/ >>> >>> Could just revert the removal till the M111 or 112 builds and see how >>> things stand then, would give time for debate *& a more fairer test of >>> market sentiment for this open JPEG standard*. >>> >>> On Friday 2 December 2022 at 23:05:15 UTC Tomáš Poledný wrote: >>> >>>> Now you should run your tests again with this: >>>> https://chromium-review.googlesource.com/c/chromium/src/+/4031214 >>>> >>>> Dne pátek 2. prosince 2022 v 22:20:19 UTC+1 uživatel Jarek Duda napsal: >>>> >>>>> If there are objectivity concerns, maybe there available tests of >>>>> independent sources? >>>>> For example Phoronix often uses libjxl in benchmarks - at least for >>>>> speed getting very different numbers: >>>>> https://www.phoronix.com/review/aocc4-gcc-clang/3 - maybe there are >>>>> available other independent tests? >>>>> >>>>> [image: obraz.png] >>>>> >>>>> On Friday, December 2, 2022 at 6:57:35 PM UTC+1 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/8a3907f1-dd5f-4d1b-981a-849a845c7508n%40chromium.org.
