Comment Re:JPEG 2000 (Score 0) 29
Wake me when they add JPEG 2000 support.
https://www.adobe.com/creativecloud/file-types/image/comparison/jpeg-vs-jpeg-2000.html
Claude says: JPEG XL beats JPEG 2000 on essentially every practical axis:
**Compression efficiency** — JXL achieves better quality at smaller file sizes than JP2, both for lossy and lossless. At equivalent visual quality, JXL files are typically 20–60% smaller.
**Lossless JPEG recompression** — JXL can losslessly re-encode existing JPEG files ~20% smaller, then decode back to the *identical* original JPEG bitstream. JP2 has no equivalent capability.
**Speed** — JP2 (especially with its wavelet codec) is notoriously slow to encode and decode. JXL encodes faster and decodes fast enough for practical real-time use, with a well-optimized reference decoder (`libjxl`).
**Progressive decoding** — Both support it, but JXL's progressive rendering is more sophisticated, allowing a useful low-resolution preview very early in the stream, which matters for web delivery.
**Feature set** — JXL supports HDR, wide gamut, alpha, animation, layers, and up to 32-bit/channel depth natively. JP2 has some of this but with far less ecosystem support.
**Royalties and patents** — JP2 has a murky patent history that scared off adoption. JXL is royalty-free with a clean IP situation.
**Browser/ecosystem support** — JP2 was never adopted by Chrome or Firefox (only Safari). JXL has broad support in Safari, Firefox, and Chrome (behind a flag, then natively). The web ecosystem simply rejected JP2.
**Encoder/decoder ecosystem** — `libjxl` is actively maintained. JP2 tooling is fragmented (OpenJPEG, Kakadu, etc.) and often requires proprietary libs for best quality.
The short version: JP2 was designed for print/archival workflows (DICOM, digital cinema via JPEG 2000's cinema profile) and never translated well to the web. JXL was designed from the start to replace JPEG on the web while also serving archival use cases — and it does both better.