Google is om: waarom JPEG XL alsnog de standaard voor het web wordt

Tekst

JPEG XL werd in het leven geroepen als de opvolger van JPEG, maar de adoptie bleef achter ten opzichte van WebP en AVIF. Tot eind vorig jaar, toen de PDF Association aankondigde JPEG XL in PDF-bestanden te gaan ondersteunen en Google de wil uitsprak om ondersteuning voor het afbeeldingsformaat in Chrome te integreren, iets wat het bedrijf vorige week ook deed. Tweakers sprak met de Belg Jon Sneyers, een van de grondleggers van JPEG XL: "Dit kan de standaardcodec voor afbeeldingen worden."

Het werk aan het JPEG XL-bestandsformaat begon in januari 2019, nadat het JPEG-comité in 2018 ontwikkelaars opriep om voorstellen in te dienen voor een opvolger van JPEG. Uiteindelijk besloot het comité twee voorstellen te combineren: Googles Pik en het Free Universal Image Format (FUIF) van Sneyers. In maart 2022 werd het formaat officieel gestandaardiseerd door de internationale standaardiseringsorganisatie ISO. De adoptie onder browsers daarna is hobbelig te noemen: Google begon in februari 2022 met de ondersteuning van JPEG XL en zette die in november alweer stop. Ook Mozilla besloot de ontwikkeling van een JPEG XL-implementatie, die al wel aanwezig was in de experimentele Nightly-versie van Firefox, stop te zetten.

Apple kondigde in 2023 plots aan JPEG XL te gaan ondersteunen in Safari. — Apple kondigde in 2023 plots aan
JPEG XL te gaan ondersteunen in Safari.

Met die twee gevoelige klappen leek JPEG XL, in ieder geval als webstandaard, al bijna ten dode opgeschreven. Daarna is de adoptie echter toegenomen. Dat begon in 2023, toen Apple uit het niets aankondigde JPEG XL in Safari te gaan ondersteunen. Mozilla stelde het jaar daarna zijn mening bij en meldde interesse te hebben in een implementatie van JPEG XL op basis van de programmeertaal Rust. Het jaar erna volgden zoals gezegd de aankondigingen van de PDF Association en Google. Laatstgenoemde bedrijf ondersteunt inmiddels de op Rust gebaseerde decoder jxl-rs in het experimentele Chrome Canary, hoewel de functie voorlopig nog standaard uit staat. Daarmee lijkt het bestandsformaat, dat al wordt ondersteund in populaire beeldbewerkingssoftware als GIMP, Krita en Adobe Camera Raw, ook een brede adoptie op het web tegemoet te gaan.

Verrassing van Google

Het nieuws over de wens van Google om JPEG XL in Chrome te integreren eind november kwam voor Sneyers onverwachts, zo geeft hij toe: "Ik ging er wel van uit dat Chrome vroeg of laat van gedachte zou veranderen, maar zo plots had ik niet verwacht. Dat was wel een verrassing, net zoals het stoppen met de ondersteuning eind 2022 een verrassing in negatieve zin was." Sneyers zag wel al de tekenen aan de wand, geeft hij toe: "Apple ondersteunde het al in Safari en daarbuiten ook in zijn besturingssystemen, Microsoft ondersteunt het in Windows, Adobe in Photoshop en Mozilla was ook al van positie veranderd. Chrome was zo'n beetje de enige belangrijke speler die nog niet openlijk had uitgesproken JPEG XL te gaan ondersteunen."

Google noemde bij het stoppen van de ondersteuning van JPEG XL in Chrome een 'gebrek aan interesse van ontwikkelaars' als belangrijkste reden. Sneyers heeft daar zelf zijn twijfels bij: "Ze hebben eigenlijk ook nooit een poging gedaan om de interesse van webontwikkelaars te polsen. Er zijn manieren om dat te doen. Met sommige functies doen ze bijvoorbeeld origin trials. Dat betekent dat op een bepaalde website of app een nieuwe feature automatisch wordt geactiveerd. Zo kan geëxperimenteerd worden met een nieuwe functie zonder dat die onmiddellijk voor iedereen is opengesteld. Met Cloudinary (het bedrijf waar Sneyers werkt, red.) hebben wij een origin trial aangevraagd, zodat wij JPEG XL-beelden konden leveren die dan zouden werken op Chrome, ook al worden deze nog niet wereldwijd ondersteund. Dat soort experimenten heeft eigenlijk nooit plaatsgevonden. Dus ja, het stond wel achter die vlag. Maar er zijn heel weinig mensen die hun instellingen van Chrome gaan aanpassen en op de Android-versie van Chrome kun je zo'n vlag zelfs helemaal niet activeren. Dus er was eigenlijk niet echt een manier om in te schatten hoeveel mensen ervan gebruik zouden willen maken."

"Ik vraag me af op basis waarvan die uitspraak werd gedaan", vervolgt Sneyers. "Het enige wat ik kan bedenken is dat Google zag dat er weinig JPEG XL's binnenkwamen. Maar ja, als het achter een vlag zit die standaard uit staat, is dat logisch. Het aantal gebruikers dat aan die vlaggen sleutelt, is echt beperkt en als webdevelopers of beheerders JPEG XL-bestanden sturen naar een browser die dat niet ondersteunt, dan krijg je een gebrokenafbeeldingssymbooltje. Dat is het laatste wat je wilt hebben."

Ons kent ons

Google heeft zelf ook een afbeeldingscodec, WebP, en is bovendien een van de leden van de Alliance for Open Media, dat de AVIF-codec heeft ontwikkeld. Sneyers kan zich dan ook niet helemaal van de indruk onttrekken dat dat de integratie van JPEG XL in Chrome ook in de weg zat: "Ik heb wel het idee dat een aantal beslissingsmakers in het Chrome-team toevallig ook dezelfde mensen zijn die destijds WebP hebben gemaakt en nu ook actief zijn in AVIF en dat er daardoor een cultuur à la 'not invented here' hangt. Op zich is dat heel ironisch, want JPEG XL heb ik samen met mensen van Google en het JPEG-comité ontwikkeld. Maar dat is een andere tak van Google die niet onder het Chrome-team valt."

JPEG XL Google publiceerde zelf kort na het besluit om de ondersteuning van JPEG XL in Chrome stop te zetten een testrapport waaruit moest blijken dat AVIF superieur is aan JPEG XL. Op het rapport is volgens Sneyers flink wat af te dingen, zo schreef hij al eerder in een blog: "Het voornaamste probleem was dat ze geen enkel onderzoek deden naar de kwaliteit van de beelden door mensen ernaar te laten kijken. Ze gebruikten alleen algoritmes. Dat is meestal niet zo'n ideale manier om te vergelijken, omdat het nogal makkelijk is om die algoritmes voor de gek te houden, vooral als je een encoder maakt die specifiek probeert goede punten te halen op een bepaald algoritme." Google gebruikt in de test onder meer de MS-SSIM-test, die vaak in de YCbCr-kleurruimte wordt toegepast. AVIF werkt met deze kleurruimte en kan daardoor specifiek getuned worden om goed te scoren op deze test. JPEG XL maakt gebruik van de XYB-kleurruimte, die meer aansluit op de menselijke perceptie van kleuren.

Bovendien is de kwaliteit van de gebruikte afbeeldingen erg laag. Google brengt de bestandsgrootte van afbeeldingen uit de Kodak-testset in zijn compressievergelijking terug tot 0,1 tot 3 bits per pixel. "Op dat gebied kan AVIF wel winnen, maar het is een compleet irrelevant gebied, omdat niemand zijn afbeeldingen zo hard wil comprimeren, ook niet op het web", zegt Sneyers. "Er is wel een gebied in de hele lage kwaliteit waar AVIF nuttig kan zijn, maar juist in de hogere kwaliteit valt het meeste te winnen. Een afbeelding van 30KB terugbrengen naar 20KB levert een relatieve winst van 33 procent. Dat geldt ook voor een afbeelding van 300KB tot 200KB comprimeren, maar de absolute winst is daar natuurlijk veel groter."

Waarom JPEG XL?

Het feit dat JPEG XL met minder agressieve compressie betere resultaten oplevert, komt onder meer omdat het een écht afbeeldingscodec is. Zowel WebP als AVIF is in feite een afbeeldingscodec dat is afgeleid van een videocodec, respectievelijk VP8 en AV1. Dergelijke codecs hebben een aantal nadelen voor gebruik met afbeeldingen, legt Sneyers uit: "Video is zoveel beelden per seconde dat de kwaliteit ook wat minder uitmaakt, omdat er dan minder compressieartefacten te zien zijn. Dat zorgt ervoor dat er andere beslissingen worden genomen in het ontwerpproces."

"Wat videocodecs bijvoorbeeld vaak hebben, is agressieve filters die blokkerigheid tegengaan door het beeld heel sterk te smoothen", vervolgt hij. "Dat werkt goed op lage kwaliteit als je wilt vermijden dat er zichtbare blokken zijn, maar op hogere kwaliteit leidt dat er gewoon toe dat de details verloren gaan en dat alles er wat plasticachtig begint uit te zien."

Een van de redenen daarvoor is dat die codecs veel gebruikmaken van directional prediction, ofwel richtinggebaseerde voorspelling. "Dat komt erop neer dat als er een lijn in een afbeelding is, dan is de voorspelling dat die lijn verdergaat in dezelfde richting. Alleen als dat niet zo is, moet er iets gedecodeerd worden, maar als dat wel zo is, wordt er gecomprimeerd", legt Sneyers uit. "Dat zorgt er bijvoorbeeld voor dat scherpe lijnen in een afbeelding behouden blijven als scherpe lijnen, zonder dat zij vaag worden. Maar het nadeel is dat die lijnen soms niet helemaal correct kunnen zijn, omdat er maar in een aantal richtingen kan worden voorspeld. Dat geeft soms een beetje vervorming of smudging. Op hogere kwaliteit is het bovendien redelijk overbodig. Het is eigenlijk vooral nuttig om op lagere kwaliteit iets te kunnen produceren wat presentabel is."

Morsecode

Voor afbeeldingen van hogere kwaliteit is volgens Sneyers sterke entropycoding belangrijker. Dat is een vorm van lossless compressie die korte codes toekent aan elementen die vaker voorkomen en langere codes aan zeldzame elementen, net zoals morsecode kortere codes gebruikt voor veel voorkomende letters dan voor letters als Q en X. Door de entropycoding wordt de totale hoeveelheid data kleiner. Dergelijke codering kan zowel in hardware als in software gedaan worden, maar het is in de praktijk lastig om krachtige entropycoding in hardware te implementeren. Sneyers: "Dat is daarom iets waar videocodecs minder goed in zijn, omdat zij de beperking hebben dat elke videocodec moet kunnen werken in allerlei verschillende soorten hardware, ook smartphones en andere apparaten met een accu. Een video kan urenlang duren. Als dat voortdurend de cpu heel erg belast, is dat een probleem."

Daarom gebruiken fabrikanten een speciale ASIC voor het decoderen van video's. Sneyers: "Het gebruik van hardware heeft veel voordelen op het vlak van energie, maar beperkt hoe complex de codec kan zijn. Als er te veel complexe dingen in zitten, dan worden die chips te groot en te duur. Daar zit altijd een afweging in. En een van de dingen waar bij videocodecs op wordt bespaard, is de verfijning van de entropycoding, omdat het voor video niet zo belangrijk is. Veel van het signaal gaat toch al verloren, dus daarop wordt bespaard om die hardware betaalbaar te houden. Bij afbeeldingen is het niet nodig om aparte hardware te hebben, omdat de compressie van een enkele afbeelding ook prima via de cpu kan."

De verfijning van de entropycoding blijkt onder meer uit het feit dat de JPEG XL-codec bestaande JPEG-bestanden compleet lossless 20 procent kleiner kan maken zonder dat daarbij detail verloren gaat. Het enige verschil met het JPEG-bestandsformaat is de manier van dataopslag; de data zelf is bij een dergelijke hercompressie compleet onaangetast.

Asymmetric numeral systems

Om dat te bereiken, heeft JPEG XL meerdere compressieverbeteringen doorgevoerd ten opzichte van JPEG. Laatstgenoemd formaat maakt vooral gebruik van Huffman-codering, een vorm van prefixcoding die een 'boom' van elementen en hun frequentie genereert en op basis van die boom codes toewijst aan de verschillende elementen. Daarbij krijgen veelvoorkomende elementen codes dichter bij de stam dan elementen die zeldzamer zijn. Daardoor zijn uiteindelijk minder bits nodig om dezelfde hoeveelheid data op te slaan. Huffman-coding is een relatief simpele manier van comprimeren, maar is minder efficiënt omdat het met hele bits werkt. Als een symbool een theoretische informatie-inhoud van minder dan een bit heeft, wordt er daarom toch een hele bit aan het symbool toegekend.

JPEG XL maakt gebruik van asymmetric numeral systems (ans), dat de snelheid van prefixcoding combineert met de compressiedichtheid van rekenkundig coderen. De methode is ontwikkeld door Jarek Duda en wordt inmiddels gebruikt in onder meer Facebooks Zstandard- en Apples LZFSE-compressiealgoritmes. Hierbij wordt data tijdens het encoderen opgeslagen in één enkel getal, de state. Elke keer dat er data wordt toegevoegd, groeit deze state. Hoe waarschijnlijker een symbool is, hoe minder de state groeit. Zodra deze state een bepaalde grens overschrijdt, worden bits uit de state overgedragen naar de bitstream, de data die uiteindelijk als bestand wordt opgeslagen. Een van de grote voordelen van deze methode is dat informatie wél in minder dan een bit opgeslagen kan worden. Een symbool met een waarschijnlijkheid van 90 procent neemt bijvoorbeeld maar ongeveer 0,15 bits in beslag.

JPEG XL implementeert range-ans, waarbij de kansverdeling van symbolen verdeeld wordt over een vast bereik, met een state van 32 bits en kansverdelingen met een precisie van 12 bits, wat voorziet in een bereik van 4096 verschillende datapunten. De precisie van die kansen bepaalt hoe nauwkeurig de optimale codering kan benaderd worden. In eenvoudige Huffman-coding kunnen enkel kansen van de vorm 1/2ⁿ exact worden uitgedrukt, bijvoorbeeld 50 procent voor een symbool met een 1-bitcode, 25 procent voor een symbool met een 2-bitcode en 12,5 procent voor een symbool met een 3-bitcode. In de variant van ans die JPEG XL gebruikt, kunnen alle kansen van de vorm x/4095 worden uitgedrukt, bijvoorbeeld 99,97 procent (4094/4095) voor een zeer vaak voorkomend symbool of 0,024 procent (1/4095) voor een extreem zeldzaam symbool. Bij histogrammen met een hogere precisie wordt de compressie weliswaar beter, maar de workload voor de cpu wordt al snel erg groot. Bij een kansverdeling van 16 bits telt het histogram bijvoorbeeld 2¹⁶=65536 waarden, tegenover de 4096 waarden bij een 12-bitshistogram.

Daarnaast maakt JPEG XL gebruik van contextmodellering. Daarbij worden stukken van de afbeelding met vergelijkbare histogrammen geclusterd, zodat er minder histogrammen nodig zijn. Daardoor wordt de overhead van de histogrammen zelf geminimaliseerd. De encoder ziet welke tabel hij moet gebruiken aan de hand van de contextmap. Het maximum aantal tabellen na de clustering is ingesteld op 255. Daardoor passen alle verwijzingen in een contextmap altijd precies in één byte.

JPEG XL ondersteunt kleurdieptes tot 32 bits, wat normaliter theoretisch onmogelijk zou zijn door de 12-bitshistogrammen. Na de kwantisatie (in het geval van lossy compressie) of na voorspelling (in het geval van lossless compressie) zijn de getallen die uiteindelijk moeten gecodeerd worden vaak dicht bij nul, maar er blijft nog steeds een groot aantal symbolen mogelijk. Om de tabellen compact te houden bij het grote aantal symbolen dat kan ontstaan bij het gebruik van hogere kleurdieptes, maakt JPEG XL ook gebruik van hybride integercodering. Hierbij worden lage getallen (die vaker voorkomen) volledig met ans geëncodeerd, terwijl zeldzamere symbolen deels direct (ongecomprimeerd) naar de bitstream worden geschreven. In dat laatste geval wordt het symbool opgesplitst in de token en onbewerkte bits. De token bevat de exponent, ofwel de positie van de meest significante 1-bit, en ook een configureerbaar aantal meest significante bits en minst significante bits. Deze worden met ans gecomprimeerd en naar de bitstream geschreven. De rest van de bits wordt onbewerkt naar de bitstream overgedragen.

Wachten op afbeeldingen

JPEG XL heeft buiten de betere entropycoding nog een aantal andere voordelen. Zo ondersteunt het bestandsformaat, in tegenstelling tot WebP en AVIF, bijvoorbeeld progressief laden. Daardoor is op webpagina's al snel een lagekwaliteitversie van de afbeelding te zien. De afbeelding wordt beter naarmate meer data wordt geladen. AVIF en WebP ondersteunen dit niet, mede omdat zij hun oorsprong kennen in videocodecs. Daardoor laden de codecs hun afbeelding pas als alle data is geladen, waardoor gebruikers mogelijk lang tegen een leeg vlak aankijken.

Daarnaast heeft JPEG XL ook een checksum ingebouwd. Het encodeerproces wordt altijd gestart op de specifieke waarde 0x00130000. Na het decoderen van de afbeelding moet dit ook de eindtoestand zijn. Als dat niet zo is, kan dat het gevolg zijn van corruptie, bijvoorbeeld als gevolg van fouten bij het versturen van de data.

Verder kan JPEG XL parallel worden geëncodeerd en gedecodeerd. Dat betekent dat een cpu de workload over meerdere rekenkernen kan verdelen om de taak sneller uit te voeren. "Dat is niet volledig lineair, maar het scheelt niet veel", zegt Sneyers. "Als je acht cores hebt, gaat het ongeveer zeven keer zo snel. Dat maakt wel een groot verschil. JPEG en WebP hebben dat voordeel niet. Dus als een JPEG of WebP wilt laden in Photoshop, maakt het niet uit of je twee of twintig cores hebt, het gaat niet sneller."

De toekomst

Op het web zijn er verschillende manieren om een fallback in te programmeren voor als de browser geen JPEG XL ondersteunt. Cloudinary gebruikt daarvoor acceptheaders van de HTTP-aanvraag, waaraan hun servers kunnen zien welk bestandsformaat er kan worden doorgestuurd als antwoord. Daarnaast kunnen webdevelopers ook de HTML-tag <picture> gebruiken, waarin meerdere URL's kunnen staan voor afbeeldingen in verschillende bestandsformaten – met als fallback een <img>-tag met daarin een JPEG of PNG. Sneyers: "Ik denk ook dat er in de voorzienbare toekomst nog altijd JPEG-fallbacks nodig zullen zijn op het web, zelfs als Safari, Firefox en Chrome modernere formaten ondersteunen. Er zal altijd wel iemand nog met een oude versie zitten of een niet-standaard browser gebruiken. Denk aan een Kindle, een smartwatch of een e-mailclient. Er is veel software die ook wel iets van webbrowsingfunctionaliteit heeft zonder een volledige browser te zijn."

Cloudinary werkt onder meer aan de referentie-implementatie libjxl en een Rust-versie genaamd jxl-rs. "Voor toepassingen die moeten encoderen, zoals bijvoorbeeld Photoshop, ontwikkelen we libjxl. Voor applicaties die enkel moeten decoderen en gevoelig zijn voor securityproblemen, zoals browsers, is de Rust-versie. Ik denk ook dat de veiligheid een van de weinige geldige redenen was van Google om te stoppen met de ondersteuning in Chrome. Zeker iets relatief complex, zoals een nieuwe codec, verhoogt natuurlijk de hoeveelheid code in een browser. Daar kunnen bugs in zitten en die kunnen een kwetsbaarheid veroorzaken. De Rust-versie moet op dat vlak betere garanties geven. Die is al bijna klaar. Alles werkt al, maar ze zijn nog een beetje de snelheid aan het optimaliseren. Naast Chrome wil ook Firefox een Rust-versie implementeren en het zou ook kunnen dat Safari daarop overstapt. Die gebruiken momenteel gewoon de C++-libjxl."

JPEG XL Chrome — Links de huidige stabiele versie van Chrome, rechts de nieuwste Chrome Canary-build

Daarmee wordt een belangrijke horde genomen, aangezien JPEG XL volgens Sneyers in veel andere software al wel wordt ondersteund. "Het zit nu bijvoorbeeld ook al in DNG als payloadcodec voor camera's." Dat wil zeggen dat camera's DNG-bestanden lossless kunnen opslaan met de moderne compressietechnologie van JPEG XL, waardoor de afbeeldingen kleiner worden zonder aan kwaliteit in te leveren. "Daarnaast wordt het gebruikt voor medische beeldvorming. Dus het is een codec die eigenlijk niet alleen voor de laatste fase van web delivery kan worden gebruikt, maar ook in de productie in toepassingen die niet noodzakelijk web zijn. En ik denk dat dat het wel het potentieel geeft om een echte vervanger voor JPEG te worden. Dat is ook de reden dat bijvoorbeeld WebP een bepaalde reputatie heeft gekregen; het team daarachter heeft er nooit echt veel aandacht aan besteed om daar algemenere support voor te krijgen. Voor JPEG XL is er ook nog werk om alles vlot te laten werken, maar er is denk ik al meer vooruitgang geboekt in het algemene ecosysteem van afbeeldingen dan WebP in dezelfde tijd heeft geboekt."

"Het optimistische en naar ik hoop ook realistische scenario is dat Chrome en Firefox JPEG XL binnen een jaar volledig ondersteunen", vervolgt Sneyers. "Dan hebben we eigenlijk universele browserondersteuning. Dat betekent dat iedereen het kan gaan gebruiken. Ik denk zoals gezegd wel dat er nog altijd een JPEG-fallback nodig gaat zijn, in ieder geval voor professionele websites. Misschien dat iemand zijn persoonlijke blog of zo het wel oké vindt om alleen nog maar JPEG XL te gebruiken vanaf het moment dat elke grote browser het ondersteunt. Dus ik denk dat het op het web wel een standaardcodec kan worden."

_{Redactie: Imre Himmelbauer, • Eindredactie: Monique van den Boomen}

IT-banen

Reacties (124)

124

Wijzig sortering

grimson 20 januari 2026 09:13

Mooie stap dat Google JPEG XL nu toch weer oppakt in Chrome. Wat veel mensen niet weten: Apple gebruikt JPEG XL inmiddels al in ProRAW, maar alleen voor de preview binnen het DNG‑bestand. De RAW‑data blijft gewoon identiek.

Sinds de iPhone 16 Pro kun je kiezen voor een JPEG XL‑preview — en dat wil je eigenlijk ook, want het scheelt enorm in bestandsgrootte zonder dat je iets inlevert op RAW‑kwaliteit.

Grootteverschillen in de praktijk:

Oude JPEG‑preview: ~20–30 MB extra → totale ProRAW ~70–90 MB
JPEG‑XL lossless: ~8–15 MB extra → totale ProRAW ~50–75 MB
JPEG‑XL lossy: ~3–8 MB extra → totale ProRAW ~45–65 MB

Kleine kanttekening: diensten zoals OneDrive ondersteunen JPEG XL nog niet. Daardoor zie je bij geüploade ProRAW‑foto’s nu een zwart vlak, omdat de viewer de JPEG XL‑preview niet kan decoderen.

Hopelijk verandert dat zodra JPEG XL breder wordt ondersteund, nu Chrome het opnieuw omarmt. Dan kunnen diensten zoals OneDrive deze previews weer gewoon tonen zegmaar, net zoals bij de oude JPEG‑previews.