Achtergrond - Google is om: waarom JPEG XL alsnog de standaard voor het web wordt
In dit artikel:
JPEG XL, ontwikkeld vanaf januari 2019 als opvolger van het klassieke JPEG (een samengaan van Googles Pik en Jon Sneyers’ FUIF), heeft na een hobbelige start eindelijk momentum gekregen: in maart 2022 werd het door ISO gestandaardiseerd, er was aanvankelijke browserondersteuning die later door Google en Mozilla werd teruggedraaid, maar sinds 2023/2024 kantelde het beeld — Apple voegde ondersteuning in Safari toe, Mozilla toonde later weer interesse voor een implementatie in Rust, de PDF Association kondigde eind 2024 ondersteuning aan en Google heeft recent een op Rust gebaseerde decoder (jxl-rs) in Chrome Canary opgenomen (vooralsnog uitgeschakeld achter een vlag). Jon Sneyers, medegrondlegger van JPEG XL en werkzaam bij Cloudinary, noemt de ontwikkeling veelbelovend: "Dit kan de standaardcodec voor afbeeldingen worden."
Waarom JPEG XL opvalt
- Echte afbeeldingscodec: JPEG XL is vanaf de grond ontworpen voor stilstaande beelden, in tegenstelling tot WebP en AVIF die afgeleiden zijn van videocodecs (VP8 en AV1). Dat verschil leidt ertoe dat JPEG XL vooral bij hogere kwaliteit betere details behoudt en minder ongerechtvaardigd vergladende filters toepast die videocodecs vaak gebruiken om blokkering te maskeren.
- Betere entropycodering: JPEG XL gebruikt moderne methoden (asymmetric numeral systems, vooral range-ans) waarmee informatie efficiënter dan traditionele Huffman-codering wordt vastgelegd. In mensvriendelijke termen: vaak voorkomende beeldelementen krijgen heel korte codes, zeldzame elementen langere, zodat de totale bitsom omlaag gaat — dit biedt vooral bij hogere kwaliteitsinstellingen grote winst.
- Praktische features: progressive loading (eerste lage-res weergave waarna kwaliteit toeneemt), ingebouwde checksum voor integriteitscontrole, parallelle encode/decode-mogelijkheden en ondersteuning voor hoge kleurdieptes. Ook kan JPEG XL bestaande JPEG-bestanden lossless hercomprimeren tot circa 20% kleinere bestanden zonder kwaliteitsverlies.
Technische verschillen en kritiek op eerdere vergelijkingen
Sneyers verwijst naar eerdere tests van Google die AVIF superieur verklaarden, maar bekritiseert vooral het testontwerp: de vergelijking gebruikte voornamelijk algoritmische kwaliteitsmetingen (zoals MS-SSIM in YCbCr), lage-res beeldsets en compressieniveaus die in de praktijk weinig toegepast worden. Omdat JPEG XL de XYB-kleurruimte gebruikt en op perceptie is afgestemd, schiet het minder goed uit de bus in zulke synthetische tests. Ook wijst Sneyers op organisatorische oorzaken voor eerdere terugtrekkingen: gebrek aan origin trials en mogelijk een cultuur binnen het Chrome-team die de voorkeur geeft aan intern ontwikkelde codecs (WebP/AVIF).
Implementatie, veiligheid en ecosysteem
- Implementaties: libjxl (C/C++) is de referentie-encoder voor toepassingen die veel encoderen (bv. Photoshop-achtige workflows); jxl-rs (Rust) richt zich op decoders die in browsers draaien, met betere geheugen- en veiligheidsgaranties. Google gebruikte die Rust-versie in Chrome Canary.
- Reële adoptie: naast browsers is JPEG XL al opgenomen in populaire beeldbewerkingsprogramma’s (GIMP, Krita, Adobe Camera Raw), DNG-werkflows voor camera’s en medische beeldvorming — dus het formaat is niet alleen een web-experiment maar wordt ook in productieomgevingen gebruikt.
- Webdeploy: standaarden en technieken voor fallback bestaan al (Accept-headers,
Waarom dit relevant is
Beeldbestanden vormen vaak de grootste laadtijd en bandbreedtepost op websites en in productieomgevingen. Een codec die bij realistische kwaliteitsinstellingen substantieel minder data gebruikt terwijl visuele kwaliteit behouden blijft, kan laadtijden, opslag en netwerkverkeer besparen zonder zichtbare kwaliteitsverlies. JPEG XL richt zich expliciet op die praktijkgebieden (hoge kwaliteit en productiegebruik), niet alleen op extreem agressieve compressie.
Toekomstperspectief
Sneyers is optimistisch dat volledige browserondersteuning binnen ongeveer een jaar mogelijk is als Chrome en Firefox de Rust-implementaties volledig integreren. Als dat gebeurt, zou JPEG XL wijdverspreid inzetbaar worden voor webafbeeldingen, hoewel professionele websites waarschijnlijk nog enige tijd JPEG-fallbacks blijven aanbieden. De combinatie van technische voordelen, al bestaande ondersteuning in belangrijke software en recente politieke besluiten (PDF Association, Google) geeft JPEG XL volgens Sneyers een reële kans om een brede vervanger van JPEG te worden.