> > *Update:* >
> Firefox: > In testing builds. (Neutral - depending on support from community.) > > Safari (& iOS): > Currently undergoing testing & implementation as of latest iOS/macOS dev > previews. (Positive.) > > Web Developers & Community: > (Very Positive Support) > > - - - - - - - - - > Support added by a lot of apps with more showing support should Google > Chrome (and ChromeOS) support the format by default & Android Community has > requested support for it too alongside some in the Windows Insider > Community. > > This would also be welcomed by the Digital art community, the medical > community for scans, and have benefits for streamlining online image > storage with a healthy balance of quality vs size taken up. > > Fwiw, I also support JPG-XL adoption to have healthy competition with > AVIF/WebP and I'm neither a developer nor a representative of any company. > Just a tech user enthusiast, I've also met countless of people supporting > the view. > > 1,000 in Chromium bug tracker over 500 in Mozilla's Trending Feature > Requests, then you have those on reddit and Phoronix wishing to raise their > support for the matter. > > But let's not beat around the bush here, support from Chromium/Chrome can > make or break something like this, regardless of whether or not it is > logically right to do so, Google knows that fact all too well by now. > > > > On Tue, 6 Jun 2023, 11:50 Albert Andaluz González, < > albertanda...@gmail.com> wrote: > >> 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/CACf2j70sic4eU626jU-Qi3JhQrWpH74jQ5V2yrFn3t%2BqgieKRg%40mail.gmail.com.
