Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome Responds "No" to JPEG XL

groups.google.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Chrome Responds "No" to JPEG XL

#41

Post by erk__ »

jonsneyers wrote: post #33
gjsman-1000 wrote: post #28

Earlier quoted context omitted.

Well... within the last ~1.5 years, AVIF has become natively supported on Windows 10 and Windows 11 (Windows 1903 with a free Store extension), macOS 13 (no AV1, but yes to AVIF), iOS 16 (no AV1, also yes to AVIF), and Android 12. And in browsers, AVIF won Firefox, Safari, and Chrome all together as a default supported option, JXL did not and was only an optional feature flag in Firefox. Basically, AVIF won the OS-le…

Note a small detail you left out: all this happened to AVIF _after_ it was enabled by default in Chrome...

I don't think AVIF was ever behind a flag in Chrome, it was always enabled by default as long as it have been a part of it.

Re: Chrome Responds "No" to JPEG XL

#42

Post by lonjil »

CharlesW wrote: post #4

Rationale from thread: > 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 t…

Hah, they definitely didn't apply this criteria when they enabled AVIF by default in Chrome before the AVIF spec was even complete.

Re: Chrome Responds "No" to JPEG XL

#43

Post by jonsneyers »

erk__ wrote: post #41
jonsneyers wrote: post #33

Earlier quoted context omitted.

Note a small detail you left out: all this happened to AVIF _after_ it was enabled by default in Chrome...

I don't think AVIF was ever behind a flag in Chrome, it was always enabled by default as long as it have been a part of it.

Correct. Same for WebP. Both were enabled before their specs were even finalized.

Re: Chrome Responds "No" to JPEG XL

#44

Post by markdog12 »

dang wrote: post #14

Related: Removing the JPEG XL code and flag from Chromium - https://news.ycombinator.com/item?id=33412340 - Oct 2022 (42 comments) Chrome drops JPEG XL, “not enough interest” - https://news.ycombinator.com/item?id=33404840 - Oct 2022 (4 comments) Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940 - Oct 2022 (93 comments) Google Chrome Is Already Preparing to Deprecat…

I posted it because there has been a lot of activity, interested parties, etc.. on https://bugs.chromium.org/p/chromium/issues/detail?id=117805..., waiting for some kind of reply from the Chrome team. Despite interest, it looks like they haven't changed their mind, given the link I posted, and I thought it merited discussion.

Re: Chrome Responds "No" to JPEG XL

#45

Post by edflsafoiewq »

mike_hearn wrote: post #38
twotwotwo wrote: post #19

They have not closed a narrower bug about the lossless JPEG compression: https://bugs.chromium.org/p/chromium/issues/detail?id=110969... I think it's a legitimately different tradeoff because the recompression is not like a new lossy format--less code, plus you don't need the whole ecosystem to move, big sites and CDNs can transparently start using it--but still substantial (22% on JPEG content out there). And by bei…

The problem with using WASM is that because of their cache segmentation, every site that wants to render JXL would have to redownload the WASM decoder from scratch, and every page load that wants to render it would presumably have to JITC it from scratch too. The WASM model doesn't seem to be a good replacement for browser plugins. Amusingly, when Chrome killed off plugins one of the rationales they gave was "reducin…

The problem with using WASM is it doesn't create an ecosystem where you can save the JXL, open it in a editor, upload it yourself, etc. like a normal image file.

Re: Chrome Responds "No" to JPEG XL

#46

Post by excite1997 »

birken wrote: post #24
excite1997 wrote: post #13

Earlier quoted context omitted.

I think that's a fair argument, except they almost certainly did not apply the same yardstick to WebP.

Well in fairness when WebP support was added in Chrome over 10 years ago it was a massive, massive improvement over the existing image formats that were being commonly used on the web. JPEG XL's problem is that WebP has now existed for 10 years and has widespread support.

I don't think that's the entire story. Google actively pushed WebP, for example recommending it to webmasters in their page speed evaluation tools (and site performance, as judged by Google, is a factor in your search ranking).

If they invested the same resources into improving and promoting JPEG XL, we'd be using JPEG XL. I'm not saying the outcome is objectively worse, but ultimately, they did pick the winner here.

Re: Chrome Responds "No" to JPEG XL

#47

Post by Macha »

shrimp_emoji wrote: post #27
edflsafoiewq wrote: post #23

I increasingly despair over the possibility of any new image format getting traction. That means support in web browsers (functionally, Chrome) and on desktop (Windows explorer, etc.). WebP is probably the one that's advanced the furthest but AFAIK it doesn't even get thumbnailed in the Windows file browser and normies absolutely hate it since it won't work everywhere a PNG or JPEG will.

I'm not a normie, but I also hate WEBP "since it won't work everywhere a PNG or JPEG will" (i.e., an image viewer).

It's been a while since I've used an image viewer that doesn't support webp, to be fair.

Re: Chrome Responds "No" to JPEG XL

#48

Post by twotwotwo »

mike_hearn wrote: post #38
twotwotwo wrote: post #19

They have not closed a narrower bug about the lossless JPEG compression: https://bugs.chromium.org/p/chromium/issues/detail?id=110969... I think it's a legitimately different tradeoff because the recompression is not like a new lossy format--less code, plus you don't need the whole ecosystem to move, big sites and CDNs can transparently start using it--but still substantial (22% on JPEG content out there). And by bei…

The problem with using WASM is that because of their cache segmentation, every site that wants to render JXL would have to redownload the WASM decoder from scratch, and every page load that wants to render it would presumably have to JITC it from scratch too. The WASM model doesn't seem to be a good replacement for browser plugins. Amusingly, when Chrome killed off plugins one of the rationales they gave was "reducin…

A JXL contributor says full JXL (not just the recompression) can fit in 174kB, and thinks a smaller version could fit in 50: https://news.ycombinator.com/item?id=33414678

If you have large JPEGs it's not hard to earn the bandwidth cost back. I am definitely curious about other aspects of WASM performance including speed on first run.

Re: Chrome Responds "No" to JPEG XL

#49

Post by anecdotal1 »

sedatk wrote: post #20
ugjka wrote: post #15

Earlier quoted context omitted.

Phones, TVs, Toasters

Okay, how does it cost to them?

Yeah it's not like it's video and we need a hardware decoder.

I doubt device vendors are thoroughly testing every image and video format that the software on the device can render.

Smells to me like BS

Re: Chrome Responds "No" to JPEG XL

#50

Post by rektide »

Is it possible to still write pages with JXL as an option a xompatibpe browser could use/prefer? It'd be great to see this just keep happening anyways. Is this just a content-negotiation question? How else might a page declare it would like to use certain resources, if the broeser supports it, else fallback?
Post reply on HN