Google unkills JPEG XL?

Original Article ↗ Hacker News Discussion ↗

Ebook formats and reading experience

  • Thread opens with a tangent: if JPEG XL lands in ebook stacks, it will take years.
  • Strong split between people preferring PDF (great on tablets, embedded annotations, stable layout) vs EPUB (reflowable, better on phones and e‑ink, customizable text, dark mode).
  • Several note PDFs are painful on phones due to fixed layout and margins; others say phones are fine for long‑form reading and help them read more.
  • EPUB’s lack of a standard in‑file annotation model is seen as a weakness; each reader keeps its own proprietary notes.

Google’s role in web standards

  • Some argue a Chrome monopoly means Google should lose decision power in standards, and be legally forced (e.g., via FTC) to follow other browser vendors.
  • Pushback: other implementers (Apple, Mozilla, Microsoft) are also in WHATWG; standards must be driven by implementers, not bureaucrats or end‑users.
  • Disagreement over whether “other parties” really diverge from Google; JPEG XL and XSLT deprecations are cited where Mozilla and Google aligned.
  • Others say Firefox can’t gain market share just by adding niche formats like JPEG XL or XSLT; most users don’t choose browsers based on codecs.

JPEG XL vs AVIF/WebP and adoption

  • Some celebrate Chrome’s apparent “unkilling,” others note AVIF already has broad support and momentum and will continue evolving (AV2).
  • Debate over compression quality: some say JXL clearly beats AVIF in realistic quality settings with faster encode/decode and better re‑save behavior; others claim that at equal file sizes AVIF looks better for typical web resolutions.
  • WebP is viewed by some as clumsy or compatibility‑annoying, by others as excellent, especially in lossless mode for comics/PNG‑style content.

Security, implementations, and Rust

  • Central concern: JPEG XL’s existing C++ reference decoder adds attack surface in browsers and email clients.
  • Both Chrome and Firefox are said to want a memory‑safe implementation (Rust, specifically “safe” Rust) before shipping.
  • Confusion about code size (100M vs ~100K lines); clarified that the decoder core is on the order of tens of thousands of lines, with much extra in tests/tools.
  • Some criticize the libjxl codebase as unstable, crash‑prone and memory‑hungry for extreme resolutions; others report successfully compressing petabytes of imagery with it.

Extreme resolutions, tiling, and pyramidal images

  • Discussion around JPEG XL’s gigantic theoretical max image size and whether this introduces DoS vectors.
  • Participants explain tiling, pyramids/mipmaps, progressive decoding, and how JXL supports multiresolution, tiled decoding and mandatory tiling above certain sizes.

Ecosystem and non‑web uses

  • PDF Association has added JPEG XL support; people speculate this may have pushed Chrome to reconsider so its PDF viewer can handle valid PDFs.
  • JPEG XL’s lossless transcoding of existing JPEGs (with ~20% savings while remaining reversible) is highlighted; large DICOM stores on GCP are adopting this to cut storage costs.
  • Apple’s use of JPEG XL in ProRAW/“RAW”‑like files is mentioned as a major ecosystem boost, especially for prosumer photography.
  • Many note that even if browsers add JPEG XL, site‑side adoption (GitHub, GitLab, Wikipedia, etc.) lags badly, as already seen with AVIF.