Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

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. ---

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

On Tue, Jun 20, 2023 at 5:35 PM ― 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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

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, ― wrote: > > *Update:* >> > > > >> Firefox: >> In testing builds. (Neutral -

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

> > *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) > > - - - - -

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

I tried running the jxl progressive 8MP test on my PC and it looks wrong. I don't see it progressing. So I changed to internet tethering with my phone

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

Thanks for the updated decode timings! It would be interesting to add decode times for other cases than 8-bit 4:2:0 AVIF. In particular, 4:4:4 is the default in avifenc and cavif, and some people recommend using 10-bit for better compression results also in SDR. It would also be interesting to

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

Thats a very comprehensive analysis, and I do not understand why it is being ignored. Unfortunately, it seems like google do not want to participate in any discussion about this. They have now closed any discussion on the issues as "wontfix", despite hundreds of direct complaints on that

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

Does anyone from chromium/google intend to weigh in on this dispute of the validity of those benchmarks that were used to dismiss jpegXL? Independent benchmarks are showing that jpegXL is more performant, which would be in DIRECT OPPOSITION to the reasoning mentioned for the removal! You have

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

Here are my thoughts on the comparison performed by the AVIF team: https://cloudinary.com/blog/contemplating-codec-comparisons I'll copy my conclusion here: *The AVIF team provided a good starting point for doing a data-driven comparison of image formats that can help to clarify the

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

For the "decoding speed" graphs, it should be noted that a recent commit fixed a performance regression for JXL decode: https://chromium-review.googlesource.com/c/chromium/src/+/4031214 "For large images, this gives a 3x speed-up when decoding." On Friday, December 2, 2022 at 10:57:35 AM UTC-7

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

Thank you Yaowu Xu for providing the link to the tests. However, being made by AVIF engineers, aren't they skewed towards AVIF format? For example, Cloudinary conducted a test with contradictory results, where "JPEG XL can obtain 10 to 15% better compression than AVIF" and "JPEG XL encoding is

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

Following Jim’s previous note, here is a link to tests 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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

Given that AVIF is about 100 times more computationally intensive to encode than JPEG XL for the same quality, have you calculated how many excess tons of carbon dioxide will be emitted thanks to this decision? That would appear to be a significant cost borne by everyone outside of Google. On

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

One 'elephant in the room' question that is perhaps uncomfortable but I think it needs to be asked nevertheless, is if and how this "weighing the data" was done in a fair and transparent way without being influenced by conflicts of interest. I observe that several people within the Chrome

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

I won't reiterate most of the stuff as Jerry Glowacki has already mentioned most of it. If you think supporting JPEG XL is an unnecessary burden at least allow passthrough support similar to HEVC. It should

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

> > 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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

On Fri, Nov 11, 2022 at 4:58 PM 'Jim Bankoski' via blink-dev < blink-dev@chromium.org> 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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

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

Re: [blink-dev] Intent to Prototype: JPEG XL decoding support (image/jxl) in blink

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