Comment by CharlesW | Hacker News Reader

Comment by CharlesW | Hacker News Reader

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

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.

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

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

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)

Reply on news.ycombinator.com