Thanks for the feedback regarding speed tests, please see updated decoding timing info on latest builds on more platforms: https://storage.googleapis.com/avif-comparison/decode-timing.html
On Tuesday, December 13, 2022 at 8:19:40 AM UTC-8 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/64dfb3f7-5531-4ff5-819c-f280029bfe57n%40chromium.org.
