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-Encoding for JXL‑compressed JPEGs so clients can “save as .jpg” while benefiting from JXL on the wire.