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

[birdie]

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.

HW decoding of images is a very nice to have feature. JPEG is almost universally HW accelerated that's why smartphones decode large JPEGs almost instantly.

If JPEG XL is to replace JPEG as a format for storing photos, HW implementation is necessary though its authors claim that:

Do I need new hardware to encode and decode JPEG XL?

With JPEG XL, images are significantly better quality, compressed more efficiently, and have shorter specifications. Using software implementations, this encoding and decoding technology is designed to be computationally efficient, even on mobile devices, without additional hardware acceleration.

[SciK]

HW decoding of images is a very nice to have feature. JPEG is almost universally HW accelerated that's why smartphones decode large JPEGs almost instantly.

The ability for JPEG hardware decoding is near-universal but it seems to hardly ever actually get used. See e.g. https://stackoverflow.com/q/46497948

[Artim]

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.

If you want any image format to succeed JPEG when it comes to smartphone and (non-raw) camera photography, its encoding better be hardware accelerated. Not only because it's more efficient and battery power is still quite limited in such devices, but it's also much faster. When you expect device to basically make and save images without any delay and don't want to be forced to build in massive volatile storage, there's no other way than hardware acceleration. Or why do you think all Chips in desktop and mobile PCs and Smartphones/Tablets do include hardware acceleration for JPEG for years now? E.g. Intel QuickSync can decode JPEG in hardware since Ivy Bridge and encoding since Braswell.

[jstoik]

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

Sure: https://blobfolio.com/ (the home page is the most image-heavy page)

• The header and footer photos — black and white, grainy photographs — both benefited from JPEG-XL, as did the picture of the server stack.
• AVIF worked out best for the site screenshots (likely because of the hard color breaks).
• The tiny profile photos ended up being an even split between WebP and AVIF.
• WebP did a good job with most of the 1990s-style header animations, but a few of them were smaller in their original GIF form.
• Everything else is just SVG.

All of the JPEG/PNG sources were losslessly optimized before conversion, so were quite small to begin with. I visually A/B tested the next-gen candidates at each quality/quantizer setting before saving so there's a degree of subjectivity. I wanted images that looked "the same" as the original, but didn't need pixel-perfect representation. (If I wanted lossless, the breakdowns would have been quite different, likely a mixture of old-gen, WebP, and JXL, with no AVIFs whatsoever.)

The biggest caveat is I didn't dive into the endless advanced tuneables of JPEG-XL. It was time-consuming enough running through all the different quality steps without increasing the comparisons exponentially. I'm obsessive, but not that obsessive. Haha.

I also discarded any next-gen images that fell out of chronological/support order. There were plenty of cases where JPEG-XL came in second place, but any browser capable of decoding JXL would also be capable of decoding AVIF/WebP, so there's no point suggesting it as a fallback.

[carewolf]

If you want any image format to succeed JPEG when it comes to smartphone and (non-raw) camera photography, its encoding better be hardware accelerated. Not only because it's more efficient and battery power is still quite limited in such devices, but it's also much faster. When you expect device to basically make and save images without any delay and don't want to be forced to build in massive volatile storage, there's no other way than hardware acceleration. Or why do you think all Chips in desktop and mobile PCs and Smartphones/Tablets do include hardware acceleration for JPEG for years now? E.g. Intel QuickSync can decode JPEG in hardware since Ivy Bridge and encoding since Braswell.

Hardware encoding is different. I was talking about decoding. And it seems camera manufacturers are pushing for JXL so it will likely come at the same time as they switch to it.

[Artim]

Hardware encoding is different. I was talking about decoding. And it seems camera manufacturers are pushing for JXL so it will likely come at the same time as they switch to it.

I don't think cameras use the same SoCs as Smartphones. So even if they will adopt it, maybe Apple will too, but that doesn't mean any other device will.

[SciK]

Or why do you think all Chips in desktop and mobile PCs and Smartphones/Tablets do include hardware acceleration for JPEG for years now? E.g. Intel QuickSync can decode JPEG in hardware since Ivy Bridge and encoding since Braswell.

(Disclaimer: I am not the person you asked)

I honestly don’t know, because who actually uses QuickSync to encode and decode JPEGs?

[Artim]

(Disclaimer: I am not the person you asked)

I honestly don’t know, because who actually uses QuickSync to encode and decode JPEGs?

I can't tell you. But on the other hand I don't think SoC designers would waste valuable silicon if nobody would use it. Also just because QuickSync offers support for it doesn't mean no other API does. Windows probably as something for that similar to DXVA2, so I'd guess that at least the default Photos app uses that for hardware decoding (because why not when pretty much any device supports it), no idea how the situation is on Linux and macOS. Android has its media framework that devs can ask to automatically convert any video (and for all I know any picture) into something the app can handle. Is guess that's also hardware accelerated.

Of course these are all guesses, but as mentioned, why include it if nobody was using it?

[Sin2x]

It's APNG situation all over again. Last time it took considerable effor from the community to bring back the format, so go create some noise, people.

[skeevy420]

Wow. Those bullshit excuses backup my claim of Antitrust yesterday a lot more than they defend Google for making a rational, thought-out decision.

Their first and last claims apply to everything, everywhere, from everyone.

- Experimental flags and code should not remain indefinitely

Code shouldn't be an indefinite experiment.

You don't say.

- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome

Removing something reduces its maintenance burden? No shit, Sherlock. That's how it works.

Those bullshit reasons apply to everything.

Let's get to the meat and potatoes:

- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL

All the comments of support and praise from companies and people in your own bug tracker proves that wrong. All the companies and programs implementing JPEG-XL proves that wrong.

- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default

Every single independent benchmark I've seen proves that wrong outside of video clips.

So half their reasons are bullshit, the other half are outright lies, and the people in charge of the decision making process have a vested interest in the codecs that compete with JPEG-XL succeeding and JPEG-XL failing. Those last two are literally why we have antitrust laws.

In the United States, antitrust law is a collection of mostly federal laws that regulate the conduct and organization of businesses to promote competition and prevent unjustified monopolies.

Those decisions by Google engineers, who have a vested interest in the competing standards of AVIF and WebP succeeding, stifle their JPEG-XL competition by removing support for the JPEG-XL codec and then promote a Google technology monopoly by lying about the community interest in JPEG-XL and the incremental benefits that JPEG-XL offers.

That's ANTITRUST.

Forget writing the Google Bug Tracker, write your Senator or Representative; State and Federal. If you're not American: write to your equivalent government agency and have them pressure America to do something about American companies having too much power. It probably wouldn't hurt to write to Mozilla, Microsoft, and any other Google (Chrome) competitor you can think of to get them to pressure the government into doing something.