Thanks for the updated decode timings! It would be interesting to add decode times for other cases than 8-bit 4:2:0 AVIF. In particular, 4:4:4 is the default in avifenc and cavif, and some people recommend using 10-bit for better compression results also in SDR. It would also be interesting to add decode times for '--faster-decoding' settings of libjxl, as well as recompressed JPEGs, as they decode somewhat faster.
I was doing some additional experimentation using this page: https://sneyers.info/browserspeedtest/index2.html and I am getting very large differences between 4:2:0 AVIF and 4:4:4 AVIF: 011.jxl: Decode speed: 41.72 MP/s | Fetch: 223.90ms | 100 decodes: 785.40ms 011-fd1.jxl: Decode speed: 45.05 MP/s | Fetch: 180.90ms | 100 decodes: 727.40ms 011-fd2.jxl: Decode speed: 47.10 MP/s | Fetch: 190.90ms | 100 decodes: 695.70ms 011-fd3.jxl: Decode speed: 48.77 MP/s | Fetch: 184.90ms | 100 decodes: 671.90ms 011-8bit420.avif: Decode speed: 86.30 MP/s | Fetch: 200.00ms | 100 decodes: 379.70ms 011-8bit444.avif: Decode speed: 2.91 MP/s | Fetch: 209.00ms | 100 decodes: 11261.10ms 011-10bit.avif: Decode speed: 2.86 MP/s | Fetch: 208.10ms | 100 decodes: 11455.70ms 011-12bit.avif: Decode speed: 2.85 MP/s | Fetch: 215.00ms | 100 decodes: 11507.10ms This could be a performance bug in the current Chrome integration of AVIF. Please note that my feedback was not only regarding decode timing. Best, -Jon. On Saturday, December 17, 2022 at 4:53:10 AM UTC+1 Yaowu Xu wrote: > 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/47bcec0b-bf30-4aa7-9f6b-98938e9c8916n%40chromium.org.
