Tiimin huomioita tekniikasta, tiedostomuodoista ja niistä pienistä päätöksistä, jotka tekevät hyvän lopputuloksen.
Miksi WebP:tä ei tueta kaikkialla työpöytäsovelluksissa
Google julkaisi WebP:n vuonna 2010, mutta työpöytäohjelmien omaksuminen laahasi kaukana selaintuesta. Selaimet ottivat WebP:n käyttöön varhain, koska ne hallitsevat omia renderöintimoottoreitaan, ja Google optimoi aktiivisesti Chromen WebP-tukea kilpailuetuna. Työpöytäsovellukset omaksuvat uuden kuvamuodon hitaammin, koska jokainen sovellus ylläpitää omaa kuvanpurkupinoaan, ja uuden muodon tukeminen vaatii testaamista pitkää erikoistapausten häntää vastaan. Adobe Photoshop, jota käyttää valtaosa ammattivalokuvaajista ja suunnittelijoista, ei toimittanut sisäänrakennettua WebP-tukea ennen versiota 23.2 vuoden 2022 lopussa. Microsoft Office -sovellukset käsittelevät WebP:tä yhä epäyhtenäisesti eri alustoilla vuonna 2026. Painatuksen RIP-ohjelmistot ja suurin osa vanhoista arkistointityökaluista eivät omaksuneet WebP:tä lainkaan. Käytännön seuraus on, että selaimessa täydellisesti näkyvä tiedosto voi tulla suoraan torjutuksi siltä ohjelmistolta, jota käyttäjä tarvitsee, ja PNG:ksi muuntaminen on luotettava kiertotie.
Miten WebP saavuttaa pakkausetunsa PNG:hen nähden
PNG käyttää DEFLATE-pakkausta, yleiskäyttöistä häviötöntä algoritmia vuodelta 1996. Se soveltaa joukon palautuvia juovasuotimia ennen pakkausta ja koodaa tuloksen zlib-virralla. Tämä on tehokasta, mutta suunniteltu ennen kuin koneoppiminen ja videokoodekkien tutkimus tuottivat parempia tekniikoita. WebP häviöllisessä tilassa käyttää lohkopohjaista muunnosta, joka on johdettu VP8-videopakkauksesta, soveltaen ruudun sisäistä ennustusta ja diskreettiä kosinimuunnosta 16x16-makrolohkoihin. WebP häviöttömässä tilassa käyttää tilaennustusta, värimuunnosta ja LZ77-vaihetta, joka on rakenteellisesti tehokkaampi kuin DEFLATE tyypilliselle kuvasisällölle. Googlen julkaisemat mittaukset osoittavat häviöttömän WebP:n olevan noin 26 prosenttia pienempi kuin PNG vakiotestikuvien joukolla, ja häviöllisen alfalla varustetun WebP:n noin kolme kertaa pienemmän kuin PNG vastaavalla näkyvällä laadulla. Suunta PNG:stä WebP:hen hyödyntää nämä edut, suunta WebP:stä PNG:hen kumoaa ne, mistä suurempi lopputiedosto johtuu.
Mitattuja esimerkkejä tiedostokoon kasvusta
Mitattu Chrome 148:lla, Linux-työpöydällä, alustan PNG-tallennuspolkua puretuille WebP-syötteille soveltaen. Pieni vektorityylinen grafiikka kokoa 400x300 pikseliä, tallennettuna WebP:nä laadulla 80, purkautuu ja tallennetaan uudelleen PNG:ksi noin 15-25 millisekunnissa, ja tiedostokoko kasvaa tyypillisesti 20-30 prosenttia. Valokuvamainen WebP kokoa 1024x768, noin 100-200 kilotavua, purkautuu ja tallennetaan uudelleen PNG:ksi alle 100 millisekunnissa, ja kasvaa tyypillisesti 3-5 kertaiseksi. Suuri valokuvamainen WebP kokoa 3840x2160, noin 1-3 megatavua, tallennetaan PNG:ksi noin 1,2 sekunnissa, ja kasvaa 5-10 kertaiseksi kohteen monimutkaisuuden mukaan. Käytännön yläraja on noin 3 megatavun WebP-valokuva, josta tulee 14 megatavun PNG. Nämä luvut heijastavat kahden muodon pakkaustehokkuuden eroa ja kasvavat lineaarisesti pikselimäärän mukana.
Alfaläpinäkyvyys edestakaisella matkalla
WebP:n ja PNG:n 8-bittinen alfakanava käyttää samaa arvoaluetta, jossa 0 on täysin läpinäkyvä ja 255 on täysin peittävä. Kun selain purkaa alfalla varustetun WebP:n, se tuottaa pikselipuskurin RGBA-arvoilla, joissa A-komponentti heijastaa alkuperäistä alfadataa. Kun tuo puskuri tallennetaan uudelleen PNG:ksi, PNG-tallennus kirjoittaa A-arvot suoraan PNG:n alfakanavaan. Mitään yhdistämistä ei tapahdu, mitään taustaväriä ei lisätä, eikä mikään esikertominen muuta pikseliarvoja. Tulos on alfakanavan häviötön siirto, jossa jokaisen pikselin peittävyysarvo PNG:ssä vastaa sitä, minkä WebP tallensi. Kuville, joissa on hienoa reunansilotusta reunoilla, jokainen väliarvo, esimerkiksi 40 prosentin peittävyydellä oleva pikseli tekstin reunalla, säilyy matkan läpi vahingoittumattomana. Tämä uskollisuus tekee PNG:stä oikean valinnan JPG:n sijaan, kun vastaanottava sovellus näyttää kuvan useita taustoja vasten.
EXIF- ja metatietojen käyttäytyminen
Muunnoksen kulku poistaa EXIF:n, IPTC:n ja XMP:n PNG-tuloksesta. WebP-tiedostot voivat kantaa metatietolohkoonsa upotettua EXIF-dataa, ja tuo data menetetään, kun selain purkaa ja tallentaa kuvan uudelleen. ICC-väriprofiilit seuraavat eri polkua, jossa Chrome ja Safari säilyttävät sRGB ICC -profiilimerkin PNG-tuloksessa WebP:n purun jälkeen, kun taas Firefox poistaa kaikki metatiedot ICC-profiili mukaan lukien. Käytännön seuraus on sRGB-turvallinen tulos kaikissa selaimissa, mutta lähteenä olevaan WebP:hen upotettu laajan väriavaruuden profiili ei säily Firefoxissa. Ammattimaisille valokuvatyönkuluille, jotka nojaavat ICC-merkittyihin edestakaisiin matkoihin, käytä metatiedot huomioivaa muunnostyökalua. Tavallisessa verkkokuvien käsittelyssä metatietojen poisto on yleensä hyväksyttävää ja kutistaa lopputiedostoa hieman.
Yksityisyyden varmistus käytännössä
Väitteen siitä, ettei tiedoston dataa poistu selaimesta, voi tarkistaa ilman mitään erikoistyökaluja. Avaa selaimesi, siirry webp-to-png-sivulle ja avaa sitten kehittäjätyökalut F12:lla tai hiiren oikean napin valikolla. Vaihda Verkko-välilehteen, tyhjennä olemassa olevat pyynnöt ja suorita muunnos pudottamalla WebP-tiedosto. Suodata luettelo Fetchillä, XHR:llä tai Kaikilla. Luettelo näyttää nolla lähtevää pyyntöä, jotka kantaisivat kuvadataa tallennuksen aikana. Ainoat läsnä olevat verkkopyynnöt ovat sivun ensimmäiset latausresurssit ja tavanomaiset analytiikan pingit, jotka kirjaavat vain sivunäytöt ja Core Web Vitals -suorituskykytiedot, ilman kuvasisältöä. Jokainen suuri WebP:stä PNG:hen-palvelu verkossa luo vähintään lähetys-POSTin ja lataus-GETin muunnosta kohden, molemmat kirjattuna palvelimelle. Laitteella tapahtuva arkkitehtuuri tarkoittaa, ettei noita lokimerkintöjä ole, mikä on merkityksellinen ero käyttäjille, jotka muuntavat arkaluonteista sisältöä kantavia tiedostoja.
