Chrome Jpegxl Issue Reopened
Reopening and Maintenance Requirements
- Chrome’s JPEG XL issue has been reopened with an explicit ask: a performant, memory‑safe decoder plus a commitment to long‑term maintenance before enabling by default.
- There is skepticism about Google’s demand for “long‑term” support given its history of killing products, but others note Chrome (and a few core products) have very solid long‑term backing, partly because it’s critical to the ad business.
- Mozilla is described as having a similar position: no large, barely maintained C++ decoder, but openness to a fast, memory‑safe implementation (Rust work is underway, including in Firefox behind flags).
JPEG XL vs AVIF/WebP/JPEG
- Pro‑JXL arguments:
- Best migration path from existing JPEGs via byte‑exact, lossless recompression with ~20–30% size reduction.
- Much richer feature set than WebP/AVIF: high bit depth, HDR, many channels, huge images, layers, CMYK/spot colors, raw sensor data, patches/splines, progressive decoding usable as “free” downscaling/thumbnailing.
- Designed as a general‑purpose image format, not just a video codec repackaged for stills.
- Counterpoints:
- Some argue AVIF is better at “typical web image quality” (especially at very low bitrates) and comes “for free” with AV1 video decoders.
- Others provide examples suggesting that at realistic web bitrates JXL matches or beats AVIF, while AVIF only wins in extreme, visibly ugly compressions.
HDR and Accessibility Debate
- Long subthread on HDR:
- Some want HDR in browsers but with proper tone mapping and user controls; others want browsers to avoid HDR entirely because it can override brightness and physically hurt eyes.
- Discussion covers bit depth, gainmaps, banding behavior, and how content should respect room conditions and display capabilities.
- Consensus only on this: current HDR-on-the-web behavior is immature and standards/browsers need better defaults and accessibility options.
Adoption, Ecosystem, and UX
- Many worry about “yet another format” after WebP/AVIF, especially due to patchy tool and site support; users already hate .webp in workflows.
- JXL’s lossless JPEG bridge is seen as a key advantage: CDNs can transparently recompress and still deliver real JPEGs to legacy clients.
- PDF’s move toward JXL is viewed as an important pressure point that may force broader adoption.
Implementation Details
- Rust is the leading candidate for the new decoder; Wuffs is mentioned but dismissed as unsuitable for complex codecs.
- There’s also work on using HTTP
Content-Encodingfor JXL‑compressed JPEGs so clients can “save as .jpg” while benefiting from JXL on the wire.