Any updates on this? Or changes in stances? On Thursday, September 19, 2024 at 3:44:05 PM UTC+1 ― wrote:
> Many apologies for messaging on a seemingly dormant thread but I feel it's > worth me pointing out that alongside the new push for JPEG-XL support in > the latest iOS/iPhone releases, there are also signs that Microsoft might > be looking at adding support into their products, and another interesting > sign would be this - > https://github.com/mozilla/standards-positions/pull/1064 perhaps it's > worth revisiting now that the 'no signal' classification no longer applies > in multiple cases here? Things have definitely changed since jxl first came > up for Chromium/Chrome > > On Monday 26 June 2023 at 02:37:01 UTC+1 Andy Foxman wrote: > >> >> Hello, >> so when will be the JPEG XL issue reopened? >> Request for reopen here: >> https://bugs.chromium.org/p/chromium/issues/detail?id=1451807 >> >> Since Safari added support, I think it deserves new discussion. >> Original issue: >> https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 >> >> Thanks. >> --- >> >> Dne úterý 20. června 2023 v 17:51:12 UTC+2 uživatel Simon Pieters napsal: >> >> On Tue, Jun 20, 2023 at 5:35 PM ― <[email protected]> wrote: >> >> Worth Noting: On top of Apple support, Mozilla is now looking into Jxl >> integration again. From neutral to positive. >> >> >> This is incorrect. https://mozilla.github.io/standards-positions/#jpegxl >> is still neutral. >> >> cheers, >> >> >> Chrome will need feature parity even if chromium doesn’t have it. >> >> >> On Wed, 7 Jun 2023 at 15:32, ― <[email protected]> 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, <[email protected]> >> 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 >> [email protected]. >> >> >> 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 [email protected] 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 < >> [email protected]> wrote: >> >> Contact emails >> >> >> *[email protected], [email protected], [email protected], >> [email protected]*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 [email protected]. >> >> 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 [email protected]. >> >> >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf2j71RrPYrWOHEXFvkcL6%3Dx9tFfDK_id2C40Mo3HHQcxRj9w%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> -- >> Simon Pieters >> https://www.mozilla.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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d8b6b280-5630-4cd7-93ba-0f70487f2ccen%40chromium.org.
