Noter fra teamet om håndværk, formater og de små beslutninger bag et godt resultat.
Hvorfor WebP ikke understøttes alle vegne i programmer på computeren
WebP blev udgivet af Google i 2010, men programmerne på computeren halede langt efter browsernes opbakning. Browsere tog WebP til sig tidligt, fordi de styrer deres egne gengivelsesmotorer, og Google optimerede aktivt Chromes WebP-understøttelse som en konkurrencefordel. Programmer på computeren er længere om at tage et nyt billedformat til sig, fordi hvert program vedligeholder sin egen billedafkodning, og at understøtte et nyt format kræver test mod en lang hale af særtilfælde. Adobe Photoshop, der bruges af hovedparten af professionelle fotografer og designere, fik ikke indbygget WebP-understøttelse før version 23.2 sent i 2022. Microsoft Office-programmer håndterer stadig WebP ujævnt på tværs af platforme i 2026. Tryk-RIP-software og størstedelen af ældre arkiveringsværktøjer tog det aldrig til sig. Den praktiske følge er, at en fil, der vises perfekt i en browser, kan blive blankt afvist af netop det program, brugeren har brug for, og at lave den om til PNG er den pålidelige løsning.
Hvordan WebP opnår sin komprimeringsfordel over PNG
PNG bruger DEFLATE-komprimering, en almen tabsfri algoritme fra 1996. Den anvender et sæt reversible scanlinjefiltre før komprimeringen og koder resultatet med en zlib-strøm. Det er effektivt, men udtænkt før maskinlæring og videokodek-forskning gav bedre teknikker. WebP i tabsgivende tilstand bruger en blokbaseret transformation hentet fra VP8-videokomprimering, og anvender intrarammeforudsigelse samt en diskret cosinustransformation på makroblokke på 16x16. WebP i tabsfri tilstand bruger rumlig forudsigelse, farvetransformation og et LZ77-trin, der strukturelt er mere effektivt end DEFLATE for typisk billedindhold. Googles offentliggjorte målinger viser tabsfri WebP cirka 26 procent mindre end PNG på et sæt standardtestbilleder, og tabsgivende WebP med alfa cirka tre gange mindre end PNG ved tilsvarende synlig kvalitet. Retningen PNG til WebP udnytter disse gevinster, retningen WebP til PNG vender dem om, deraf den større udgang.
Målte eksempler på vækst i filstørrelse
Målt på Chrome 148, Linux-computer, ved hjælp af platformens PNG-lagringsvej anvendt på afkodede WebP-filer. En lille grafik i vektorstil på 400x300 pixels, gemt som WebP ved kvalitet 80, afkodes og gemmes igen som PNG på cirka 15 til 25 ms med en typisk vækst på 20 til 30 procent. En fotografisk WebP på 1024x768, omkring lille størrelse, afkodes og gemmes igen til PNG på under 100 ms med en typisk vækst på 3 til 5 gange. En stor fotografisk WebP på 3840x2160, omkring større størrelse, gemmes til PNG på cirka 1,2 sekunder med en vækst på 5 til 10 gange afhængigt af motivets kompleksitet. Den praktiske øvre grænse er cirka et stort WebP-billede, der bliver en PNG mange gange større. Disse tal afspejler forskellen i komprimeringseffektivitet mellem de to formater og vokser lineært med antallet af pixels.
Alfagennemsigtighed i rundturen
Den 8-bit alfakanal i WebP og PNG bruger samme værdiområde, hvor 0 er helt gennemsigtig og 255 er helt fast. Når browseren afkoder en WebP med alfa, danner den en pixelbuffer med RGBA-værdier, hvor A-komponenten afspejler de oprindelige alfadata. Når den buffer gemmes igen som PNG, skriver PNG-lagringen A-værdierne direkte ind i PNG-filens alfakanal. Der sker ingen sammensætning, ingen baggrundsfarve lægges på, og ingen formultiplicering ændrer pixelværdierne. Resultatet er en tabsfri overførsel af alfakanalen, hvor hver pixels uigennemsigtighedsværdi i PNG-filen svarer til det, WebP-filen gemte. For billeder med fin kantudjævning langs kanterne overlever hver mellemliggende alfaværdi, for eksempel en pixel på 40 procents uigennemsigtighed ved en tekstkant, rundturen uskadt. Den troskab er det, der gør PNG til det rette valg frem for JPG, når modtagerprogrammet skal vise billedet mod flere baggrunde.
EXIF- og metadataadfærd
Konverteringsforløbet fjerner EXIF, IPTC og XMP fra PNG-udgangen. WebP-filer kan bære EXIF-data lagt i deres metadatablok, og de data går tabt, når browseren afkoder og gemmer billedet igen. ICC-farveprofiler følger en anden vej, hvor Chrome og Safari bevarer sRGB ICC-profilmærket i PNG-udgangen efter at have afkodet WebP, mens Firefox fjerner al metadata, ICC-profilen iberegnet. Den praktiske følge er en sRGB-sikker udgang i alle browsere, men en bredgamut-profil lagt i WebP-kilden overlever ikke i Firefox. For professionelle fotoforløb, der hviler på ICC-mærkede rundture, så brug et konverteringsværktøj, der tager hånd om metadata. For almindelig billedhåndtering på nettet er fjernelsen af metadata normalt acceptabel og har den lille fordel, at den krymper udgangsfilen en smule.
Privatlivskontrol i praksis
Påstanden om, at ingen fildata forlader browseren, kan kontrolleres uden noget specialværktøj. Åbn din browser, gå til webp-til-png-siden, og åbn så udviklerværktøjerne med F12 eller højrekliksmenuen. Skift til Netværk-fanen, ryd eventuelle anmodninger, og kør en konvertering ved at slippe en WebP-fil. Filtrer listen på Fetch, XHR eller Alle. Listen viser nul udgående anmodninger, der bærer billeddata under lagringen. De eneste netværksanmodninger, der findes, er ressourcerne til den første sideindlæsning og almindelige analysepings, der kun registrerer sidevisninger og ydelsesdata for Core Web Vitals, uden billedindhold. Enhver større WebP-til-PNG-tjeneste på nettet genererer mindst en upload-POST og en download-GET per konvertering, begge logget på serveren. Arkitekturen på enheden gør, at de logposter aldrig findes, hvilket er den meningsfulde forskel for brugere, der konverterer filer med følsomt indhold.
