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 ― <hmz...@gmail.com> 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, ― <hmz...@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, <albert...@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 > <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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b0ef5a55-dca0-4d11-88af-0c455997d414n%40chromium.org.
