Google Revisits JPEG XL in Chromium After Earlier Removal

Original Article ↗ Hacker News Discussion ↗

Ecosystem & Platform Support

  • JPEG XL support remains fragmented: Safari supports it via system Image I/O, Windows 11 has an optional codec extension, but Firefox and Windows lack out‑of‑the‑box support.
  • PDF 2.0 recommends JPEG XL (and Brotli), especially for HDR, but commenters argue that PDF support alone won’t force browsers to support JPEG XL as a general web image format; browsers already decode formats inside PDFs (e.g., JPEG 2000) that they won’t render on the web.
  • Windows is cited as “modular” for modern codecs in general (video, audio, and image), requiring store-installed components beyond legacy JPEG/PNG/GIF.

Google/Chromium’s Position

  • Chrome’s stance has shifted from active rejection to “willing to accept” JPEG XL, on conditions: Rust-based implementation, usual security and maintenance guarantees, and long‑term ownership.
  • Existing C++ libjxl-based patches are seen as dead ends for Chrome; instead, a Rust implementation (jxl-rs) from Google Research is the likely path.
  • Several comments stress that “Google” isn’t monolithic: the JPEG XL team has pushed the format while the Chrome org has been wary of importing a large multithreaded C++ codec.

HDR, Wide Gamut, and User Frustration

  • A major thread laments that in 2025/26 it’s still practically impossible to reliably share wide‑gamut, true HDR still images across platforms and apps (messaging, social, email) without them degrading to SDR or breaking.
  • Ultra HDR / JPEG gain‑map approaches (including Android’s UltraHDR and Apple’s HEIF‑based variants) are called a “hack” that often produces artifacts or cross‑vendor incompatibilities.
  • Others counter that HDR content can be viewed today (HDR PNGs, P3 web images, HDR JPEG XL in Safari), but critics say the problem is consistent, cross‑platform sharing, not isolated demos.
  • There’s confusion and disagreement over what counts as “HDR” (multi‑exposure/tone mapping vs. 10‑bit+ PQ/HLG style HDR with gain maps and >1000‑nit displays).

Technical Comparisons & Performance

  • JPEG XL is described as both lossy and lossless, already used in camera RAW (DNG), medical imaging, and being evaluated in cinema/art workflows.
  • Lossless JPEG XL is praised as highly competitive in compression and complexity; only proprietary codecs like HALIC are said to beat it.
  • Comparisons with AVIF/AV1:
    • Some claim AVIF yields better compression at very low bitrates, but JXL is faster and has more web‑friendly features (e.g., progressive decoding).
    • Others cite benchmarks where JXL decodes ~2.5x slower than AVIF and compresses worse in current implementations; earlier Chrome experiments reportedly saw JXL ~6x slower than AVIF.
    • AV2 is mentioned as an upcoming codec with likely better compression but higher computational cost.
  • One user reports real‑world tests where JPEG XL produced “ugly blocky artifacts” vs AVIF, contradicting optimistic benchmarks.

Lossy vs Lossless & File Extensions

  • JPEG XL’s unified extension for lossy and lossless raises workflow concerns; some want distinct extensions to signal “pristine” vs “degraded” content, analogous to JPG vs PNG.
  • Others argue this is legacy thinking, noting that even “lossless” files can encapsulate previously lossy content and that detailed semantics don’t belong in filenames.
  • Tools and metadata can distinguish modes internally (e.g., jxlinfo indicating “lossy” vs “possibly lossless”).

Adoption, Strategy, and Outlook

  • Several commenters call it “insane” that Google hasn’t already shipped JPEG XL, given its suitability for photography and broadening use (PDF, cameras, medical).
  • There is cynicism about Google’s habit of killing projects, but hope that if JPEG XL gains enough traction, deprecation would become politically impossible.
  • Some attribute the slow HDR/JPEG XL rollout to corporate incentives and “format wars”; others insist it’s more about complexity, competing standards, and security concerns than a deliberate anti‑HDR strategy.
  • Overall sentiment: Chrome’s openness to Rust‑based JPEG XL is seen as a small but important step; many hope this will finally unlock practical, high‑quality HDR/wide‑gamut imaging on the web, but skepticism remains about performance, fragmentation, and Google’s follow‑through.