The Chrome status page (https://chromestatus.com/feature/5188299478007808) should now mention that Webkit supports jpeg-xl, at least for Safari 17 beta onwards. https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes See also relevant WWDC2023 session (Explore media formats for the web) : https://developer.apple.com/videos/play/wwdc2023/10122/ (available 8th June)
El sábado, 17 de diciembre de 2022 a las 22:55:47 UTC+1, ⸻ “How Things Work” escribió: > > 800 Users with hundreds of comments seem to be distrustful after the > previous ones, can't that be considered or taken into account for the > request? There are many developers from quite a few big name companies such > as Facebook/Meta & Intel too. Also use cases highlighted, such as Medical > Imaging. Regardless of how this is spun, it would seem that this format > would see widespread adoption & implementation across multiple industries > if it were permitted to be enabled by default. > > https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 - One again > leaving this link for reference, please reconsider, a lot of work would go > to waste when we could all just compromise and improve on the format in the > future > On Saturday 17 December 2022 at 03:53:10 UTC 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/b71b72b6-0f23-4a98-b030-bcf73aa89b80n%40chromium.org.
