Google unkills JPEG XL?
Google’s move to revisit support for the JPEG XL image format in Chrome has reignited debate over who effectively controls web standards and how new codecs gain traction. Commenters contrast JPEG XL’s technical strengths—better compression, progressive decoding, archival use cases, and lossless JPEG transcoding—with the already widely adopted AVIF, while noting browser vendors’ growing insistence on memory-safe Rust implementations for complex decoders. The episode is framed both as a technical trade-off (complexity, security surface, ecosystem maturity) and as a power issue, with concern that Chrome’s dominance lets Google’s product strategy shape what formats the web can realistically use.
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.