Google heeft officieel bevestigd dat het de ondersteuning voor JPEG XL (JXL) in de Chrome-browser zal herstellen.
JPEG XL (JXL) is een royaltyvrij beeldformaat van de volgende generatie, ontworpen om de oude JPEG-standaard te vervangen door superieure compressie en moderne mogelijkheden zoals HDR, transparantie en animatie te bieden. Het beslissende voordeel is de mogelijkheid om bestaande JPEG’s verliesvrij te transcoderen naar kleinere bestanden (waardoor de grootte met grofweg 20%) wordt verminderd, zonder enig kwaliteitsverlies.
De stap van Google volgt op jaren van verzet van ontwikkelaars en toenemende druk van rivaliserende ecosysteemspelers zoals Apple en Adobe, die het royaltyvrije raster-grafische bestandsformaat omarmden ondanks Google’s eerdere beweringen van”gebrek aan interesse.”
Chrome-ingenieurs zeggen nu dat ze de functie zullen leveren zodra een geheugenveilige decoder is geïntegreerd, wat een belangrijk keerpunt in de’codec-oorlogen’op het web aangeeft en de weg vrijmaakt voor JXL om de verouderde JPEG-standaard te vervangen.
A Op roest gebaseerd pad naar verlossing
Rick Byers, hoofd van het Chrome Audit-team, doorbrak een impasse van drie jaar en maakte officieel een einde aan de bevriezing van de JPEG XL-integratie in de Blink-dev-mailing lijst draad. Goedkeuring hangt af van twee specifieke voorwaarden: de aanwezigheid van ‘positieve signalen’ uit het bredere ecosysteem en strikte naleving van de beveiligingsregels.
Google wijst expliciet de vorige C++-implementatie af ten gunste van een ‘performante en geheugenveilige’ decoder, waarschijnlijk geschreven in Rust. Byers merkte op dat “we gezien deze positieve signalen bijdragen zouden verwelkomen om een performante en geheugenveilige JPEG XL-decoder in Chromium te integreren”, waarbij de grondgedachte rond externe adoptie in plaats van interne statistieken wordt geformuleerd.
Langdurig onderhoud blijft de laatste hindernis voordat de functie gebruikers bereikt. Google heeft een speciaal team nodig dat eigenaar is van de decodercode voordat deze naar het Stabiele kanaal wordt verzonden.
Byers verduidelijkte de tijdlijn en zei:”Om deze standaard in Chromium in te schakelen, hebben we een verbintenis tot langdurig onderhoud nodig. Als aan deze en onze gebruikelijke lanceringscriteria wordt voldaan, zullen we deze in Chrome verzenden.”
Ontwikkelaar Helmut Januschka heeft een gedetailleerde statusupdate gegeven voor de Chromium-bugtracker, waarmee wordt bevestigd dat de nieuwe code is gebaseerd op de nieuwste libjxl referentie-implementatie. In de update van de ontwikkelaar staat:
“Huidige status: – Functie voltooid – gebruikte de vorige JXL-implementatie als blauwdruk en bijgewerkt naar de meest recente referentie-implementatie – Animatie-ondersteuning toegevoegd (Chromium zou de eerste browser zijn die JXL-animaties ondersteunt) – bots zijn groen”
Januschka publiceerde ook de volgende demo met ondersteuning voor JPEG XL-animatie in een Chromium-build.
[ingesloten inhoud]
Gemarkeerd als”functie voltooid”, de nieuwe implementatie zou naar verluidt de meeste geautomatiseerde bottests doorstaan. Ondersteuning voor animaties is een cruciale technische differentiator bij deze tweede poging en overtreft mogelijk de oorspronkelijke implementatie van Safari.
Januschka merkte op dat”Chromium de eerste browser zou zijn die JXL-animaties ondersteunt”, hoewel deze bewering wordt betwist door kleinere projecten zoals de Thorium-browser, die sindsdien JXL-animaties ondersteunt medio 2024.
De context van de ‘Codec-oorlog’ (2022-2025)
Google verwijderde oorspronkelijk de JXL-ondersteuning in Chrome 110 in december 2022, waardoor het webmomentum van het formaat effectief werd gedood. Jim Bankoski verklaarde destijds dat”we hebben besloten het JPEG XL-experiment van Chrome stop te zetten en de code te verwijderen die aan het experiment is gekoppeld”, daarbij verwijzend naar onvoldoende voordelen ten opzichte van Google’s eigen AVIF-formaat.
Critici en experts op het gebied van beeldcompressie beschuldigden Google ervan gebrekkige statistieken te gebruiken door niet-geoptimaliseerde encoders te testen ten gunste van AVIF. De verwijdering leidde tot een van de meest controversiële discussies in de geschiedenis van Chromium en trok meer dan 1.000 sterren en honderden reacties van ontwikkelaars.
Tijdens de pauze heeft Google op agressieve wijze AVIF, afgeleid van de AV1-videocodec, gepusht als de enige opvolger van JPEG en WebP. Ingenieurs hebben de’feature flag’volledig uit de browser verwijderd, waardoor zelfs experimenteel gebruik bijna drie jaar lang onmogelijk is geworden.
Om een verhaal van een’format-oorlog’te consolideren, zette deze periode Google’s op video gebaseerde AVIF tegenover het beeld-eerst-ontwerp van JPEG XL.
Ecosysteemdruk en technische realiteit
Apple doorbrak de impasse in 2023 door native JXL-ondersteuning toe te voegen aan Safari 17. Door een’split web’-scenario te creëren, betekende deze adoptie dat hifi-afbeeldingen op iPhones werden geladen, maar mislukten op Android en Chrome.
Adobe integreerde JXL in Lightroom en Photoshop, terwijl Microsoft de JPEG XL Image Extension aan Windows 11 toevoegde, waardoor deze als professionele standaard werd gevalideerd, ongeacht de browser ondersteuning.
Mozilla’s standpunt verschoof van “neutraal” naar “positief”, op voorwaarde dat de veiligheidsproblemen werden aangepakt via een op Rust gebaseerde decoder. Technisch gezien biedt JXL een uniek voordeel: verliesloze transcodering van bestaande JPEG’s om de grootte met ongeveer 20% te verkleinen zonder generatieverlies.
AVIF mist deze transcoderingsmogelijkheid, waardoor hercodering met verlies nodig is, waardoor de kwaliteit van archiefinhoud afneemt. In lijn met de bredere trend in de sector om kwetsbaarheden in de geheugenveiligheid bij het parseren van complexe mediabestanden te elimineren, zorgt de verschuiving naar een op Rust gebaseerde decoder voor stabiliteit op de lange termijn.
