W3C geeft officiële specificaties voor PNG 3 met Exif- en hdr-ondersteuning vrij

Het W3C heeft nieuwe specificaties voor PNG 3 vrijgegeven. De nieuwe standaard heeft onder meer ondersteuning voor hdr en kan nu officieel Exif-metadata opslaan. Ook krijgt PNG ondersteuning voor animaties.

Het World Wide Web Consortium, of W3C, heeft de nieuwe standaard PNG 3 uitgebracht. In de specificaties staat beschreven hoe het Portable Network Graphics-formaat in de toekomst kan worden geïmplementeerd. PNG is, naast JPEG en GIF, een van de belangrijkste bestandsformaten, maar de vorige versie, PNG 2, stamt nog uit 2003. PNG 3 werd al in 2022 voorgesteld, maar is nu definitief klaar als specificatie.

PNG 3 ondersteunt nu volledige hdr-kleuren in meer dan 8bit. Dat gebeurt onder andere met Coding Independent Code Points of CICP's. Dat is een onderdeel van de metadata waarin de kleurruimte wordt beschreven, waardoor afbeeldingen in de toekomst ook HDR10- of HLG-kleuren kunnen weergeven. De CICP-standaard zat eerder al in modernere bestandsformaten zoals AVIF en JPEG XL.

PNG heeft nu ook ondersteuning voor Exif-metadata, althans, officiële ondersteuning. In de praktijk was het al heel lang mogelijk metadata aan een afbeelding toe te voegen, maar daarvoor moesten softwaremakers zelf ondersteuning schrijven.

Hetzelfde is het geval voor geanimeerde afbeeldingen. Dat is nu niet alleen maar voorbehouden aan gifs, maar ook aan png's. Ook dat was al langer mogelijk; er bestond al het APNG-formaat voor animated png's, maar softwaremakers moesten dat zelf toevoegen. Dat was lang niet overal het geval: Adobe maakt het bijvoorbeeld niet mogelijk een geanimeerde png te maken in Photoshop. Door de officiële ondersteuning toe te voegen aan de standaard zou dat wel makkelijker moeten zijn.

Reacties (34)

[Kun]

Kan iemand me uitleggen waarom er nog een nieuwe PNG versie nodig is? Als software toch aangepast moet worden om deze nieuwe versie te ondersteunen waarom zou je dan niet gelijk voor WebP of AVIF kiezen?

[jaapzb]

De standaard is aangepast zodat het juist reflecteert wat er in de praktijk ondersteund word door de meeste applicaties die PNG-ondersteuning bevatten. Ze hebben 10 jaar niks gedaan aan de specificatie, maar er zijn wel ontwikkelingen geweest die de facto standaard zijn geworden, en die zitten nu officieel in de spec, bijvoorbeeld geanimeerde PNG's.

Er komen wel nieuwe versies van PNG aan met nieuwe functionaliteiten.

waarom zou je dan niet gelijk voor WebP of AVIF kiezen?

Tja waarom zou je niet voor JPEG kiezen, of GIF? PNG wordt breed ondersteund door veel verschillende programma's, dus lijkt mij verstandig om de spec uit te breiden met nuttige, moderne functionaliteiten.

[downtime]

Tja waarom zou je niet voor JPEG kiezen, of GIF?

Dat is geen goede vergelijking. JPEG is lossy en GIF ondersteunt alleen 8-bits images. Dus beide hebben een hele andere use case.

[leuk_he]

precies JPEG en Wepb is lossy, dus wordt vaag of wordt blokkerig. PNG is lossless, je kunt het 100 keer door PNG heen halen, en het plaatje blijft hetzelfde. Voor computer graphics/screenshots werkt dat over het algemeen heel goed. Uiteraard kun je een formaat gebruiken dat alles kan, maar gespecialiseerde tools zijn duidelijker.

[Ayporos]

Wat ik zelf nogal storend vind is dat alles altijd maar alles moet ondersteunen.
Leuk hoor geanimeerde PNG's.. nóg meer manieren voor trolls om mensen voor de gek te houden.

Overigens wel mooi hoor, ik had altijd al een hekel aan lossy afbeeldingsformaten maar anno 2025, in ieders geval hier in Nederland, lijkt het me toch dat men zowel voldoende bandbreedte als ook opslag heeft op hun devices dat het eigenlijk toch niet nodig zou moeten zijn.

Lossy opslag was een tool om een probleem op te lossen. Dat probleem is er nu nauwelijks meer, dus laten we s.v.p er mee stoppen.

[BugsNL]

Ik had even gekeken wat er gebeurt met mijn RAW file als ik die converteer naar de verschillende formaten:

• Origineel .RAF = 56.539kB
• Converted naar JPG = 18.397kB
• Converted naar JPGXL = 5.249kB
• Converted naar PNG = 119.663kB

Converted met Affinity Photo v2.6.3

Ik dacht dat het een fout van affinity was om het PNG bestand te verdubbelen maar dat komt omdat die het in 16 bit bitdiepte opslaat. Export met Darktable gemaakt om ook een 8bit te maken:

• Origineel .RAF = 56.539kB
• Converted naar JPG = 24.863kB
• Converted naar JPGXL = 4.086B
• Converted naar PNG(8bit) = 33.470kB
• Converted naar PNG(16bit) = 122.733kB

Dan zie je toch wel dat er nog een groot verschil zit tussen JPG en 8bit PNG. Met mijn 400mbit internet verbinding zou dat betekenen dat een JPG laad in een halve seconden maar een PNG in iets minder dan een seconden. Ook als je het voor jezelf opslaat op een netwerkschijf is het gebruik van PNG het niet waard. Omdat je zelf niet de JPG honderden keren opent om opnieuw op te slaan.


JPGXL is dan wel weer een interessante omdat die het formaat bijna met 2/3e verminderd. Helaas wordt dat nog niet breed ondersteund (voor Windows 11 moest ik iig een extra plugin installeren van de Windows Store). Anders was dat zeer handig om te gebruiken om foto's te delen.

edit:

stukje van JPGXL toegevoegd.

[Reactie gewijzigd door BugsNL op 27 juni 2025 20:43]

[FlaffTweakr]

Ik denk dat je berekeningen er helemaal naast zitten.
400 Mbps = 50MB/s
Trek daar 20% overhead en storing van af, en je zit aan 40MB/s.
Je PNG is ~125kB, en als we afronden naar 1MB = 1000kB, dan heb je 40.000 kB/s, waardoor je uitkomt op in de orde van 3ms, terwijl latency meestal een orde hoger ligt.

Je kan ~300 png's van die grootte binnenhalen per seconde, of ga naar een bad case scenario (latency, lage bandwidth, lage server performance) en je zit aan misschien 25-75 per seconde.

Foutje!

[Reactie gewijzigd door FlaffTweakr op 29 juni 2025 09:53]

[databit]

Je PNG is ~125kB

Voor zover ik weet, worden duizendtallen in het Nederlands in de regel nog steeds gescheiden door een punt. Ik wil niet voor OP spreken, maar ik gok dat je er zelf een aantal orde grootte naast zit.

En dit is precies de reden waarom we lossy formaten ooit in het leven geroepen hebben: deze hoeveelheden data de lijn over sturen is gekkenwerk, ook anno 2025

[BugsNL]

Je hebt helemaal gelijk, heb de getallen van een Nederlandse Windows installatie.

Omgevormd naar MB is het DUS (Darktable conversie)

JPG = 24MB

PNG = 33MB

Het ging om een foto geschoten met een fujifilm x100V, RAW van 26 mega pixel

[Reactie gewijzigd door BugsNL op 28 juni 2025 08:51]

[Memori]

En doe voor de gein eens naar AVIF?:

ffmpeg -i bestand.RAF -c:v libaom-av1 -still-picture 1 -crf 30 "bestand.avif"

[BugsNL]

Verlies vrij = 29.213 kB

Met verlies (100% kwaliteit) = 23.687 kB

Uitgevoerd met Darktable

[Reactie gewijzigd door BugsNL op 29 juni 2025 07:17]

[curkey]

Ik weet niet hoor, maar de raw bestanden uit mijn camera zijn 32 MB de stuk. De jpg voor in een webgalerij significant veel kleiner. Ondanks glasvezel laadt zoiets veel snappier.

Ik moet er niet aan denken dat websites hun advertenties of boilerplate graphics ongecomprimeerd gaan aanbieden.

[SCS2]

Lossy is helemaal niet "erg" ! Dat is een vooroordeel.

ALLEEN bij kleine, lage resolutie afbeeldingen met scherpe randen in lossless echt nodig.

Of bij veelvuldig bewerken en saven van een afbeelding. Niet voor het resultaat.

Bij de huidige hoge resoluties moet je echt moeite doen om verschillen te zien.

Er zit vaak zoveel nutteloze details in dingen, die hoeven helemaal niet bewaard te worden.

Test met good old JPG, neem een foto, save met bijv Irfan naar jpg 70%, 80% en 90%.

Open de gesavede files, volle grote, dus 1:1 met pixels van je scherm

Loop er zo hard doorheen met alt-tab, kijk "blind" en probeer in te schatten welke het is.

Bij het wisselen zie je ook mooi de onderlinge verschillen

Meestal zie ik pas bij een zoom van 400% afwijkingen, uiteraard bij jpg 70 eerder dan 90

En die verschillen zijn vaak kleiner dan bijvoorbeeld de weefsel van een jasje.

JPG 90% is als zo goed, dat zie je niet.

En de nieuwe webP is slimmer en beter.

Bedenk hoe groot de afbeelding ooit gebruikt gaat worden en genoeg is genoeg.

(Sorry, regelafstand doet ineens raar bij Tweakers)

[N8w8]

Webp kan ook lossless, en is dan doorgaans ook n stuk kleiner dan PNG in mijn ervaring.
Alleen kan webp niet meer dan "gewoon" 8bpc.

[OttoRocketman]

Als software toch aangepast moet worden om deze nieuwe versie te ondersteunen

Volgens mij hoeft dat niet per se?

Ik denk overigens dat er nog veel (oudere) applicaties zijn met image-uploaders die geen WebP/AVIF ondersteunen, dus dan kun je nu alsnog bijv. een hdr afbeelding uploaden

[jumbos7]

Omdat het consortium achter PNG niets te maken heeft met Webp of AVIF en een concurrende standaard is. Uiteindelijk is het aan de gebruiker van de standaarden welk formaat ze voor hun toepassing willen gebruiken.

[HerrPino]

Compressie is 1 ding, maar cpu-overhead en geheugen gebruik bij het decoden is een ander. Er geen enkel formaat welke altijd het beste is. Niet voor images (graphics of foto's), audio, video of desnoods 3d meshes. Ieder voordeel heeft z'n nadeel, en je gebruikt het formaat wat voor de taak het meest ideaal is ... niet waar je zelf het 'warmste gevoel' bij krijgt.

[curkey]

Waren die laatste trouwens niet door Google ontwikkeld?

[lenwar]

Avif is (zo ver ik weet niet lossless), dus dat geeft een ander doel.

Webp is beter met foto's, PNG is beter met scherpe teksten. PNG is makkelijk te bewerken zonder verlies. Webp had (heeft?) beperkingen met alpha-kanaal transparantie.

Er zit heel veel overlap in, maar elke standaard heeft zwakkere en sterkere punten.

[Jeffrey2107]

lossless vs lossy.

[downtime]

In de praktijk was het al heel lang mogelijk metadata aan een afbeelding toe te voegen, maar daar moesten softwaremakers zelf ondersteuning voor schrijven.

Dat is wat onduidelijk. Is er dan nu referentiecode die ze kunnen gebruiken? Want ze moeten toch sowieso ondersteuning schrijven? Of wordt er bedoeld dat ze dan hun eigen specificatie moesten bedenken?

[jaapzb]

De spec is up to date gebracht met wat applicaties die PNG ondersteunen zelf al veel langer hadden ingebouwd. Dingen die de-facto standaard waren (zoals APNG's), zijn nu ook "officieel" standaard. Applicaties hoeven nu dus niks extra's te doen om ondersteuning hiervoor te maken.

[downtime]

De tekst van het artikel klopt dus niet. Er is niets veranderd voor softwaremakers want die moeten nog steeds "ondersteuning" schrijven. Het enige wat veranderd is, is dat ze nu een officiele spec hebben.

[Cristan]

De beste concurrent voor PNG wat mij betreft is WebP. Deze heeft een lossless variant die echt ontzettend goed comprimeert (een stuk beter dan PNG). Ik ben best vaak in de hilarische situatie geweest dat een 90% kwaliteit WebP een stuk groter is dan de 100% kwaliteit, gezien die met de 100% kwaliteit in een "PNG-stand" terecht komt. Persoonlijk vind ik het dan ook belachelijk dat de modernere AVIF slechter is met lossless dan WebP.

Dit gaat het verschil in compressie met WebP lossless niet oplossen, het is meer een uitbreiding op de huidige PNG specificaties. Op zich ook niet verkeerd.

[elmuerte]

Voor photo-achtig materiaal is WebP inderdaad veel beter. Maar voor pixel nauwkeurig, of klein, materiaal gaat het vaak minder goed.

Daarnaast heeft PNG een fantastische feature dat je er heel goed arbitraire data in kan opslaan. Zo is een PICO-8 "cartridge" een PNG waar de code van de software als extra data in zit. Voor de image viewer zie je een logo, voor de PICO-8 VM is het software. Dit is uitvoerbare software: https://www.lexaloffle.com/bbs/cposts/sn/snekburd-6.p8.png

Macromedia Fireworks gebruikte dit ook om de source van de image op te slaan.

Source materiaal sla ik eerder op als PNG om het vervolgens mogelijk als WebP te exporteren.

[dmantione]

Inderdaad. De ontwerpers van PNG hebben zich laten inspireren door het IFF-formaat dat op de Amiga heel populair was. Net als IFF is PNG een hiërarchisch bestandsformaat waar naar believen nieuwe chunksoorten aan toegevoegd kunnen worden. Het is te vergelijken met XML, waar naar hartelust nieuwe XML-tags bedacht kunnen worden, maar dan voor binaire gegevens, . PNG is net zo flexibel.

[Cristan]

Voor photo-achtig materiaal is WebP inderdaad veel beter. Maar voor pixel nauwkeurig, of klein, materiaal gaat het vaak minder goed.

Ik weet niet of ik ooit een PNG ben tegen gekomen die niet kleiner kan worden dmv deze te converteren naar een lossless WebP. Let wel op dat WebP eigenlijk 2 formaten zijn, de lossy en de lossless formaat. De lossy variant werkt inderdaad beter bij foto's, maar een 100% WebP werkt juist extra goed bij plaatjes waar traditioneel PNG het erg goed doet. Bij dit soort plaatjes merk je dan ook dat een 99% kwaliteit WebP een heel stuk groter is dan de 100% WebP.

Maar I'm happy to be proven wrong. Als je een link naar een PNG hebt die niet kleiner wordt dmv deze te converteren naar WebP, ben ik hier erg geïnteresseerd in.

Arbitraire data opslaan klinkt wel als een leuke feature voor sommige use cases, ja .

[elmuerte]

Voor een deelbare voorbeeld moet ik even opzoek gaan (of even een eentje maken). Maar zo uit m'n hoofd zijn bijvoorbeeld 8bit PNGs met alpha, ja dat kan, meestal kleiner dan een WebP. De reden hiervoor is natuurlijk simpel, webp heeft geen pallet optie. Als je lossy wilt zijn met alpha transparency en er worden weinig kleuren gebruikt, dan zou je met pngquant bijvoorbeeld een beter resultaat kunnen krijgen dan met webp, en het verschild is nauwelijks merkbaar. De truk in kleine PNGs maken zit in optimaal gebruik van de verschillende PNG compressors (die vaak niet gebruikt worden).

PS, q=100 is niet een percentage. Het is "gewoon" een nummer. q=75 is namelijk niet 25% punt beter dan q=50. Als je echt goed lossy wilt compressen zal je het echt op het oog moeten doen welke q je wilt gebruiken. Zeker bij gradients moet je oppassen, ook bij hogere q kunnen die er slecht uit komen (gelukkig niet zo erg als bij jpg).

[Stijnvi]

Semi-off-topic, maar wanneer komt er eindelijk universele ondersteuning voor HEIC/HEIF?

Bijna alle nieuwe apparaten slaan hun afbeeldingen in dit format op, maar bijna geen enkele website ondersteunt het, en op Windows moet je zelfs een speciale licentie kopen.

[Seal64]

Voor zover ik kan vinden is HEIF de container, waar je dan verschillende encoders in kunt stoppen. HEIC gebruikt vervolgens HEVC als encoder, maar er zijn ook varianten waar AV1 of zelfs gewoon JPEG in zit. Win10 ondersteunt de HEIF container middels een (gratis) plugin, en in Win11 zit die standaard al ingebakken.

Waar je voor betaalt is de HEVC licentie om de inhoud van die container te kunnen decoderen - die is namelijk niet gratis, daar hangen allerlei patenten en dus licenties achter.


Microsoft zal er voor kiezen om die HEVC codec niet standaard mee te leveren omdat dat gewoon geld kost (al zal het niet veel zijn op de schaal waarop zij werken), maar ook omdat ze natuurlijk wel heel snel tegen allerlei antitrust rechtszaken aan lopen. Als ze HEVC mee gaan leveren dan krijg je geheid rechtszaken van concurrerende codecs of formats die dat als machtsmisbruik zien en dan gaan eisen dat zij ook meegeleverd worden, of dat ze HEVC eruit halen.

Merk overigens op dat als je al een HEVC codec geïnstalleerd hebt, Windows die wel gewoon zal gebruiken. Je hoeft dus niet de versie uit de MS Store te downloaden. Ik heb die namelijk niet op mijn PC staan maar kan wél gewoon HEIC files bekijken met de ingebouwde foto-viewer van MS zelf. Mijn werklaptop, daarentegen, stuurt me wél naar de Store voor die plugin, dus daar staat geen HEVC codec op.

[Reactie gewijzigd door Seal64 op 27 juni 2025 16:31]

[Arrigi]

Klopt. Whatsapp converteert afaik nog naar JPG voor compatibiliteit en ik exporteer foto's van RAW naar JPG vanwege dezelfde reden...

[Cristan]

Zolang Safari de enige browser is die dit formaat ondersteunt, zou ik mijn adem niet inhouden. Wel apart dat Chrome dit niet ondersteunt, gezien Google een founder is van de Alliance for Open Media waar dit formaat vandaan komt.

[djwice]

verwijderd - staat me al in het artikel

[Reactie gewijzigd door djwice op 27 juni 2025 14:45]

[Armselig]

Geinig, ik wist niet dat er nog nieuwe bestandsformaten werden gemaakt, of in dit geval geupdate.