Google Outlines Why They Are Removing JPEG-XL Support From Chrome

[brucethemoose]

That's a trivial bitstream decoder (if they even do that part in hardware) and then just DCT/IDCT that they'd need for other compression formats, as well.

JPEG-XL is a lot more complex and has more esoteric features. It would also be a highly speculative and long-range gamble to bet on JPEG-XL acceleration, whereas it's virtually guaranteed that SoCs will have hardware acceleration for AV1 decoding.

Not if Apple, Qualcomm and such have anything to say about it :P

[brucethemoose]

currently JXL both encodes and decodes slower then av1 by a large margin unless you are using rav1e for encoding the images or really low preset for aomenc, and no matter what you do right now, JXL decodes way slower then av1, this will can (and likely will) change in the future. that being said, because JXL supports progressive decoding JXL image is still typically "usable" first

... what? According to this paper, JXL decoding speed is on par with JPEG and like and much faster than HEVC (and therefore much much faster than AV1)

https://infoscience.epfl.ch/record/2...manuscript.pdf


Just looking at the past two threads, it almost feels like some entity is spreading misinformation about JXL.

[birdie]

... what? According to this paper, JXL decoding speed is on par with JPEG and like and much faster than HEVC (and therefore much much faster than AV1)

https://infoscience.epfl.ch/record/2...manuscript.pdf


Just looking at the past two threads, it almost feels like some entity is spreading misinformation about JXL.

Not misinformation per se, "FUD" sounds a lot more pertinent.

[brucethemoose]

Maybe its time for Michael to benchmark JXL and AVIF?

[Quackdoc]

... what? According to this paper, JXL decoding speed is on par with JPEG and like and much faster than HEVC (and therefore much much faster than AV1)

https://infoscience.epfl.ch/record/2...manuscript.pdf


Just looking at the past two threads, it almost feels like some entity is spreading misinformation about JXL.

Its pretty easy to test yourself but I have made several image sequences using jxl, jpeg, png and avif (no, not an avif animation, a legitimate sequence) avif sequences beat out jxl by quite a margin, I encoded bad apple, a pretty easy video since it's just black and white, and decoding that I get about 20-25~ fps, got much more on avif. though last time I checked decoding an image sequence was probably in april, so a lot might have changed since then. but I would be doubtful, I can always test it later though, ill need to remake the avif sequence since my poor google drive storing JXL sequences alone is kinda rough.

EDIT: Dav1d has had a lot of optimizations too, so it could be a fun thing to bench again, I think dav1d will still be better though

[jstoik]

Given the source, JPEG-XL can compress to 1/2 (or even better) of JPEG's size while having comparable image quality. Is that incremental for you?[/LIST]

Sure, if JPEG and JPEG-XL were the only two formats in existence.

Think of it this way:

• WebP almost always compresses better than JPEG (lossily) and PNG (lossily and losslessly).
• AVIF almost always compresses better than WebP (lossily).
• JPEG-XL can only sometimes compete with AVIF (lossily) and WebP (lossily/losslessly).

You're right that there's only so much that can be done before image quality tanks, but that's kind of the problem. All these different image formats are annoying for web developers and confusing for end users. Unless a new format can really offer something special, nobody wants it. Haha.

And to be clear, I don't think AVIF fits the bill either. Its lossless capabilities are a joke, and it takes forever to manually run through all the different quality settings to find the right lossy candidate. The disk savings aren't worth it.

I have to say i cannot replicate your experience, JXL typically encodes a decent amount smaller then avif in both lossy and lossless for me.

Every image format, even the older ones, have their relative strengths and weaknesses. My site has a lot of images with hard color breaks, which is something that AVIF is particularly good at dealing with. If I had wanted truly lossless conversions, though, AVIF would have fallen to dead last for sure.

[Quackdoc]

Every image format, even the older ones, have their relative strengths and weaknesses. My site has a lot of images with hard color breaks, which is something that AVIF is particularly good at dealing with. If I had wanted truly lossless conversions, though, AVIF would have fallen to dead last for sure.

do you have a set of sample photos I can test with? would be nice if we could meet on some common ground here

[Artim]

• Everything is incremental nowadays, you can only compress images so much before they turn any a blurry mess. Given the source, JPEG-XL can compress to 1/2 (or even better) of JPEG's size while having comparable image quality. Is that incremental for you?

If that was true, I would be very surprised when Google didn't already put heaven and hell in motion to make it the default at least for Google Photos. After all, any pictures uploaded by users are JPEGs. If they could save that much space (and that sounds like more saving than anything they apply right now) without even lowering image quality, that would mean that they would save a lot of storage that they could use for other stuff. That means either its usage would require much more power on Googles end or (like others suggested) they aren't convinced that they won't ever have to pay patent fees.

• People in this thread continue to claim that HW AV1F decoding is ubiquitous and that's absolute lies. I guess fewer than 1% of computing devices support AV1 hardware decoding. Yes, that little. There are at least a billion of PCs and at least 3 billions of smartphones. That makes it 4 billion of devices. Fewer than 40 million of them supporting AV1 sounds about right.

While that might be true at the moment, you can be assured that probably every SoC and GPU being released in the future will at least support AV1 hardware decoding and probably very soon even hardware encoding. For all I know the only chips currently supporting neither are Qualcomm and Apple chips. Not sure about Mediatek. And Apple is quite irrelevant as their Chips aren't used by anyone except themselves. Sure, they would first need to enable support in Safari, but web devs are used to always have fallback solutions for them since they just enabled WebP and VP9 support while everybody else was using that for years now.

Also, software based encoding and decoding for AV1 is pretty good. dav1d is optimized as much as possible for pretty much any SoC you could be using, even older ones. Not sure if stuff like SVT-AV1 can be used on iOS/Android, but after all, that's not really needed. Probably quite some time will go by before at least high end Android phones allow you to record in AV1 and probably video conference software won't use that much sooner. Sure, Cisco WebEx can use it, but only on Tower PCs with newer Chips through SVT-AV1 and only for screen sharing.

[carewolf]

That's a trivial bitstream decoder (if they even do that part in hardware) and then just DCT/IDCT that they'd need for other compression formats, as well.

JPEG-XL is a lot more complex and has more esoteric features. It would also be a highly speculative and long-range gamble to bet on JPEG-XL acceleration, whereas it's virtually guaranteed that SoCs will have hardware acceleration for AV1 decoding.

You dont need hardware accelerated image decoding. It isnt important even on phones or tiny embedded systems. Hardware accelerated video decoding is important everywhere because it saves energy at least, but images are at little over one order of magnitude less image data.

[quaz0r]

XL lives matter