Notater fra teamet om håndverket, formater og de små valgene bak et godt resultat.
Hvorfor WebP ikke støttes overalt i skrivebordsapper
WebP ble sluppet av Google i 2010, men skrivebordsprogramvarens oppslutning lå langt etter nettleserstøtten. Nettlesere tok WebP i bruk tidlig fordi de styrer sine egne gjengivelsesmotorer, og Google optimaliserte aktivt Chromes WebP-støtte som et konkurransefortrinn. Skrivebordsprogrammer bruker lengre tid på å ta i bruk et nytt bildeformat fordi hvert program vedlikeholder sin egen bildedekoding, og å støtte et nytt format krever testing mot en lang hale av kanttilfeller. Adobe Photoshop, brukt av flertallet av profesjonelle fotografer og designere, fikk ikke innebygd WebP-støtte før versjon 23.2 sent i 2022. Microsoft Office-programmer håndterer fortsatt WebP ujevnt på tvers av plattformer per 2026. Trykk-RIP-programvare og de fleste eldre arkiveringsverktøy tok aldri i bruk WebP i det hele tatt. Den praktiske følgen er at en fil som vises perfekt i en nettleser kan bli helt avvist av programvaren brukeren trenger, og å gjøre om til PNG er den pålitelige løsningen.
Hvordan WebP oppnår sitt komprimeringsfortrinn over PNG
PNG bruker DEFLATE-komprimering, en generell tapsfri algoritme fra 1996. Den bruker et sett reversible skannelinjefiltre før komprimeringen og lagrer resultatet med en zlib-strøm. Dette er effektivt, men utformet før maskinlæring og videokodek-forskning ga bedre teknikker. WebP i tapsbasert modus bruker en blokkbasert transformasjon hentet fra VP8-videokomprimering, og anvender intrarammeforutsigelse og en diskret cosinustransformasjon på makroblokker på 16x16. WebP i tapsfri modus bruker romlig forutsigelse, fargetransformasjon og et LZ77-trinn som er strukturelt mer effektivt enn DEFLATE for typisk bildeinnhold. Googles publiserte målinger viser tapsfri WebP omtrent 26 prosent mindre enn PNG på et sett standard testbilder, og tapsbasert WebP med alfa omtrent tre ganger mindre enn PNG ved tilsvarende synlig kvalitet. Retningen PNG til WebP utnytter disse gevinstene, retningen WebP til PNG reverserer dem, derav den større utgangen.
Målte eksempler på filstørrelsesvekst
Målt på Chrome 148, Linux-skrivebord, ved hjelp av plattformens PNG-lagringsvei anvendt på dekodede WebP-filer. En liten grafikk i vektorstil på 400x300 piksler, lagret som WebP ved kvalitet 80, dekodes og lagres på nytt som PNG på omtrent 15 til 25 ms med en typisk vekst på 20 til 30 prosent. En fotografisk WebP på 1024x768, rundt liten størrelse, dekodes og lagres på nytt til PNG på under 100 ms med en typisk vekst på 3 til 5 ganger. En stor fotografisk WebP på 3840x2160, rundt større størrelse, lagres til PNG på omtrent 1,2 sekunder med en vekst på 5 til 10 ganger avhengig av motivets kompleksitet. Den praktiske øvre grensen er omtrent et stort WebP-bilde som blir en PNG mange ganger større. Disse tallene gjenspeiler forskjellen i komprimeringseffektivitet mellom de to formatene og vokser lineært med antall piksler.
Alfagjennomsiktighet i rundturen
Den 8-bits alfakanalen i WebP og PNG bruker samme verdiområde, der 0 er helt gjennomsiktig og 255 er helt ugjennomsiktig. Når nettleseren dekoder en WebP med alfa, lager den en pikselbuffer med RGBA-verdier der A-komponenten gjenspeiler de opprinnelige alfadataene. Når den bufferen lagres på nytt som PNG, skriver PNG-lagringen A-verdiene rett inn i PNG-ens alfakanal. Ingen sammensetting skjer, ingen bakgrunnsfarge legges på, og ingen forhåndsmultiplisering endrer pikselverdiene. Resultatet er en tapsfri overføring av alfakanalen, der hver piksels tetthetsverdi i PNG-en stemmer med det WebP-en lagret. For bilder med fin kantutjevning langs kantene overlever hver mellomliggende alfaverdi, for eksempel en piksel på 40 prosent tetthet ved en tekstkant, rundturen uskadd. Denne troskapen er det som gjør PNG til det rette valget framfor JPG når mottakerprogrammet skal vise bildet mot flere bakgrunner.
EXIF- og metadataoppførsel
Omgjøringsprosessen stripper EXIF, IPTC og XMP fra PNG-utgangen. WebP-filer kan bære EXIF-data lagt i metadatablokken, og de dataene går tapt når nettleseren dekoder og lagrer bildet på nytt. ICC-fargeprofiler følger en annen vei, der Chrome og Safari beholder sRGB ICC-profilmerket i PNG-utgangen etter å ha dekodet WebP, mens Firefox stripper all metadata, ICC-profilen inkludert. Den praktiske følgen er sRGB-trygg utgang i alle nettlesere, men en vidgamut-profil lagt i WebP-kilden overlever ikke i Firefox. For profesjonelle fotoflyter som hviler på ICC-merkede rundturer, bruk et omgjøringsverktøy som tar vare på metadata. For vanlig bildehåndtering på nett er fjerning av metadata vanligvis akseptabelt og har den lille fordelen at det krymper utgangsfilen litt.
Personvernsjekk i praksis
Påstanden om at ingen fildata forlater nettleseren kan sjekkes uten noe spesialverktøy. Åpne nettleseren, gå til webp-til-png-siden, og åpne så utviklerverktøyene med F12 eller høyreklikkmenyen. Bytt til Nettverk-fanen, tøm eventuelle forespørsler, og kjør en omgjøring ved å slippe en WebP-fil. Filtrer listen på Fetch, XHR eller Alle. Listen viser null utgående forespørsler som bærer bildedata under lagringen. De eneste nettverksforespørslene som finnes er de første sideinnlastingsressursene og vanlige analysepinger, som bare registrerer sidevisninger og ytelsesdata for Core Web Vitals, uten bildeinnhold. Alle store WebP-til-PNG-tjenester på nett genererer minst en opplastings-POST og en nedlastings-GET per omgjøring, begge logget på tjeneren. Arkitekturen på enheten gjør at de loggoppføringene ikke finnes, noe som er den meningsfulle forskjellen for brukere som gjør om filer med følsomt innhold.
