Worth Noting: On top of Apple support, Mozilla is now looking into Jxl integration again. From neutral to positive.
Chrome will need feature parity even if chromium doesn’t have it. On Wed, 7 Jun 2023 at 15:32, ― <hmz2...@gmail.com> wrote: > > *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> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>> -- Sent from Gmail Mobile -- 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/CACf2j71RrPYrWOHEXFvkcL6%3Dx9tFfDK_id2C40Mo3HHQcxRj9w%40mail.gmail.com.
