Notities van het team over vakmanschap, formaten en de kleine beslissingen achter een goed resultaat.
Waarom WebP niet overal in desktopapps wordt ondersteund
WebP verscheen in 2010 bij Google, maar de overname door desktopsoftware liep ver achter op de browserondersteuning. Browsers namen WebP vroeg over omdat ze hun eigen rendering-engines beheren en Google de WebP-ondersteuning in Chrome actief aanjoeg als concurrentievoordeel. Desktopapplicaties bewegen trager bij een nieuw beeldformaat, want elke onderhoudt zijn eigen beelddecodeerstack en een nieuw formaat vraagt tests tegen een lange staart aan lastige gevallen. Adobe Photoshop, het dagelijkse gereedschap van de meeste professionele fotografen en ontwerpers, leverde native WebP-ondersteuning pas met versie 23.2 eind 2022. Microsoft Office-programma's behandelen WebP tot in 2026 ongelijk over de platformen heen. Print-RIP-software en het gros van de verouderde archiveringstools namen WebP nooit over. Het gevolg is dat een bestand dat in een browser foutloos oogt, botweg geweigerd kan worden door precies het programma dat de gebruiker nodig heeft, en omzetten naar PNG is de betrouwbare omweg.
Hoe WebP zijn compressievoordeel boven PNG bereikt
Onder PNG zit DEFLATE, een lossless werkpaard uit 1996. Het haalt eerst omkeerbare filters over elke scanlijn en stuurt het resultaat daarna door een zlib-stroom, degelijk werk, maar uit een tijd vóór het onderzoek naar videocodecs en machinaal leren het vak aanscherpte. WebP brengt twee nieuwere trucs. In lossy-modus trekt het een blokgebaseerde transformatie uit VP8-video, met intraframe-voorspelling en een discrete cosinustransformatie over 16x16-macroblokken. In lossless-modus weeft het ruimtelijke voorspelling samen met een kleurtransformatie en een LZ77-fase die typische beelddata simpelweg strakker pakt dan DEFLATE aankan. Googles eigen metingen leggen lossless WebP zo'n 26 procent onder PNG op een standaardset, en lossy WebP met alfa rond een derde van PNG bij dezelfde zichtbare kwaliteit. Van PNG naar WebP gaan boekt die winst, dus van WebP terug naar PNG geeft die terug, en het bestand zwelt aan.
Gemeten voorbeelden van groei in bestandsgrootte
Deze komen van Chrome 148 op een Linux-desktop, met het PNG-schrijfpad van het platform op door de browser gedecodeerde WebP-invoer. Neem een kleine afbeelding in vectorstijl van 400x300 pixels, opgeslagen als WebP op kwaliteit 80, en die wordt in zo'n 15 tot 25 ms als PNG herschreven met een groei van een vijfde tot een derde. Een fotografische WebP van 1024x768, zeg kleine bestandsgrootte, herschrijft binnen 100 ms naar PNG en zwelt drie tot vijf keer aan. Ga naar een forse fotografische WebP van 3840x2160, ruwweg grotere bestandsgrootte, en de PNG kost zo'n 1,2 seconde om te schrijven terwijl die vijf tot tien keer groeit, afhankelijk van hoe druk het beeld is. Aan het uiterste eind kan een WebP-foto van groot formaat rond de een PNG van meerdere malen die grootte landen. Elk cijfer weerspiegelt hoeveel strakker WebP dezelfde pixels pakt, en de groei loopt mee met het aantal pixels.
Alfatransparantie op de heen- en terugreis
WebP en PNG delen hetzelfde 8-bits alfabereik, waarbij 0 volledig transparant en 255 volledig dekkend betekent. Als de browser een WebP met alfa decodeert, bouwt die een pixelbuffer van RGBA-waarden waarvan de A-component de oorspronkelijke alfa spiegelt. Die buffer als PNG herschrijven zet die A-waarden recht in het eigen transparantiekanaal van de PNG. Er gebeurt geen compositing, er wordt geen achtergrondkleur gelegd en geen voorvermenigvuldiging verschuift stilletjes de pixels. De uitkomst is een lossless overdracht van de alfa, waarbij de dekking van elke pixel in de PNG gelijk is aan wat de WebP vasthield. Bij beelden met fijne randverzachting komt elke tussenwaarde heel door de reis, zeg een pixel op 40 procent dekking langs de rand van een letter. Die getrouwheid kantelt de keuze naar PNG boven JPG zodra de ontvangende app het beeld tegen meer dan één achtergrond moet tonen.
Gedrag van EXIF en metadata
Het herschrijven veegt de EXIF-, IPTC- en XMP-velden van de resulterende PNG. Een WebP kan EXIF in een metadatablok bergen, en dat blok verdwijnt zodra de browser het bestand decodeert en herschrijft. Kleurprofielen volgen hun eigen pad. Chrome en Safari houden de sRGB-profieltag op de PNG na het lezen van de WebP, terwijl Firefox alles wegveegt, het ICC-profiel incluis. Dat laat een uitvoer die elke browser als sRGB-veilig leest, maar een wijd-gamut-profiel verstopt in de bron-WebP haalt het niet door Firefox. Leeft je fotopijplijn op ICC-getagde heen- en terugreizen, kies dan een omzetter die bewust met metadata omgaat. Voor gewoon webwerk is het verliezen van die velden meestal welkom en scheelt het bovendien een beetje in de bestandsgrootte.
Privacy in de praktijk verifiëren
Je test de bewering dat geen bestandsdata de browser verlaat met niets meer dan de browser. Open hem, ga naar de webp-to-png-pagina en haal dan de ontwikkelaarstools op met F12 of het rechtermuismenu. Schakel naar het tabblad Netwerk, wis wat er staat en draai een omzetting door een WebP neer te leggen. Filter op Fetch, XHR of All. Niets met beelddata verschijnt tijdens het schrijven. De enige verzoeken op de pagina zijn de aanvankelijke laadobjecten en gewone analyse-pings, die alleen paginaweergaven en Core Web Vitals loggen, nooit je beeld. Elke grote externe omzetter van WebP naar PNG vuurt minstens een upload-POST en een download-GET per taak af, elk naar een serverlog geschreven. Op het apparaat wordt geen van die regels ooit aangemaakt, en dat is het verschil dat telt wanneer het bestand iets privés bevat.
