Het pleidooi tegen JPEG XL

Een onderzoek naar de plek van JPEG XL als afbeeldingscodec voor het web.

Waarom?

JPEG XL is een technisch indrukwekkende afbeeldingscodec; het is een definitieve upgrade ten opzichte van JPEG, veelzijdiger dan WebP en goed uitgerust voor gebruiksscenario's buiten het web. Desondanks werd het in 2023 bekendelijk afgewezen door Chrome. Omdat dit gebeurde bij een vrij van royalty's zijnde, flexibele en compressie-efficiënte codec van het JPEG-comité die aandacht kreeg van grote bedrijven, werd deze beslissing door velen niet goed ontvangen.

Onlangs is een JPEG XL-decoder in Rust in zekere mate terechtgekomen in Firefox en Chrome. De belangrijkste belanghebbenden van het web zouden daarom hun koers kunnen ombuigen wat betreft JPEG XL, aangezien de nieuwe decoder het web kan beschermen tegen een herhaling van de WebP-kwetsbaarheid uit 2023. Is dit alles wat nodig was om JPEG XL voor het web te rechtvaardigen?

Historisch gezien ben ik een groot voorstander geweest van JPEG XL voor alle gebruiksscenario's. Ik steunde JPEG XL voor Interop 2024 en heb persoonlijk meerdere keren contact gehad met Jon Sneyers en Jyrki Alakuijala (twee van de primaire auteurs van het formaat). Ik ben consistent onder de indruk van hun publieke optreden, hun kalmte, technische bekwaamheid en passie voor het vakgebied.

Dit artikel is niet bedoeld om de auteurs van het formaat of hun werk in diskrediet te brengen, noch om een politieke voorkeur te uiten met betrekking tot de symboliek van de codec binnen vrije software. De geest van dit bericht is educatief; ik wil een empirische blik werpen op de huidige staat van beeldcompressie en het webplatform in 2026. Een deel van de inspiratie is geput uit RISC-V: They Should Have Known Better door Dmitry Grinberg.

Het web

Ik houd me bezig met beeldcompressie, oorspronkelijk vanuit videocompressie. Tijdens het werken aan een AV1-encoder hebben Julio Barba en ik aanzienlijke vooruitgang geboekt met AVIF, en ik heb in dat proces veel geleerd. Toen ik besloot mijn eigen encoder te bouwen, moest ik goed nadenken over welke formaten het hoogste potentieel hadden, effectief geoptimaliseerd konden worden en de meeste huidige en potentiële bruikbaarheid hadden. Ik besloot niet met JPEG XL te werken.

Kijkend naar het volume zijn er zeer weinig gebruiksscenario's op het web die niet worden bediend door veelzijdige lossy compressie (compressie met kwaliteitsverlies). De gemiddelde webconsument heeft geen lossless compressie nodig; zij hebben slechts een lossy codec nodig die veelzijdig genoeg is om vreselijke artefacten te voorkomen (bijv. JPEG bij niet-fotografische inhoud).

Dit sluit het voordeel van lossless compressie van JPEG XL uit, dat in de praktijk sowieso slechts ongeveer 11,9% kleiner is dan lossless WebP – en dat op een onrealistische testdataset voor het web (foto's van 157 MP, illustraties van 10 MP en boeken van 27 MP). Het kan niet rendabel zijn om een nieuwe afbeeldingscodec in browsers te introduceren om 12% te besparen op een klein volume aan beeldinhoud met gebruiksscenario's die inherent minder gevoelig zijn voor bandbreedtebeperkingen. Ik zeg dit omdat JPEG XL niet competitief is voor lossy compressie, waardoor lossless het enige echte voordeel zou zijn.

Efficiëntie van compressie met kwaliteitsverlies

Een van de oorspronkelijke argumenten voor JPEG XL was dat de referentie-encoder meer perceptueel was geoptimaliseerd dan concurrerende encoders. Tegenwoordig zijn andere encoders sterker, zowel wat betreft snelheid als getrouwheid per bit.

De AV1-referentie-encoder heeft gespecialiseerde perceptuele tuning gekregen op basis van gecontroleerde subjectieve menselijke tests om de efficiëntie te versterken, terwijl er een tuning-modus behouden is die is geoptimaliseerd voor perceptuele metrieken. SVT-AV1 heeft vergelijkbare tuning-modi. Er is geen overtuigend argument dat moderne encoders niet zijn afgestemd op het menselijk oog.

Metrieken zijn niet perfect, maar ze schetsen een ontmoedigend beeld voor JPEG XL: CVVDP, MS-SSIM en SSIMULACRA2. aperture-alpha is de komende encoder van Halide Compression (codenaam Aperture). Ik heb deze toegevoegd om te laten zien hoeveel inhaalslag libjxl moet maken om aan het front te kunnen concurreren.

Sommige analyses beweren dat JPEG XL in metrieken ondermaats presteert ten opzichte van zijn perceptuele kracht, maar ik zie onvoldoende bewijs dat dit in zulke grote mate gebeurt dat grafieken zoals die ik heb gedeeld geheim volledig omgedraaid zouden kunnen worden. CVVDP en SSIMULACRA2 zijn zeer sterke perceptuele metrieken en vertellen ons zeker iets wanneer de verschillen zo groot zijn. Voor AVIF is de perceptueel geoptimaliseerde tune (tune IQ) van libaom slechts een paar punten lager dan de op perceptuele metrieken geoptimaliseerde tune (tune SSIMULACRA2). Bovendien heeft de JPEG XL-referentie-encoder historisch geleden onder perceptuele problemen die grotendeels onopgelost blijven.

Er bestaat niet zoiets als een codec-benchmark, alleen een encoder-benchmark; in theorie is het plafond voor JPEG XL als formaat hoger dan wat libjxl momenteel haalt. Maar hoe moeilijk zou het zijn om het gat te dichten? Als compressie-ingenieur geloof ik dat JPEG XL hier in het nadeel is. Enkele redenen hiervoor:

  • Ontbreken van richtingsgebaseerde voorspellingsmodi (directional prediction modes): Gecomprimeerde beelden worden verdeeld in VarDCT-blokken (van 2x2 tot 256x256) en omgezet in frequentierepresentaties van hun pixels. Andere blokgebaseerde beeldcodecs, zoals WebP, stellen je in staat om de pixels van een blok te voorspellen met behulp van omringende gegevens, deze voorspelling af te trekken van de werkelijke pixels en vervolgens de frequentietransformatie uit te voeren. Richtingsgebaseerde voorspellingsmodi kunnen leiden tot vervaging als je encoder niet perceptueel is geoptimaliseerd, maar sterke mode-decision pipelines kunnen de juiste modus kiezen en veel bits besparen. Zo is de randbehouding sterker in codecs met richtingsvoorspelling, terwijl JXL hier zwakker is.
  • De voorgestelde oplossing voor het gat in randbehouding zijn splines, die echter veel moeilijker te gebruiken zijn. Het lastige deel zit aan de kant van de encoder: je hebt een efficiënt algoritme nodig om te bepalen welke pixels überhaupt als een spline kunnen worden weergegeven, om vervolgens elke kandidaat via RDO te leiden om te beslissen of het coderen de moeite waard is. Er is geen bestaande Proof of Concept (PoC) voor het gebruik van splines voor randbehouding, en ik heb geen reden om te geloven dat ze beter zouden zijn dan richtingsvoorspelling.
  • Geen deblocking loop filtering (DLF): JPEG XL heeft geen deblocking-filter of enige vorm van DLF. Er zijn twee in-loop tools die soms als gedeeltelijke equivalenten worden aangeboden: gaborish (hetgeen JXL het dichtst benadert van de loop restoration filtering van AV1) en EPF (edge-preserving filter, waarvan de dichtstbijzijnde analoog de CDEF van AV1 is). Geen van beide is een deblocking-filter, en samen kunnen ze een correcte DLF niet volledig vervangen. DLF kan beelden gladstrijken, maar een slimme encoder zal dit alleen gebruiken om mosquito noise te voorkomen, waar JPEG XL nog steeds last van heeft.
  • De XYB-kleurruimte: De perceptuele "XYB"-kleurruimte van JPEG XL is gebaseerd op veel intuïtie en vertaalt zich niet altijd naar winst in andere formaten (zoals JPEG), zelfs niet wanneer metrieken zoals SSIMULACRA2 in exact dezelfde kleurruimte werken. De geclaimde efficiëntiebesparingen door het gebruik van XYB zijn bovendien niet zo groot als oorspronkelijk geadverteerd, omdat libjxl momenteel vertrouwt op agressieve kwantisering van het B-kanaal. Dit heeft geleid tot ondermaatse kleurbehouding, wat nieuwe JXL-encoder-ontwikkelaars expliciet ongedaan moeten maken.
  • Niet-fotografische beelden: JXL presteert slecht bij niet-fotografische beelden. De voorgestelde oplossing is het gebruik van patches, maar deze zijn moeilijker te gebruiken dan de Intra Block Copy van AV1. Om een vergelijkbaar bereik aan expressiviteit als IntraBC te krijgen, moet de encoder omgaan met aanvullende concepten zoals lagen en blending, wat niet goedkoop is om op bitstream-niveau te representeren.
  • Residuele codering (Residual coding): Dit is onhandig opgezet. Bij AV1 voorspel je een blok, trek je de voorspelling af van de bron, en de transformatiecoëfficiënten representeren natuurlijk het residu. Bij de constructie van JXL decodeer je een residu-frame en meng je vervolgens een referentie-patch, waardoor je een feitelijk frame of laag nodig hebt waarvan de gedecodeerde pixels het residu representeren. Dit zou waarschijnlijk een Modular frame zijn, wat interessant is omdat Modular niet beperkt is tot conventionele ongetekende beeldwaarden, in tegenstelling tot het uiteindelijke gerenderde beeld.
  • Een IntraBC-blok kost in essentie een bewegingsvector plus residu-coëfficiënten, terwijl een JXL-constructie potentieel een referentiekader, een frameheader, een uitsnede (crop), blend-informatie, een vermelding in het patch-woordenboek, patch-coördinaten en een residu-frame kost. Die overhead kan de besparingen overschaduwen, tenzij het herhaalde gebied vrij groot is of vaak wordt hergebruikt. Patches moeten in libjxl expliciet worden ingeschakeld onder effort 7, omdat ze momenteel prestatieproblemen hebben.

Voor niet-fotografische beelden houdt het argument "ze zouden vectorafbeeldingen moeten zijn" geen stand, omdat veel beelden vectorafbeeldingen zouden kunnen zijn maar dat niet zijn, en ze niet perfect gevectoriseerd kunnen worden. "De wereld zou anders moeten zijn" is geen rechtvaardigbaar verdedigingsmiddel tegen het optimaliseren voor de manier waarop de wereld daadwerkelijk is.

Het is verleidelijk om te denken dat deze punten betekenen dat het plafond hoger ligt dan libjxl ons laat bereiken en dat we beter kunnen doen, maar ik ben er niet van overtuigd dat het goed geoptimaliseerde AVIF-encoders snel kan overtreffen, gezien de minder intuïtieve (en potentieel zwakkere) coderingsinstrumenten.

Decodeertijd

JPEG XL heeft een indrukwekkend flexibele specificatie. Naast zijn coderingsinstrumenten ondersteunt het tot 4096 kanalen, willekeurige kleurdiepte, progressieve decodering, JPEG-recompressie en meer. Veel van deze functies zijn niet breed bruikbaar op het web; je hebt 4 kanalen nodig (RGB/YUV + alpha), een redelijke kleurdiepte om HDR te ondersteunen (10-bit is voldoende) en de mogelijkheid om snel te laden.

Progressieve weergave (die AVIF ook ondersteunt) decodeert een weergave van lage getrouwheid voordat het volledige beeld arriveert. AVIF ondersteunde dit een tijdje niet, en ik geloof dat het in die tijd zwaar werd oververkocht. Nu libavif dit heeft geïmplementeerd (het was altijd mogelijk), lijkt de discussie voorbij. De resultaten spreken voor zich: op de JPEG-XL infosites laat AVIF een bruikbaar beeld veel eerder zien dan JXL, bij slechts ~2-3% van de grootte van het volledige beeld. Gecombineerd met het feit dat de AVIF-bestanden over het algemeen kleiner zijn, is dit een gemakkelijke overwinning.

JPEG-recompressie is de mogelijkheid om JPEGs verliesvrij te hercoderen als JXL-afbeeldingen terwijl er bits worden bespaard; het vaak genoemde getal is 20% besparing. De gebruiker betaalt dit echter in decodeertijd, aangezien gerecomprimeerde JPEGs ongeveer 33% langer nodig hebben om te decoderen. Moderne consumentenapparaten zijn krachtig, maar het argument dat de besparingen "gratis" zijn, is misleidend.

Wat dat betreft is de decodeertijd niet competitief met de besten. In het publieke debat wordt AVIF als traag beschouwd om te decoderen; wat maakt JXL dan? In tests waarbij beelden van dezelfde bron en grootte werden gebruikt, bleek WebP (ondanks dat het meer dan 90kb groter was) meer dan 10x sneller te decoderen dan jxl-rs met wpd.

Vanwege de expressiviteit van de codec is het mogelijk om afbeeldingen te maken die extreem lang duren om te decoderen. Een voorbeeld hiervan is een afbeelding die priemgetallen tot 33.599 berekent en 17,43 seconden aan gebruikers-tijd kost om te decoderen op een M5 Pro met de Rust-decoder. Aangezien dit de decoder is die zijn weg vindt naar Chrome en Firefox, wordt het triviaal eenvoudig om low-end apparaten te "JXL-bomben". Je kunt al een paar dozijn van deze beelden op een webpagina plaatsen om Apple-apparaten te vertragen, aangezien zij JPEG XL native ondersteunen in Safari.

Conclusie en mening

Ik geloof dat webcodecs doelgericht, efficiënt en nauw afgebakend moeten zijn naar de behoeften van het web. Ik denk dat WebP iets te nauw was afgebakend, maar het idee was goed. De container van AVIF zou beter kunnen en de AV1-specificatie zou specifieker kunnen zijn over de behandeling van bepaalde eigenschappen van afbeeldingen (bijv. normatieve 4:2:0 upsampling), maar AVIF was altijd een gegarandeerde toevoeging aan het web dankzij AV1 en profiteert van een zeer volwassen ecosysteem.

Hebben we JPEG XL dan nodig? Het is absoluut niet nauw afgebakend; het is ontworpen om alles voor iedereen te zijn. Ik denk dat veel andere gebruiksscenario's dit nodig hebben, maar het web moet bandbreedte besparen, snel decoderen en "foot-guns" (gevaarlijke implementaties) voorkomen; ik zie niet hoe JPEG XL zelfs maar net zo goed past als WebP. Bovendien ontstaat er een extra compatibiliteitsprobleem voor iedereen die gewoon een afbeelding van het internet wil downloaden en ergens anders wil gebruiken – het was al moeilijk genoeg om wijdverbreide adoptie van WebP te krijgen, en ik denk niet dat het de pijn waard is om dezelfde berg te beklimmen voor zowel AVIF als JPEG XL, zeker wanneer JPEG XL niets lijkt toe te voegen aan het webplatform.

3½ jaar geleden zei ik:

"Ik wil een web waar zowel AVIF als JPEG XL kunnen bestaan, en ontwikkelaars beslissen welk formaat ze gebruiken op basis van de verdiensten. [...] Naar mijn mening hebben JPEG XL en AVIF fundamenteel verschillende sterktes die hen geschikt maken voor verschillende gebruiksscenario's."

In die tijd was JPEG XL een veel sterkere kandidaat voor lossy beeldcompressie van medium tot hoge getrouwheid. AVIF domineert nu het gehele getrouwheidsbereik, waardoor het enige echte voordeel van JPEG XL is verdwenen.

JPEG XL is voortgekomen uit Cloudinary en Google, maar ik denk dat de codec op een manier wordt besproken die dit niet duidelijk maakt. Ook is het vermeldenswaardig dat zowel JPEG XL als AVIF vrij zijn van royalty's. Vanwege de politiek rond de dominantie van Google op de browsermarkt, het feit dat AV1 van Google komt en de controverse rond Google's WebP, is het mijn mening dat het grootste deel van het pleidooi voor JPEG XL voortkomt uit de wens voor meer keuze voor ontwikkelaars, in plaats van de wens voor een technologisch superieure beeldcodec. Ik begrijp dit, en ik denk dat JPEG XL buiten het web kan floreren op plekken waar AVIF dat nooit zou kunnen.

JPEG XL is niet nutteloos; het is oprecht overtuigende technologie voor gebruiksscenario's buiten het web. Ik ben er alleen persoonlijk niet van overtuigd dat we het op korte termijn in browsers nodig hebben.