I've been hearing about fights over JpegXL and WebP (and AVIF?) for years, but don't know much about it.
From a quick look at various "benchmarks" JpegXL seems just be flat out better than WebP in both compression speed and size, why has there been such reluctance from Chromium to adopt it? Are there WebP benefits I'm missing?
My only experience with WebP has been downloading what is nominally a `.png` file but then being told "WebP is not supported" by some software when I try to open it.
https://github.com/libjxl/jxl-rs jxl-rs is the underlying implementation. It's relatively new but Rust certainly calms security fears. This library wasn't really an option last time this came around in chromium.
No, memory safety is not security, Rust's memory guarantees eliminate some issues, but they also create a dangerous overconfidence, devs treat the compiler as a security audit and skip the hard work of threat modeling
A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language
I’ve recently compared WebP and AVIF with the reference encoders (and rav1e for lossy AVIF), and for similar quality, WebP is almost instant while AVIF takes more than 20 seconds (1MP image).
JXL is not yet widely supported, so I cannot really use it (videogame maps), but I hope its performance is similar to WebP with better quality, for the future.
I know, thats why I used max CPU settings. But when processing map tiles with a final total compressed size of half a terabyte, and each one is 200kB, taking 20s per tiles is prohibitively expensive.
Thanks, but just like WEBP I'll try to stick to regular JPEGs whenever possible. Not all programs I use accept these formats, and for a common user JPEG + PNG should mostly cover all needs. Maybe add GIF to the list for simple animations, while more complex ones can be videos instead of images.
> This consolidates JPEG XL’s position as the best image codec currently available, for both lossless and lossy compression, across the quality range but in particular for high quality to visually lossless quality. It is Pareto-optimal across a wide range of speed settings.
Wow. Nice. Big improvement if JPEG and PNG can be replaced by one codec.
Unfortunately, with Chromium dropping support for manifest-v2 extensions, and through that dropping proper support for uBlock Origin, I'm moving away from it. Not that that's easy, of course...
With Chrome being by far the most popular browser, it gaining support is almost a precondition for jxl gaining traction on the web.
Few would bother converting their images for Safari (and when it becomes enabled without a flag Firefox).
So this is good news even for people who don't use Chromium.
Reading the feature list of JpegXL on Wiki, it includes some interesting stuff like arbitrary numbers of channels for multi-spectral imaging and multi page documents, which for both better and worse starts to sound a lot like TIFF.
Why does the current design paradigm in image coding formats emphasise supporting as many features as possible in order to have “one image format to rule them all”? You do not see this in audio and does anybody think that Opus and FLAC should be combined into one format? Does the fact that Opus does not support lossless encoding make it worse?
32 comments
[ 2.4 ms ] story [ 52.2 ms ] threadFrom a quick look at various "benchmarks" JpegXL seems just be flat out better than WebP in both compression speed and size, why has there been such reluctance from Chromium to adopt it? Are there WebP benefits I'm missing?
My only experience with WebP has been downloading what is nominally a `.png` file but then being told "WebP is not supported" by some software when I try to open it.
so webp > jpegxl > png
No, memory safety is not security, Rust's memory guarantees eliminate some issues, but they also create a dangerous overconfidence, devs treat the compiler as a security audit and skip the hard work of threat modeling
A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language
https://github.com/search?q=repo%3Alibjxl%2Fjxl-rs%20unsafe&...
JXL is not yet widely supported, so I cannot really use it (videogame maps), but I hope its performance is similar to WebP with better quality, for the future.
Encoding time isn't as important as decoding time since encoding is generally a once-off operation.
Yeah, we all want faster encodes, but the decodes are the most important part (especially in the web domain).
Oldie goodie article with charts, comparing webp, jpegxl, avif, jpeg etc. avif is SLOW
Wow. Nice. Big improvement if JPEG and PNG can be replaced by one codec.
By one ? Ten maybe: webp, avif, ...
I wonder if this new implementation could be extended to incorporate support for the older JPEG format and if then total code size could be reduced.