Chrome Responds "No" to JPEG XL • Hacker News Board

Re: Chrome Responds "No" to JPEG XL

#51

Post by pvg » Fri, Nov 11, 2022, 9:54 PM UTC

markdog12 wrote: post #44

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.

The interest is largely contained to that issue and its forum and you've already had the issue itself discussed in a recent post (beside the other recent posts).

The overlap between advocacy and interesting conversation is not zero but repetitions diminish it a lot. And just generally, even if it's not the intent, posting project bug trackers on HN (which is much bigger than most bug trackers) tends to have effect of brigading the particular issue which is not great for the project and not great for HN.

Re: Chrome Responds "No" to JPEG XL

#52

Post by Wevah » Fri, Nov 11, 2022, 10:44 PM UTC

rektide wrote: post #50

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?

Sure, with the element: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pi...

Re: Chrome Responds "No" to JPEG XL

#53

Post by Zandikar » Sat, Nov 12, 2022, 2:46 AM UTC

Macha wrote: post #47

shrimp_emoji wrote: post #27

Earlier quoted context omitted.

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.

To be fair, there is no bundled or built in app in windows 11 that associates with or can view webp by default. Edge can, but that's not a photo app, and you have to explicitly tell it to (open with) or explicitly associate it with that file type. In other words, it's not natively supported in the current version of Windows.

That's a trivial "problem" for the HackerNews audience, but it's a pain point for webp with the broader windows audience.

Re: Chrome Responds "No" to JPEG XL

#54

Post by sk65535 » Sat, Nov 12, 2022, 9:33 AM UTC

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.

For a recap of WebP history: https://bit.ly/image_ready_webp_slides

If you look at slide #14, you'll see Opera was an early adopter. Firefox published a "No" blog-post in 2013, and Safari removed WebP support from Sierra preview in 2016, eventually adding it back in 2020. Stuff happened.

And yes, when WebP was created there was a real, non-incremental, need for a Web-oriented image format. Nowadays, it's just incremental improvement on this idea for browsers.

(disclaimer: WebP initiator here)

Re: Chrome Responds "No" to JPEG XL

#55

Post by Gigachad » Sun, Nov 13, 2022, 1:57 AM UTC

Scaevolus wrote: post #8

Disappointing. I'll have to figure out the JXL WASM polyfill. Maybe if I wait a few months someone else will do it for me? There's https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/... that provides `JXLModule.decode(data: BufferSource): ImageData | null`, but for a polyfill I suspect you'd want a method to get the dimensions of the image and an IntersectionObserver to defer actually decoding the image unti…

If hardware decoding support wasn't going to happen, is there really any problem with a polyfill since presumably the performance would be similar? I suppose if it's just one image, the weight of the polyfill download may make the savings in image compression worthless.

Re: Chrome Responds "No" to JPEG XL

#56

Post by JyrkiAlakuijala » Mon, Nov 14, 2022, 2:52 PM UTC

ZeroGravitas wrote: post #6

I really like JPEG XL tech, seemed like the first format that could completely replace animated gif, png, jpeg with a simple upgrade path and backwards compatability story for lots of weird corner case usages. I do have sympathy for the not adding lots of formats to the web argument though.

we could still remove both WebP and AVIF and go with JPEG XL only

Re: Chrome Responds "No" to JPEG XL

#57

Post by JyrkiAlakuijala » Mon, Nov 14, 2022, 2:53 PM UTC

Scaevolus wrote: post #8

Disappointing. I'll have to figure out the JXL WASM polyfill. Maybe if I wait a few months someone else will do it for me? There's https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/... that provides `JXLModule.decode(data: BufferSource): ImageData | null`, but for a polyfill I suspect you'd want a method to get the dimensions of the image and an IntersectionObserver to defer actually decoding the image unti…

several wasm solutions will soon appear in libjxl github

Re: Chrome Responds "No" to JPEG XL

#58

Post by JyrkiAlakuijala » Mon, Nov 14, 2022, 2:56 PM UTC

ZeroGravitas wrote: post #40

edflsafoiewq wrote: post #35

Earlier quoted context omitted.

Webp's lossy mode may be uninspiring, but it also has a good lossless mode and supported both lossy and lossless transparency.

Worth noting that JPEG XL has a pretty good lossless mode too, however, I think in many cases you actually want to just use a lossy AVIF or JPEG XL in places you'd previously have used "lossless". It was kind of an artificial split, much like text, alpha transparency or line drawing might be done as PNG, not because you wanted them to be "lossless" but because JPEG would mess them up due to a lack of tools for reprod…

don't look there -- that 'lossless' comparison is not actually lossless

here, a better comparison: https://siipo.la/blog/whats-the-best-lossless-image-format-c...

this one is also good: https://www.reddit.com/r/AV1/comments/fjddcj/lossless_image_...

basically: JPEG XL does things right, WebP lossless is also not bad (14.8 % worse than JPEG XL), PNG is ok for its age (46.3 % worse), AVIF didn't focus on lossless (63.0 % worse)