JPEG-XL Image Support Returns To Latest Chrome/Chromium Code (phoronix.com) 17
After widespread backlash over its 2022 decision to remove JPEG-XL support, Google has quietly restored the image format in the latest Chrome/Chromium codebase. Phoronix reports: Back in December they merged jxl-rs as a pure Rust-based JPEG-XL image decoder from the official libjxl organization. At the end of December they did more JPEG-XL plumbing with the enums and build flags for the support. Now as of yesterday they wired up the JXL decoder! The jxl-rs-powered JPEG-XL image decoding is gated by the enable_jxl_decoder build flag but it's enabled by default.
So, all you "Google is Evil" haters (Score:1)
Wut ?
Re:So, all you "Google is Evil" haters (Score:5, Interesting)
If Google wasn't evil, we'd have working JXL in 2021. The lack of pressure also allowed Mozilla to waste years writing a NIH implementation in their own toy language. The benefits from JXL are pretty great all around, including both lossy and lossless, it's a pity we didn't get it sooner.
Google pushed their own WEBP and AVIF hard despite neither being as good as the rest. WEBP is very slow and hardly better than old JPEG, AVIF is at least usable but loses to other modern formats for anything except extremely low bitrates.
Re: (Score:2)
The C reference implementation of JXL is quite poor, and certainly not ready for deployment in a browser. Presumably the Rust one is much better.
That's the reason for the delay.
Re: (Score:2)
Google had the manpower to make it production ready in a few month.
Re: (Score:2)
That's not a webp problem but a problem with the CDN sending you the "best" image for your device. The extension is ignored, as the CDN does some (probably cached) on the fly conversion. You may be able to stop it by not sending an accept-header for image/webp with your request.
Re: (Score:3)
WebP was such a wasted effort, and AVIF was likewise. Both of them aimed to something non-productive, make files smaller by invoking the hardware lossy decoders on hardware. When the problem was not even that. The problem was the encoding side.
JPEG, even at 99% still produces visible artifacts. JPEG-XL solves that and adds the necessary transparency and HDR that is missing from JPEG, and the missing HDR from PNG (which is locked to sRGB.) PNG is not bad, at all, but it's core design was around a standard im
Re: (Score:3)
and the missing HDR from PNG (which is locked to sRGB.)
sRGB is a limitation on the gamut of PNG images, in terms of dynamic range, the dynamic range of PNG is really rather high, since it supports 16bpc and the transfer function doesn't do anything insane like rounding.
But also, PNG allows more than just sRGB gamuts:
http://www.libpng.org/pub/png/... [libpng.org]
Re: (Score:2)
If Google wasn't evil, we'd have working JXL in 2021. [snip] Google pushed their own WEBP
Google is one of the main contributors to JPEG-XL. There is nothing "own" about WebP. There is no way to for Google to monetize WebP. Google has similar level of control over WebP as JPEG-XL as both formats are developed by a committe dominated by Google contributions.
WebP was a format that was far more mature and widely used than JPEG-XL in 2021. WebP was a published standard in 2010, JPEG-XL only went to a proposal stage in 2018.
The internet is still dominated by JPEG. You're living in a complete fantasy
If it's Rust then it's OK (Score:3)
Rust is essentially the poster child of inclusivity; anything is getting included on the only basis that it is coded in Rust.
This is actually a good strategy to counter anything that gets censored going forward.
Re: (Score:3)
Or maybe when you include someone else's library you take an approach of picking a language that is memory safe given that memory safety in image decoders has lead to an embarrassing exploits in browsers... I mean it's not like Chrome had a major high risk vulnerability caused by the inclusion of OpenJPEG in 2015, or another in 2021 due to libjpeg-turbo...
Nah it must be to do with some Rust wokeness.
Re: (Score:2)
Rust is at least a well-liked language. Compare that with Clojure. I use an open source program written in Clojure. The choice of tech stack is such a shame! It's full of minor bugs and usability issues that I can't work on because learning the technology has negative value for me--so Clojure is never going to come before learning to, say, take photos or collect rocks.
They had to. (Score:5, Interesting)
https://www.theregister.com/20... [theregister.com]
If they want chrome to be able to show PDF files going forward, then JPEG-XL support is required as well.
Re: (Score:2)
The Chrome PDF reader doesn't have that much to do with the render engine. It isn't even distributed with Chromium.
This had nothing to do with the backlash (Score:2)
JPEG-XL is now a requirement for Chrome if they wanted a standards compliant PDF reader. But that is known here. Multiple people (including myself) have pointed out this very obvious outcome in different articles where the adoption of JPEG-XL in the PDF format was previously discussed:
https://news.slashdot.org/comm... [slashdot.org]
https://tech.slashdot.org/comm... [slashdot.org]