Pdf's krijgen ondersteuning voor JPEG XL, dat verdween uit Chrome

De PDF Association heeft aangekondigd dat pdf's ondersteuning krijgen voor JPEG XL, een bestandsformaat voor onder meer hdr-afbeeldingen. Google verwijderde JPEG XL een paar jaar geleden uit Chrome.

Pdf's krijgen op termijn ondersteuning voor JPEG XL om hdr en afbeeldingen met meer kleuren mogelijk te maken, schrijft The Register op basis van een presentatie van de PDF Association. Er is geen duidelijke tijdlijn voor wanneer de ondersteuning in het pdf-formaat komt te zitten, maar het is wel zeker dat de ondersteuning eraan komt.

JPEG XL is een afbeeldingscodec die het bestandsformaat aanzienlijk terug kan dringen zonder veel kwaliteitsverlies. Daarbij zijn dergelijke bestanden backward compatible, ofwel kunnen bestaande JPEG-bestanden getranscodeerd worden naar het nieuwe formaat. Webdiensten hebben daardoor minder opslag nodig voor het bewaren van afbeeldingen.

De ondersteuning voor JPEG XL zat in 2022 in Chrome, maar Google besloot die te verwijderen. De zoekgigant voerde als reden aan dat er te weinig interesse zou zijn om de standaard toe te passen. De ontwikkeling van de standaard ging wel door en vorig jaar kwam er een nieuwe versie van.

JPEG XL.jpg

Reacties (51)

[Sando]

Toevoeging aan het artikel: De ondersteuning van JPEG-XL in PDF-bestanden zal geen invloed hebben op het al dan niet ondersteunen van JPEG-XL in de browser.

PDF ondersteunt ook al 22 jaar JPEG-2000. Het is 14 jaar geleden gestandaardiseerd voor archival PDF/A-2 long term storage en de meeste browsers ondersteunen ook nog steeds geen J2K. Browsers gebruiken dan ook een PDF-engine om PDF's te tonen, niet de browser engine. Bij Chromium is dat PDFium.

The Internet Archive maakt ook veel gebruik van J2K om comics en afbeeldingen met text te archiveren als PDF. Dit gebruik ik zelf ook op mijn scans in Linux. Ik hoop dat zij ook snel JXL zullen implementeren in deze workflow!

De ondersteuning voor JPEG XL zat in 2022 in Chrome, maar Google besloot die te verwijderen.

Nadat veel mensen interesse toonden, gaven Google devs aan dat het ook om de veiligheid ging. JPEG-XL zou ingewikkeld zijn en veel attack vectors voor buffer overflows hebben, en ze willen die kosten niet op zich nemen.

Mozilla zou bezig zijn met een memory safe alternatief in Rust dat ze hebben uitbesteed aan Google (ik maak geen grap) en als die af is wil Google het heroverwegen om in Chrome te stoppen.

[Reactie gewijzigd door Sando op 11 november 2025 11:36]

[de-cvd]

Ze zijn al druk bezig met de Rust versie: https://github.com/libjxl/jxl-rs

[markg85]

Nadat veel mensen interesse toonden, gaven Google devs aan dat het ook om de veiligheid ging. JPEG-XL zou ingewikkeld zijn en veel attack vectors voor buffer overflows hebben

Ik weet niet waar je dat heb gelezen maar dat is op zijn zachts gezegd uit de context getrokken overdreven onzin. Rond de tijd dat JXL in de browser kwam (en er vervolgens weer uit ging) heb ik de bug reports bij chromium in de gaten gehouden die over dit onderwerp gingen. Let wel, destijds was het bestaan van AVIF (plaatjes formaat van AV1) nog in de kinderschoenen. Of AVIF in browsers ging komen was onduidelijk.

Google gaf veel redenen om JXL niet te ondersteunen. Ze gaven redenen als slechte performance i.v.t. bestaande codecs (begrijpelijk voor een nieuwe codec en flauw als argument). Ze gaven code onderhoudbaarheid en complexiteit als argumenten. Ook hebben ze gezegd dat AVIF een "gratis" functie is omdat AV1 toch ook al in de browser zat en dat (voornamelijk) als argument tegen JXL gebruikt.

Destijds was het heel duidelijk als je tussen de regels door las dat AVIF de browser in moest en JXL eruit.

Je kan hier wel zeggen dat er een flink staaltje machtsmisbruik door google is uitgevoerd om JXL uit de browser te houden. De industrie acceptatie en steun voor JXL was enorm dus dit had een no-brainer van acceptatie moeten zijn. Inmiddels kan je zeggen dat het machtsmisbruik goed gelukt is, avif werkt op ruim 90% van de mainstream browsers, jpeg-xl is effectief 0%.

[bzuidgeest]

JPEG-XL zou ingewikkeld zijn en veel attack vectors voor buffer overflows hebben

Persoonlijk vind ik als programmeur dat een absoluut slecht excuus. Buffer overflows is niet iets van de specificatie, het is iets van slecht programmeer werk.

Er zijn genoeg talen op de planeet die op een op andere manier voor overflows op buffers e.d. kunnen checken en waken. En ook gewoon goed testen is een redelijke optie. En natuurlijk ben je er zelf nog bij om controles in je code te schrijven.

[Joshua]

Ik mis een beetje de noodzaak waarom het zo belangrijk is om te vernoemen dat het verwijderd is uit Chrome.. alsof Chrome bepaald wat de standaard hoort te zijn? Hoe zit het dan met support in Firefox en Safari?

[onok]

Het is belangrijk omdat Chrome by far het grootste marktaandeel heeft onder de browsers. Dus geen Chrome support = je kunt het niet gebruiken (op het web).

[devilkin]

En chrome, chromium, vivaldi, edge, brave, ... allemaal voor een groot stuk gebaseerd zijn op dezelfde basis: chromium.

[novasurp]

Je kan als website makkelijk JPEG XL met fallback naar WebP en ouderwets JPEG gebruiken.

[Celebithil]

Is het voordeel "Webdiensten hebben daardoor minder opslag nodig voor het bewaren van afbeeldingen." wel meteen weg.

(Ja, je wint nog wel aan kosten voor bandbreedte, maar toch).

[rbr320]

Bandbreedte is duurder dan opslagruimte, dus dat zullen de grote jongens op het web zien als winst

[demianmonteverd]

Aanvulling op wat onok schreef: je kunt op caniuse zien hoe groot de adoptie is van functies.

Hier kun je het onderzoek van google naar JPEG-XL versus alternatieven (AVIF, WebP) lezen.

[Raem]

Safari is de enige die het enigszins ondersteunt.

https://caniuse.com/jpegxl

[TheVivaldi]

En Firefox, al moet je dan wel Nightly gebruiken en in about:config duiken om de instelling aan te zetten, maar voor de gemiddelde tweaker is dat geen probleem.

[SaiBork]

Windows Firefox ondersteund nog steeds geen HDR op een normale manier. Dit is dan ook een van de grootste redenen dat ik geen Firefox gebruik. Bijna 2026 en nog steeds geen HDR support voor videos.

[TheVivaldi]

Het ging om JPEG XL…

[SaiBork]

Klopt, en JPEG XL voegt onder andere hdr ondersteuning toe voor afbeeldingen.

In het artikel: "Pdf's krijgen op termijn ondersteuning voor JPEG XL om hdr en afbeeldingen met meer kleuren mogelijk te maken"

[KorporaalTimmer]

Safari ondersteunt naar mijn weten gewoon alles perfect, inclusief kleurprofielen en zelfs HDR in een foto

[Server.1968]

Safari ondersteunt helaas geen flac, beetje off-topic maar moest eraan denken door jouw post.

[KorporaalTimmer]

Wel Alac, wat hetzelfde of beter is maar goed opgemerkt

[BartOtten]

Behalve CSS dan.

[DdeM]

Hadden ze niet beter kunnen focussen op avif images? Geen idee hoe dat zich verhoudt tot jpg XL maar het is een nog efficiënter formaat dan webp en wordt ondersteund door alle moderne browsers.

[N8w8]

AVIF heeft max 12bit RGB, "tiles" van 4096x2304 waarbij tussen de tiles overgangen zichtbaar kunnen zijn, kan niet lossless, heeft geen progressive decoding, en de lossy mode heeft bij weinig compressie (grotere files) een lagere kwaliteit. En zoals al genoemd, kan je JPEG niet zonder (verder) kwaliteitsverlies ernaar omzetten voor kleinere files.
Bij JPEGXL is dat allemaal beter. edit: Oja, en met JXL kan je plaatjes in theorie ook opdelen in verschillende stukken met verschillende settings. Bijv bij n portret doe je t gezicht in hoge kwaliteit en achtergrond lage kwaliteit.
Wel heeft AVIF hogere kwaliteit bij veel compressie (kleinere files), en kan JPEGXL last hebben van chroma bleed.
Als je alleen naar website gebruik kijkt dan is AVIF mss goed genoeg, maar voor "universeel" gebruik (bijv plaatjes van MRI scanners(?) of ruimtetelescopen) schiet het echt tekort.
In dit geval gaat het ook niet over websites maar over PDF.

@DdeM, oeps, ja dat lossless had ik blijkbaar verkeerd onthouden

[Reactie gewijzigd door N8w8 op 11 november 2025 12:00]

[DdeM]

Hmm volgens de specs kan avif wel lossless, maar heeft verder inderdaad minder features dus thanks voor het overzicht. Maar, de meeste mensen (die ik ken) openen pdfs in hun browser dus vraag ik me toch af of jpg XL wel de juiste focus is, want dan krijg je straks mogelijk een hele sloot aan zeurende mensen als hun images in de pdf "niet werken".

[bigkillerstorm]

Zoals Nw8 zegt jpeg xl is erg functioneel en kan miniaturen van zichzelf maken zonder extra rekenwerk. Als je kwaliteit boven de 80-85% doet is jpeg-xl kwalitatief hoger en kleiner bestand. Avif loseless is gewoon geen keus die je wilt doen. Dan beter jpeg-xl gebruiken. Maar wil je snelle website en hoeven fotos geen ultra hoge kwaliteit te hebben. Avif blinkt wel uit in 30-70% compressie. Echt lager als 30 raad ik niet aan tenzij het hele simpele afbeeldingen zijn zoals logo's etc.

[novasurp]

JPEG XL is efficiënter dan AVIF. Alleen Google is AVIF aan het pushen.

[vickypollard]

Is Google niet juist WebP aan het pushen?

[Klaus_1250]

Altijd verbaasd hoe succesvol JPEG was, maar hoe moeizaam het daarna is geweest om de standaard door te ontwikkelen. JPEG2000 heeft het niet gehaald destijds (was tijd ver vooruit) en ook JPEG XL lijkt het niet te worden (mosterd na de maaltijd).

Wat ik in bovenstaande mis is dat Google zelf aan deze standaard heeft meegewerkt. En het dus extra frappant was dat ze zo snel de ondersteuning al weer uit Chromium haalde. Apple ondersteund wel het uitlezen van afbeeldingen dan weer wel.

[laptopleon]

Ja, dat is toch met zoveel standaarden? Kijk naar hoe mateloos populair e-mail werd, zodra het breed beschikbaar kwam, maar qua beveiliging, authentificatie etc is er van alles achteraf en dus optioneel bij bedacht.

Nog vreemder is dat er voor van alles nog steeds geen standaard is. Waarom stelt de EU bijvoorbeeld niet gewoon een standaard voor digitale facturen voor? Al was het maar alleen de namen van de verplichte veldjes in een factuur in een pdf, zoals welk stukje tekst het adres, kvk-nummer, de btw, eind totaal etc is. Zodat de software van je boekhouder het feilloos kan inlezen. Dat alleen al zou zoveel tijd schelen.

Ja, er is software die dat grotendeels alsnog probeert te automatiseren, maar dan nog moet je het handmatig nalopen.

[robin1301]

Waarom stelt de EU bijvoorbeeld niet gewoon een standaard voor digitale facturen voor?

Dat hebben ze: Peppol, vanaf 1 januari verplicht voor alle b2b en b2g facturen in België, Nederland heeft nog geen datum gekozen maar kan al wel gebruikt worden.

[GertMenkel]

Waarom stelt de EU bijvoorbeeld niet gewoon een standaard voor digitale facturen voor?

De EU wil zich volgens mij niet met dat soort dingen bezighouden tenzij het echt de spuigaten uitloopt. Toen de EU de markt verplichtte om naar één laadstandaard te gaan voor draagbare apparaten heeft het ook de industrie ruim de tijd gegeven om die standaard te bepalen. Het afdwingen van specifieke technologie kwam pas nadat een bepaald fruitvormig bedrijf weigerde om mee te gaan.

In dit geval zegt de EU welke velden er precies nodig zijn, het zal hun geen bal schelen of je ze in een PDF of een LaTeX-bestand stopt. Er zijn genoeg standaarden hiervoor waar de markt zich aan kan houden als ze dat willen (gewoon een labeltje aan een veld plakken) maar pas als de noodzaak hoog wordt, zal de EU gaan bepalen welke standaard de norm is.

Momenteel lijken de meeste bedrijven helemaal geen tagging te gebruiken voor hun velden, wat echt rete-irritant is, maar je kunt als klant natuurlijk op zoek gaan naar een partnerbedrijf dat dat wel doet als je automatisering daarvan afhankelijk is.

[novasurp]

Als Apple en Nintendo niet geweigerd hadden, zouden we nu waarschijnlijk nog steeds MicroUSB gebruiken in plaats van USB-C.

[KorporaalTimmer]

Dat is een heel belangrijk punt, sterker nog, Apple heeft van de betrokken bedrijven de meeste ontwikkelaars voor de USB-C standaard geleverd omdat ze bang waren dat er anders een micro-usb2 opgedrongen zou worden

[TheVivaldi]

Nintendo, misschien, maar Apple vraag ik me eerlijk gezegd af. Ja, ze waren wel gehecht aan Lightning, maar daarentegen ook weer niet 100%, want ze hadden al voor de EU het afdwong apparaten met usb-c, uit eigen vrije beweging.

[laptopleon]

Momenteel lijken de meeste bedrijven helemaal geen tagging te gebruiken voor hun velden, wat echt rete-irritant is, maar je kunt als klant natuurlijk op zoek gaan naar een partnerbedrijf dat dat wel doet als je automatisering daarvan afhankelijk is.

Ja, de facturen die je zelf stuurt, kun je (laten) labelen hoe je maar wil, maar de facturen die je binnenkrijgt niet.

Kijk, ik snap dat de EU geen totalitaire staat is, waar je dit even verplicht maakt. En dat elk groot boekhoud-softwarebedrijf nu intussen zijn eigen standaard heeft en niet op wil geven, maar juist daarom is de enige uitweg een universele opmaak.

Hetzelfde zie je bij pakweg elektronische patientendossiers. Ik ken iemand die al dertig jaar werkt bij een bedrijf wat niets anders doet dan de patientendossiers van twee (groepen van) ziekenhuizen (of andere zorgbedrijven) gelijktrekken. Daar zijn ze dan een, anderhalf jaar mee bezig voor alles is aangepast en iedereen het snapt.

[Sando]

JPEG2000 heeft het niet gehaald destijds

Ja hoor, zonder dat je het doorhebt gebruik je al 14 jaar JPEG2000 in PDF. Als je een PDF wegschrijft voor de lange termijn en je kiest PDF/A-2 (2011) of PDF/A-3 dan is JPEG2000 de standaard. De ondersteuning zit er al sinds 2003 in, 22 jaar dus.

[Klaus_1250]

Misschien dat PDF het nog ondersteund en dat het nog wel niche toepassingen heeft (digital cinema)?, maar alle browsers hebben ondertussen de support verwijderd. Mocht je dus een mooie collectie jp2's hebben, dan moet je je dus enigszins zorgen maken over het uitlezen nu maar zeker over een jaar of 10-20.

[Werelds]

Wat ik in bovenstaande mis is dat Google zelf aan deze standaard heeft meegewerkt. En het dus extra frappant was dat ze zo snel de ondersteuning al weer uit Chromium haalde. Apple ondersteund wel het uitlezen van afbeeldingen dan weer wel.

Zo snel? Zat bijna 2 jaar in Chromium en niemand anders maakte aanstalten het ook te ondersteunen. Apple's ondersteuning kwam 4 maanden nadat Google het op gaf en is slechts een gedeeltelijke ondersteuning. Geen animatie, geen progressive decoding. Dat zal gebaseerd zijn op een eigen usecase die ze hebben, zo gaat dat meestal met Apple. Soortgelijk verhaal met APNG.

[jimshatt]

Als dit een standaard formaat wordt in PDFs dan zullen browsers het ook moeten gaan ondersteunen om PDFs te tonen?

[Sando]

Nee. De meeste browsers ondersteunen ook geen Jpeg2000, maar PDF wel. Browsers gebruiken een ingebouwde PDF-engine om PDF's te tonen.

[jimshatt]

Maar die engine moet dan dus die formaten ondersteunen. Ofwel direct dan wel door te converteren naar een ander formaat dat de browser wel ondersteunt.

Waarom dan niet ook buiten de pdf engine (die volgens mij gewoon in javascript is geschreven) ondersteunen?

[Hugo!]

Zonder direct credits te willen geven aan Apple. Ik vind het opvallend dat Apple volop heeft ingezet op JPEG XL en er nu weer shot in de zaak lijkt te komen. Het is jammer dat Google hun eigen formaten wil blijven pushen, ik vind dit een mooie ontwikkeling.

[elmuerte]

JPEG XL is ook een Google formaat.

[Hugo!]

Ik heb het opgezocht, maar je hebt helemaal gelijk. In dat geval, Jammer dat Google JPEG XL grotendeels heeft laten vallen.

[lenwar]

Het is een formaat van de 'Joint Photographic Experts Group', en Google heeft mee-ontwikkeld aan het formaat. (essentieel detail). Het is overigens ook nog is een 'open formaat'.

[laptopleon]

Des te vreemder dat ze het hebben laten vallen.

[doyc]

JPEG XL is een interessant formaat, hoop dat het snel meer gangbaar wordt. Die keuze ligt natuurlijk bij de browser makers.

Het onderschrift van de bijgevoegde foto is overigens wel grappig. JPEG XL.jpg

[lenwar]

Juist in browsers lijkt het me een minder interessant formaat. De meerwaarde van het formaat is juist voor ongeveer 100,0% van de websites irrelevant. Hooguit wat 'foto-sites'. Het is eerder iets dat in andersoortige software moet komen/zitten.

[doyc]

Het grote voordeel aan JPEG XL is dat de compressie er veel op vooruit gaat. Kijk voor de grap eens hoeveel afbeeldingen je binnenhaalt op een willekeurige website. Zelfs op deze tweakers pagina download je tientallen afbeeldingen. Stel je voor dat het 10-20% procent sneller kan laden. (Dat is nog een voorzichtige schatting) Bedenk je nu dat je het hele internet dan 10-20% minder data hoeft te vervoeren. Als je daar een kosten plaatje aan hangt kom je op astronomische bedragen uit.

[lenwar]

Bedenk je nu dat je het hele internet dan 10-20% minder data hoeft te vervoeren. Als je daar een kosten plaatje aan hangt kom je op astronomische bedragen uit.

Dit is zeker een valide punt, maar websitemakers lijken weinig bezig te zijn met de hoeveelheid data die hun site is/over de lijn trekt. Kijk alleen al op Tweakers:
https://tweakers.net/g/forum_themes/popular-topic-1296w.jpg
https://tweakers.net/i/AY7xItuhjJZLvF5I1jigyINOQ8c=/640x200/filters:strip_icc():strip_exif()/i/2006575882.jpeg?f=ankeiler_small
Die plaatjes die op het moment op de site staan als een soort miniaturen zijn vrij groot.

Of kijk dan is naar hoeveel data een adblocker scheelt. De hoeveelheid data aan trackingscripts is gigantisch (die is zo 30-50% van een website (niet overdreven). Nou snap ik dat dat een neveneffect is van de inkomstenmethode van websites is, maar daar moet ook wel echt veel mogelijk in zijn.
Of kijk naar al die Wordpress-sites, die een vracht scripting en spul meesturen die al dan niet gebruikt wordt.

[Tourmaline]

O.a. transparantie....

[Atomsk]

Hoop dat het nog wat wordt met jpegxl voor het weergeven van HDR afbeeldingen. Het enige wat nu breed ondersteund wordt is jpeg met gain maps. Een doorsnee CMS of online fotoalbum laat daar echter niks van heel.