JPEG XL and the Pareto Front
JPEG XL is presented as a highly efficient next‑generation image codec that outperforms JPEG, WebP, AVIF and PNG on both compression ratio and speed, with features like lossless JPEG recompression, progressive decoding, HDR support and strong lossless performance. Commenters praise recent encoder and memory‑usage improvements, but note that real‑world impact is constrained by inconsistent browser support, patent anxieties and the dominance of Chromium in setting de facto web standards. There is broad agreement that JPEG XL is technically impressive and attractive for photography, archives and professional workflows, yet its future on the web hinges on adoption decisions by major vendors rather than on technical merit alone.
Browser support and “gatekeeping”
- Many comments focus on Chrome removing JPEG XL behind a flag and refusing to ship it, despite community requests.
- Some argue Chrome offshoots (Edge, Brave, Opera) could differentiate by enabling JXL but generally don’t, suggesting real divergence from Chromium is expensive.
- Safari already ships JPEG XL; Firefox is described as “neutral” and resource‑constrained, with work stalled at nightly.
- Concerns that Chromium’s dominance makes it a de facto gatekeeper; others reply that market share isn’t a mandate to implement every format.
Patents, legal risk, and security
- Debate about whether an ANS‑related Microsoft patent scared browser vendors; others counter it doesn’t apply to JXL and that this is speculative.
- Apple and Adobe shipping JXL is cited as evidence the patent risk is manageable.
- Clarification that Cloudinary and Google offer royalty‑free licenses for their JXL‑related patents; remaining risk is generic to any recent format.
- Separate concern: libjxl is C++, already had memory‑safety bugs; some argue new, complex codecs that will be ubiquitous should be written in safe languages.
A Rust decoder exists and has been validated.
Compression quality and speed
- Lossless: JXL and WebP lossless are strong; AVIF lossless is widely panned and often worse than PNG. WebP lossless is praised but limited to 8‑bit and smaller dimensions.
- Lossy: at typical web qualities, JXL often beats JPEG and WebP; AVIF may be better at low bitrates. Some find low‑quality JPEG more detailed but note it uses more bits.
- JXL encoder improvements in v0.10 significantly cut memory use and raise speed, especially for multi‑threaded lossless.
- Discussion over how to draw the Pareto frontier and whether some points were mis‑classified.
Decode performance and UX
- Many see encode speed as economically critical for services (mass encoding); decode speed is “good enough” on modern devices.
- Progressive/streaming decoding is viewed as more impactful for UX than raw decode throughput; JXL supports strong progressive decoding, unlike AVIF.
Features and ecosystem
- A major selling point: JXL can recompress existing JPEGs losslessly and reconstruct bit‑identical JPEGs, enabling storage savings without quality loss.
- JPEG‑compatible encoder “jpegli” delivers impressive gains while staying within JPEG, reinforcing “old JPEG still has life.”
- Tooling: desire for better JXL integration (e.g., libvips, ImageMagick versions), and mention of SIMD library Highway spun out of JXL work.
- Some skepticism remains that, despite technical merits, JXL adoption is slow and real‑world use remains limited compared to the hype.