> Given these positive signals, we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance. With those and our usual launch criteria met, we would ship it in Chrome.
JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support JPEG-XL in favour of AVIF which they were pushing. I’m glad to hear they’re finally reconsidering. Let’s hope this leads to resources being dedicated to help build and maintain a performant and memory safe decoder (in Rust?).
Nice example for how a standard, like PDF, can even persuade/force one of the mighty to adopt a crucial bit of technology, so that this may become a common standard in its own right (i.e. "cascading standards").
> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images
Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format.
For example, ask a normal social media user how they feel about .webp and expect to get an earful. The problem is that even if your browser supports the new format, there's no guarantee that every other tool you use supports it, from the OS to every site you want to re-upload to, etc.
That's also not the only potential gain. You get 20% gain on baseline compression but you also no longer need to store variants at different sizes since JPEG-XL's progressive decode is essentially equivalent to downscaling in terms of quality.
i.e. you can also serve downscaled & thumbnail versions directly from the original image.
Google's internal issue tracker, Buganizer (which the Chromium Issue Tracker is based on), refers to everything as a "bug". It's confusing, yeah. You get used to it.
I like how even the nus product (jpegli) is a significant improvement. I am in the process of converting my comic book collection. I save a lot of space and still use JPEG, which is universally supported.
JPEGXL doesn't refer to the same standard as JPEG. JPEGXL competes with AVIF in as a next-generation image format. It also has some properties that make it very nice for the web, such as the fact that a truncated (e.g., because the download hasn't completed yet) JPEGXL image is also a reduced-fidelity version of the same image, which with large images gets you much faster LCP compared to AVIF where the image remains unusable until fully downloaded.
Webp was a nice new format now widely adopted in browsers, yet it's barely supported in websites (upload) and softwares. It's hard to see this being different.
AVIF is trying to be a distribution format for the Web. JPEG XL is trying to be a complete package for working with image data. JPEG XL can replace OpenEXR in many workflows. AVIF simply cannot.
There's a lot of power in not having to convert for distribution.
18 comments
[ 2.6 ms ] story [ 38.8 ms ] thread> Given these positive signals, we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance. With those and our usual launch criteria met, we would ship it in Chrome.
https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
https://news.ycombinator.com/item?id=46021179
Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format.
For example, ask a normal social media user how they feel about .webp and expect to get an earful. The problem is that even if your browser supports the new format, there's no guarantee that every other tool you use supports it, from the OS to every site you want to re-upload to, etc.
I've seen enough software that gets petulant about not supporting webp to fight the Google monopoly or whatever to understand their frustration.
i.e. you can also serve downscaled & thumbnail versions directly from the original image.
> (this is the tracking bug for this feature)
Is it just me -- or it's confusing to use the terms issue / bug / feature interchangeably?
Why are we going backward?
AVIF is trying to be a distribution format for the Web. JPEG XL is trying to be a complete package for working with image data. JPEG XL can replace OpenEXR in many workflows. AVIF simply cannot.
There's a lot of power in not having to convert for distribution.