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/a653b898-b6b2-4e5b-86df-a999e5e70caen%40chromium.org.
