Google Revisits JPEG XL in Chromium After Earlier Removal
68 points by polywolf
68 points by polywolf
This is great news. A highlight is that JXL contains a lossless JPEG recompressor that provides a ~22% savings for old-school .jpg files with the original file bit-for-bit recoverable, which can hopefully mitigate the "what the heck is a WebP" aspect for users. (If this proposal were implemented, files could even save as .jpg when right-clicked, with JXL as only an over-the-wire optimization like gzip.) It has a good lossless mode as well.
For new lossy modes, JPEG XL appears to win at fast encoding for high quality and has a progressive mode, and AVIF clearly wins at getting results that look good with very few bits. When either's pushed to the point of having visible artifacts, who wins can depend on your aesthetics and needs--JXL is more likely to have visible DCT noise in the image and AVIF more likely to smooth low-contrast detail away entirely.
Good to see. To keep my site small I only support JXL via <picture> & the fallback JPEG or PNG since several image formats bloat the bundle to send. My original trigger was Google saying there wasn’t enough users serving the JXL format (which many users weren’t enabling since it was all behind feature flags). I also mentioned to the LibreWolf team at the time to remove the Nightly-only block for about:config which meant I could get the files too.
The real thing I want tho is support in cameras & camera apps even just the transparent compression option to save space on my devices.
Are there enough of JPEG-XL implementations now? Back then Google complained that we had not enough non-hobby implementations that could be tested against.
Beside the reference implementation, Wikipedia lists implems in C, Java, Python, C++ for low ressources, Rust from the Google team, and Rust from the community.
I particularly wonder how ready the Rust implems are, given that Mozilla thinks the C++ one is too risky for what jxl is worth, but a Rust one would be acceptable.
Only the Java and Rust ones are maintained at all. Also Java, and the later Rust ones won’t pass Google’s earlier policy as both classify as hobby projects, given that Java one is maintained by a single person, and the other one has just a few contributors listed. They wanted to have more than one implementation maintained by organisations who won’t simply rugpull those projects like the other listed implementations that are dead for 3-4 years.
The Java one doesn't look too healthy either, with a single contributor doing sporadic work.
Out of the two Rust repos, the community-driven one seems in a better state ? It has existed for longer, claims spec-conformance instead of being WIP, has reasonable-looking extra features... To prevent a rugpull, wouldn't it have been better if Google started co-maintaining the existing repo instead of starting a new one ? For anybody outside Google, a Google-owned repo doesn't offer much guarantees.
There’s a GitHub issue comparing the two Rust implementations: tirr-c/jxl-oxide – Relation with jxl-rs. The maintainer of jxl-oxide (the community implementation) wrote that jxl-oxide is currently too slow to be integrated into browsers:
The goal of jxl-rs is to integrate into browsers like Firefox, which have quite high standards regarding decode speed and memory efficiency. jxl-oxide was once considered for the integration, but the amount of work needed to match performance expectation is so much that a reimplementation with architecture borrowed from libjxl would work better.