Chrome Responds "No" to JPEG XL | Hacker News Reader

Chrome Responds "No" to JPEG XL

groups.google.com

54 pointsmarkdog1255 comments

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 Deprecate JPEG-XL - https://news.ycombinator.com/item?id=33383880 - Oct 2022 (20 comments)

Also:

The case for JPEG XL - https://news.ycombinator.com/item?id=33442281 - Nov 2022 (207 comments)

Is there SNI (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...) in the current post? - if there is I can't find it.

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.

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 the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?

> After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We'll work to publish data in the next couple of weeks.

> For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward.

> Jim

It was an opt-in feature, so what data did they weigh?

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.

Firefox didn't add Webp support for a long time, because it wasn't a massive, massive improvement over the existing image formats.

https://research.mozilla.org/2013/10/17/studying-lossy-image...

More recent coverage: https://siipo.la/blog/is-webp-really-better-than-jpeg

Neither of your links support your claim that Firefox avoided adding Webp support because it wasn't technically superiour.

Instead, what happened was that WebP started to be used on the web and this broke websites for Firefox users.

Since Firefox is by no means dominant on the web, we had to follow suit or lose more users.

I'm not sure what you are saying.

Mozilla didn't support WebP for years. I'm fairly certain one of the official reasons they gave for not doing it was that it wasn't a massive jump in quality over JPEG, which obviously would have been good for the web if it was true and motivation for them to support it sooner than they did.

Notably, when they did add it, Edge did so around the same time, which seems to me suggests some politics in the background, (not in a conspiracy sense, just an agreement based on interperability) which I suspect might apply this time too.

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 reproducing non-natural photo content.

See the lossless comparison here for more:

https://jakearchibald.com/2020/avif-has-landed/

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)

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.

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)

Which isn’t a real rationale. It says what some common problems are but not why specifically jpeg-xl is unfit. Are we really to believe that a new format is going to be perfect out of the gate? Surely there’s a path to introducing a new format that doesn’t screw over 3rd parties. I mean Google has been iron fisted with certain other formats… Something else happened here.

Other browsers can still add JPEG XL support and that would put pressure on Chrome to do the same. They just don't want to be the first mover.

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-level support race by a landslide. And then got natively supported in all the common browsers by a landslide. JXL hasn't taken any victories in OS-level support yet, or any victories as an enabled-by-default option in any browser. With the winner increasingly becoming obvious, time to cut the losses on JXL and run. And thus the "we don't need another format" argument when AVIF is clearly winning now.

Part of this may be as well that AVIF is basically just an AV1 still. If you implement AV1, you've got 95% of your AVIF support already done.

Edit: And for those wondering why AVIF won, it might just be timing. The AVIF spec was finalized in 2019, while JXL was only informally finalized in 2020, and had different parts formally finalized in 2021 and 2022. AVIF had the head start and the implementation advantage.

Edit 2 for @jonsneyers: True... but AVIF was ready to go before JXL, and so logically was enabled first. Chrome enabled AVIF before JXL even had an informal spec completed (Chrome enabled AVIF on August 24, 2020; versus, December 24, 2020 for the informal JXL spec being "finished", with formal standardization dragging on into 2021 and 2022). I take that as a sign the JPEG XL team was way too late and needed to be ~2 years quicker. When your competition has literally designed, formalized, implemented, and enabled a spec before you've even finished the informal standard, you're toast.

Edit 3: And a third reason, because I've not found enough already. If you join the AOM, you don't just get patents for AV1 and AVIF - you also get assistance from all the other members to defend AVIF and AV1 from patent lawsuits on any of them. JXL is just Apache 2, which means it is patent-free... from contributors only, outsiders can still sue JXL implementers for patents. As a result, AVIF has a much, much larger stick to hit patent trolls with - definitely preferable for an open format.

Edit 4: Because I'm probably going to reference this post in the future, I guess I'll add yet another reason. AV1 is a new standard being widely worked on and accepted by almost everyone, and AVIF is following. JPEG meanwhile has released JPEG 2000, JPEG XR, JPEG XS, and JPEG XT standards, all of which failed to take off. What makes anyone think that JPEG's "5th time's the charm" replacement for JPEG will be successful? I wouldn't hope in it. Neither, probably, would any other tech company, who would just look at it as the JPEG Forum's latest fad.

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.

That seems like a rather high bar to reach given that almost every other format got to do it the other way around (browser support before hardware level encoders etc).

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

> JPEG XL is a royalty-free raster-graphics file format that supports both lossy compression and lossless compression. It is designed to outperform existing raster formats and thus become their universal replacement.

> The bitstream was informally frozen on 24 December 2020 (...) The file format and core coding system were formally standardized on 13 October 2021 and 30 March 2022 respectively.

source: https://en.wikipedia.org/wiki/JPEG_XL

" If a tree falls in a wood, and there is no one around, does it make a sound ?" - Chrome, probably

This is ridiculous. Chrome's influence is too big and Google is basically dictating how the web works. The whole world must bow to what a select group of people decide. This internet explorer level of oppression has to stop.

Sure. Downvote me. Perhaps you weren't around when IE was still a thing. As a webdesigner back in those days your job was basically working around IE6's limitations and quirks. _You couldn't even use transparant PNG's ffs_. MS didn't give a flying F and only started improving IE again when they started losing big chunks of marketshare. We are heading towards that exact same situation right now.

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 until it scrolls into view. Having to load the image with XHR is annoying.

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.

several wasm solutions will soon appear in libjxl github

It's hard to be anything but skeptical about the intent behind this decision, considering that the competing emerging standard (WebP) is one that Google controls.

This is one reason why I am thankful that Apple still only allows webkit on iOS even if philosophically I believe people should be able to run the software they want on their phone — it's basically the only check against pure Google hegemony over the web.

> can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?

They did not show this restraint at all when it came to implementing and pushing their own formats.

This is a really strange take, because Apple does not support JPEG XL and was never going to support it. And since nobody else can bring that support to iOS either, the format as a whole is dead to the web.

(And, uh, I don't know where you're getting webp from here. The competition for this generation of image formats is AVIF; AVIF has been blessed by Apple, so no matter how distasteful it is that's what we'll get.)

> They did not show this restraint at all when it came to implementing and pushing their own formats.

JPEG XL was largely a Google-created format.

The Chrome team did not create JPEG XL, that was a totally different team. The Chrome team did create WebP and was heavily involved in the creation of AVIF.

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 being very CPU-light it fills a fairly large gap where people are not ready to use AVIF, which needs either dedicated hardware or tons of CPU to encode.

One thing this is right about is a WASM polyfill is interesting. With that and a ServiceWorker, you can make the recompression pretty transparent (right-click saves a .jpg) but still save your 22%. The performance penalty of doing it in WASM is a question, but it's definitely possible.

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 "reducing code complexity". The enormous bloat in the code and HTML5 specs that followed did many things, but reducing Chrome's code complexity isn't one of them.

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.

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.

> We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware),

What's that mean? What's a browser partner? What's a device partner? How do additional formats cost to those "partners", as the format handling would be performed by Chrome already?

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

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

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.

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.

> 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

To add some info, JPEG XL can still be enabled on the latest Edge, Opera, and Firefox Nightly versions. It can be enabled on Chrome 91 - 110 (not included).

>After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We'll work to publish data in the next couple of weeks.

You know, if you did that in the other order, you might avoid a lot of sturm und drang.

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 <picture> element: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pi...

Could supporting JPEG XL natively be an opportunity for Edge and Firefox to compete with Chrome seriously?

So does this mean we are getting AVIF or WebP or both? It's not clear to me which is the "blessed" format out of these. HEIC is ofcourse there but proprietary.

WebP has been in Chrome for years, and isn't going anywhere. WebP2 is cancelled. AVIF is still arriving and is Chrome's preferred choice over JXL. HEIC was not supported by Chrome until recently, but only on devices where the manufacturers already paid for decoding.

One advantage for AVIF is that an AVIF file is very close to just being an AV1 still, so if you implement AV1, you've basically got 95% of AVIF already. AVIF is also now natively supported by both Windows, macOS, iOS, and Android, whereas JXL is supported natively by none. The fact that AVIF has gotten OS-level support and JXL hasn't is a sign JXL is dead.

Thanks for a concise lay of the land, I'm curious about this stuff but not on top enough of the happenings.

Reply on news.ycombinator.com