Geschiedenisles: Wat is een .png-bestand? Het formaat dat GIF moest vervangen

Wat is een .png-bestand?

Een .png-bestand is een afbeelding in het Portable Network Graphics-formaat. In gewone taal: een verliesvrij gecomprimeerde afbeelding (de decompressor bouwt exact de pixels op die de encoder opsloeg), gemaakt om over het vroege web te reizen zonder de patentlast die GIF trof. De officiële uitspraak is “ping.” De recursieve grap — “PNG’s Not GIF” — bleef in het ontwikkelaarsfolklore hangen naast de serieuze naam.

Op schijf is een PNG een korte handtekening gevolgd door chunks: benoemde blokken die de kop, het palet, gecomprimeerde pixels, tekstopmerkingen en een eindmarkering dragen. Dat ontwerp laat het formaat groeien met optionele functies zonder te doen alsof elk bestand een tekenfilm is. De alledaagse zoekopdracht “wat is een .png-bestand” komt meestal van iemand die naar een scherpe screenshot, een logo met zachte schaduw of een diagram kijkt dat “te groot” lijkt naast een foto-JPG — en zich afvraagt of er iets mis is. Bijna nooit; het formaat doet ander werk. Voor de GIF-geschiedenis waar het op antwoordde, zie Geschiedenisles: Wat is een .gif-bestand?.

Waarom is mijn PNG veel groter dan een JPG?

Verliesvrij tegenover verlieslatend is de hele schrik. PNG houdt pixelwaarden terug te halen na decompressie. JPEG (de alledaagse JPG-route) gooit hoogfrequent detail weg dat het oog in foto’s met doorlopende tonen zelden opmerkt, daarom is een vakantiefoto als JPG vaak piepklein en als PNG hardnekkig groot. Een Windows-screenshot, een UI-mockup of een gescand diagram heeft scherpe randen en vlakke kleur — precies waar verliesvrij wint en verlieslatende ringing er lelijk uitziet.

Transparantie voegt ook bytes toe. GIF bood één transparante palet-index — een hard ja/nee-gat. PNG kan een alfakanaal opslaan: een transparantiewaarde per pixel, zodat zachte schaduwen en glasranden netjes over elke achtergrond worden samengesteld. Die kracht is waarom ontwerpers van PNG hielden en waarom een doorschijnende export groter is dan een vlakke JPG met dezelfde breedte en hoogte.

Het LZW-geschil van Unisys en waarom PNG ontstond

GIF was het werkpaard van het vroege web geworden voor logo’s en eenvoudige graphics. De compressie gebruikte LZW, en Unisys bezat een sleutelpatent. Na gesprekken met CompuServe maakte een aankondiging eind december 1994 duidelijk dat GIF-compatibele software royalty’s kon betekenen. Usenet ontplofte begin januari 1995. Deze les verzint geen tarieven; het culturele feit volstaat: auteurs die GIF vrij te implementeren achtten, stonden ineens voor een licentieprobleem. Protesten zoals “Burn All GIFs” en de drang naar een schone vervanger volgden. De eerdere GIF-les behandelt CompuServe, GIF87a / GIF89a en de patenttijdlijn uitgebreider — PNG is het vervolg.

Thomas Boutell plaatste de eerste opzet van wat PNG zou worden — toen PBF (Portable Bitmap Format) — op 4 januari 1995 in grafische en compressiegroepen. Binnen ongeveer een week had de vrijwilligerskring de meeste blijvende ideeën voorgesteld: deltafiltering vóór het comprimeren (Scott Elliott, Mark Adler en anderen), deflate-compressie (Tom Lane, de Info-ZIP-gemeenschap en vele anderen), truecolor-diepte, interne CRC’s (Greg Roelofs) en de naam PNG zelf (Oliver Fromme). Boutell leidde de ontwerpen als welwillend dictator wanneer consensus vastliep. Met Draft 9 (7 maart 1995) lag het formaat feitelijk vast; latere ontwerpen verduidelijkten vooral.

Hoe de bytes werken: handtekening, chunks, DEFLATE, filtering, Adam7

Elke PNG begint met een handtekening van acht bytes zodat lezers het bestand herkennen ook als de extensie niet klopt. Daarna volgt een stroom chunks. Een chunk is een zelfbeschrijvend blok: lengte, vierletterige typenaam, datalading en een CRC (cyclic redundancy check) — een checksum die corruptie in type en data opspoort. Kritieke chunks die elke decoder moet begrijpen zijn onder meer IHDR (afbeeldingskop: breedte, hoogte, bitdiepte, kleurtype en vlaggen), een of meer IDAT (afbeeldingsgegevens: gecomprimeerde pixels) en IEND (einde van de afbeelding). Optionele chunks kunnen palet, eenvoudige of volledige transparantie, gamma-hints, tekst of andere metadata dragen zonder oude lezers te breken die onbekende hulptypen overslaan.

Pixels gaan niet ruw in IDAT. Eerst komt filtering: elke scanlijn kan worden herschreven als verschillen met naburige bytes zodat herhalende patronen beter comprimeren — een omkeerbare voorstap, geen tweede beeldformaat. Daarna worden de gefilterde bytes met DEFLATE (de LZ77-plus-Huffman-methode die ook in gzip / ZIP zit) gecomprimeerd via het zlib-formaat. Jean-loup Gailly en Mark Adler vormden zlib in die tijd; Guy Eric Schalnat leidde het vroege libpng-werk zodat toepassingen de decoder niet opnieuw hoefden uit te vinden. Specificaties en bibliotheken rijpten samen door 1995 heen.

Interlacing is optioneel. Methode 0 slaat rijen van boven naar beneden op zoals gebruikelijk. Methode 1 is Adam7, van Adam M. Costello: zeven passes over een 8×8-patroon zodat een grove voorvertoning verschijnt voordat de download klaar is — de progressieve weergavegewoonte die inbelbrowsers nodig hadden. Decoders moeten geïnterlinieerde bestanden kunnen lezen, ook als ze alleen het eindbeeld tonen.

W3C Recommendation, RFC 2083 en ISO/IEC 15948

Standaardisatie volgde op implementatie. Het World Wide Web Consortium (W3C) publiceerde PNG 1.0 als Recommendation op 1 oktober 1996 — een stabiele, beoordeelde referentie voor webgraphics. Dezelfde generatie tekst verscheen als RFC 2083 (PNG Specification Version 1.0, Informational) via de IETF. IANA registreerde het mediatype image/png. Later publiceerde ISO/IEC 15948 PNG als internationale functionele specificatie (de veel geciteerde editie van 2004), met de opmerking “pronounced ping” in de samenvatting. In gewone taal: wat als Usenet-brand begon, werd een formele web- en ISO-standaard.

De browserrealiteit liep achter op het papierwerk. Native PNG verscheen ongelijk in Netscape en Microsoft Internet Explorer eind jaren 1990. Volledige alfa-compositie was jarenlang een pijnpunt in Windows-IE: vroege versies gingen slecht met PNG om of alleen met grove binaire transparantie, en webontwikkelaars gebruikten AlphaImageLoader-trucs totdat Internet Explorer 7 de alfa per pixel verbeterde. Het formaat was klaar; de dominante browser kwam laat — een reden waarom GIF-banners en -lussen bleven bestaan.

Alfatransparantie versus GIF, en waarom een gewone PNG niet animeert

GIF89a kan één palet-index als transparant markeren. PNG kan die eenvoudige transparantie én, belangrijker, een volledig alfakanaal voor gedeeltelijke dekking. Zachte schaduwen, antialiased logo’s en overlays op onbekende achtergronden zijn de dagelijkse winst. Daarom werd “opslaan als PNG” de reflex voor UI-exports en daarom wint een foto opnieuw opslaan als PNG zelden van JPG qua grootte.

Animatie werd bewust uitgesteld. Basis-PNG is één afbeelding. MNG (Multiple-image Network Graphics) groeide in dezelfde gemeenschap als broer voor meerdere beelden / animatie — krachtig, complex en nooit een universele browserstandaard. APNG (Animated PNG) voegde later animatie-chunks toe aan een PNG-stroom zodat oudere decoders nog één stilstaand frame tonen terwijl nieuwere de frames afspelen. Behandel ze als zijsporen: de .png-bestanden die in 2026 screenshotmappen vullen zijn bijna altijd stilstaand.

Waarom .png-bestanden in 2026 nog op schijven staan

In 2026 duiken legacy-bestanden .png (en gloednieuwe) nog steeds op waar scherpte en transparantie tellen: OS-screenshots, app-store-assets, presentaties, gescande diagrammen, game-UI-pakketten, ontwerpoplevering en “Afbeelding opslaan”-downloads van het web. Camera’s geven nog steeds de voorkeur aan JPEG of RAW voor foto’s; editors kiezen nog steeds PNG wanneer pixels niet mogen vervagen. Het formaat won de stilstaande-beeldhelft van de gok om GIF te vervangen zo grondig dat mensen vergeten dat het begon als een noodcomité op Usenet.

Legacy File Converter vermeldt Portable Network Graphics / .png onder de ondersteunde afbeeldingen op Ondersteunde bestandstypen en converteert .png lokaal op de Windows-pc van de gebruiker naar JPG, PDF en andere vermelde doelen — er wordt niets geüpload. Dit artikel blijft bij de geschiedenis — het is geen handleiding om chunks met de hand te schrijven. Voor naastgelegen lessen over afbeeldingsformaten, zie Geschiedenisles: Wat is een .gif-bestand?, Geschiedenisles: Wat is een .bmp-bestand? en Geschiedenisles: Wat is een .jfif-bestand?.