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

[NM64]

But the point is that since AV1 support is becoming universal, AV1F is a given everywhere.

That doesn't mean it isn't the crappier choice though - you don't see AV1 videos on YouTube being paired with AAC audio or even MP3 audio despite YouTube packaging AV1 video streams into an MP4 container, do you?

No, they pair it with Opus because, in their words, "it's just so good." - heck, when VP9 encodes are not (yet) available, you'll even sometimes see YouTube's h.264 encodes be paired with Opus audio!

(I do believe I'm paraphrasing that quote though - it was a presentation from years ago by a Google AV1 dev responding to the question of an AV1-like project for audio, at which they replied to just use Opus as it's already really good)

Also I realize that the majority of YouTube's formats use separate audio and video streams, therefore they can be mixed-and-matched with no regard for what video and audio formats are more normally paired together. Nevertheless, that doesn't change that it does in fact default to Opus which definitely requires more CPU grunt to decode than AAC (you can verify this yourself by digging out low-end x86 CPU hardware, possibly most easily with desktop AMD hardware made before Ryzen due to stagnant single-thread IPC and widely-supported multiplier underclocking, and then set the CPU to a 1GHz clockrate or the like and play Opus audio then AAC audio through Audacious or the like), not to mention that they'd been defaulting to VP9 for years now even before VP9 hardware decoding was a thing in shipping hardware (causing people to write extensions that basically force h.264 instead specifically to take advantage of hardware decoding).

[Quackdoc]

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 like it matters all that much for still images, it isnt until you get to animations where it becomes a big deal

[NotMine999]

When I read the article and saw the timeline I figured Google was working in their own version of Internet time.

Sadly, the rest of the world that makes actual physical products that you can hold in your hand or touch has a slightly longer development cycle.

The concepts of "code fast, recompile at will, and break stuff" do not work everywhere.

[jarekZ]

looks like cutting costs or something

[jstoik]

"The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default."
That's just lies. That's so much lies Pinocchio's nose looks totally normal.

I don't know. I spent hours generating JXL copies of all the images on my own web site last year and found exactly the same thing. For my particular content and compression goals — "visually indistinguishable" — AVIF produced smaller output more often than all the other formats combined.

The keyword, I think, is "incremental". Any browser capable of decoding JPEG-XL can also decode WebP and AVIF, so it has no fallback value. It has to be the best of the best to justify its existence in a

<picture>

element, and for me at least, that almost never happened.

If it were born a decade earlier, it would be a different story.

But that said, I'm sure Google's actual reasons for killing it are more selfish. Haha.

[Quackdoc]

I don't know. I spent hours generating JXL copies of all the images on my own web site last year and found exactly the same thing. For my particular content and compression goals — "visually indistinguishable" — AVIF produced smaller output more often than all the other formats combined.

The keyword, I think, is "incremental". Any browser capable of decoding JPEG-XL can also decode WebP and AVIF, so it has no fallback value. It has to be the best of the best to justify its existence in a

<picture>

element, and for me at least, that almost never happened.

If it were born a decade earlier, it would be a different story.

But that said, I'm sure Google's actual reasons for killing it are more selfish. Haha.

the issue is that avif produces absolutely zero progressive decoding capable images, this means that people with slow and possibly lossy connections (very common for satellite, cellular and rural DSL connections all over the world) become useable way slower, this might be acceptable if you only have a couple images per page that need to load, but when you start to load even 7+ images this becomes a significant factor for many people. it can literally make or break a website. I dont think webp nor avif is a good candidate for next gen web images because of this, people treat it like its some forgotten problem, but bad internet is as prominent as ever.

and thats JUST progressive decoding that makes JXL better then avif or webp, this isnt even accounting for any of the other features like lossless compression of jpgs, and the flexible image thing where you can encode multiple resolutions into a single file with better overhead then just encoding multiple images.

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

[birdie]

I don't know. I spent hours generating JXL copies of all the images on my own web site last year and found exactly the same thing. For my particular content and compression goals — "visually indistinguishable" — AVIF produced smaller output more often than all the other formats combined.

The keyword, I think, is "incremental". Any browser capable of decoding JPEG-XL can also decode WebP and AVIF, so it has no fallback value. It has to be the best of the best to justify its existence in a

<picture>

element, and for me at least, that almost never happened.

If it were born a decade earlier, it would be a different story.

But that said, I'm sure Google's actual reasons for killing it are more selfish. Haha.

• AV1F is computationally a lot more expensive than JPEG-XL.
• 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?
• 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.

[brent]

Oh boy. If Google had applied the same kind of standards for WebP, that image format simply wouldn't exist today. And frankly WebP is a complete shitshow and supported nonetheless to this today.

[Quackdoc]

• AV1F is computationally a lot more expensive than JPEG-XL.

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

[birdie]

Oh boy. If Google had applied the same kind of standards for WebP, that image format simply wouldn't exist today. And frankly WebP is a complete shitshow and supported nonetheless to this today.

Mad kudos to this lad!