Notes de l'equip sobre artesania, formats i les petites decisions darrere d'un bon resultat.
Per què el WebP no té compatibilitat universal a les aplicacions d'escriptori
Google va publicar el WebP el 2010, però l'adopció per part del programari d'escriptori va anar molt endarrere respecte a la compatibilitat dels navegadors. Els navegadors van adoptar el WebP aviat perquè controlen els seus propis motors de renderització i Google va optimitzar activament la compatibilitat de Chrome amb WebP com a avantatge competitiu. Les aplicacions d'escriptori triguen més a adoptar un format d'imatge nou perquè cadascuna manté la seva pila de descodificació i admetre un format nou requereix provar-lo contra una llarga llista de casos límit. L'Adobe Photoshop, que fa servir la majoria de fotògrafs i dissenyadors professionals, no va incorporar compatibilitat nativa amb WebP fins a la versió 23.2 a finals del 2022. Les aplicacions del Microsoft Office encara tracten el WebP de manera desigual segons la plataforma cap al 2026. El programari RIP d'impressió i la majoria d'eines d'arxivament antigues no el van adoptar mai. La conseqüència pràctica és que un fitxer que es mostra perfecte en un navegador pot ser refusat del tot pel programari que l'usuari necessita, i convertir a PNG és la solució fiable.
Com aconsegueix el WebP el seu avantatge de compressió sobre el PNG
El PNG fa servir compressió DEFLATE, un algorisme sense pèrdua d'ús general del 1996. Aplica un conjunt de filtres reversibles per línia d'escaneig abans de comprimir i codifica el resultat amb un flux zlib. És eficaç, però es va dissenyar abans que la recerca en aprenentatge automàtic i còdecs de vídeo donés tècniques millors. El mode amb pèrdua del WebP fa servir una transformació basada en blocs derivada de la compressió de vídeo VP8, aplicant predicció dins del fotograma i una transformada discreta del cosinus a unitats de macrobloc de 16x16. El mode sense pèrdua del WebP fa servir predicció espacial, transformació de color i una etapa de codificació LZ77 estructuralment més eficient que el DEFLATE per al contingut d'imatge típic. Els mesuraments publicats de Google mostren el WebP sense pèrdua al voltant d'un 26 per cent més petit que el PNG en un conjunt d'imatges de prova estàndard, i el WebP amb pèrdua amb alfa unes tres vegades més petit que el PNG amb una qualitat visual comparable. La direcció de PNG a WebP aprofita aquests guanys, la direcció de WebP a PNG els reverteix, d'aquí la sortida més gran.
Exemples mesurats de creixement de la mida del fitxer
Mesurat al Chrome 148, escriptori Linux, fent servir el camí d'escriptura de PNG del sistema aplicat a entrades WebP descodificades. Un gràfic petit d'estil vectorial a 400x300 píxels, desat com a WebP a qualitat 80, es descodifica i es torna a escriure com a PNG en aproximadament 15 a 25 ms amb un creixement típic de la mida d'un 20 a un 30 per cent. Un WebP fotogràfic a 1024x768, al voltant de mida petita, es descodifica i es torna a escriure en PNG en menys de 100 ms amb un creixement típic de 3 a 5 vegades. Un WebP fotogràfic gran a 3840x2160, al voltant d'mida gran, s'escriu en PNG en uns 1,2 segons amb un creixement de 5 a 10 vegades segons la complexitat de l'escena. El límit superior pràctic és aproximadament una fotografia WebP de gran que esdevé un PNG moltes vegades més gran. Aquestes xifres reflecteixen la diferència d'eficiència de compressió entre els dos formats i creixen de manera lineal amb el nombre de píxels.
Transparència alfa en el trajecte d'anada i tornada
El canal de transparència de 8 bits del WebP i el PNG fa servir el mateix rang de valors, on 0 és totalment transparent i 255 totalment opac. Quan el navegador descodifica un WebP amb alfa, produeix una memòria intermèdia de píxels amb valors RGBA on el component A reflecteix les dades alfa originals. Quan aquesta memòria es torna a escriure com a PNG, l'escriptura del PNG posa els valors A directament al canal de transparència del PNG. No hi ha cap pas de composició, no s'aplica cap color de fons i cap efecte secundari de premultiplicació no canvia els valors dels píxels. El resultat és una transferència sense pèrdua del canal de transparència, on el valor d'opacitat de cada píxel al PNG coincideix amb el que el WebP va desar. Per a imatges amb suavitzat fi a les vores, cada valor alfa intermedi, per exemple un píxel al 40 per cent d'opacitat a la vora d'un text, travessa el trajecte intacte. Aquesta fidelitat és el que fa del PNG l'opció adequada davant del JPG quan l'aplicació de destinació ha de mostrar la imatge sobre diversos fons.
Comportament de l'EXIF i les metadades
El procés de reescriptura treu les metadades EXIF, IPTC i XMP del PNG de sortida. Els fitxers WebP poden portar dades EXIF incrustades al seu bloc de metadades, i aquestes dades es perden quan el navegador descodifica i torna a escriure la imatge. Els perfils de color ICC segueixen un camí diferent, on Chrome i Safari conserven l'etiqueta del perfil sRGB ICC al PNG de sortida després de descodificar el WebP, i Firefox treu totes les metadades, inclòs el perfil ICC. La conseqüència pràctica és una sortida segura per a sRGB a tots els navegadors, però qualsevol perfil de gamma àmplia incrustat al WebP d'origen no sobreviu a Firefox. Per a fluxos de treball fotogràfics professionals que depenen de trajectes amb etiqueta ICC, feu servir una eina de conversió que tingui en compte les metadades. Per al tractament habitual d'imatges web, treure les metadades sol ser acceptable i té el petit benefici de reduir una mica la mida del fitxer de sortida.
Verificació de la privadesa a la pràctica
L'afirmació que cap dada del fitxer no surt del navegador es pot comprovar sense cap eina especial. Obriu el navegador, aneu a la pàgina webp-to-png i després obriu les les eines de desenvolupador del navegador amb F12 o el menú del clic dret. Passeu a la pestanya de Xarxa, esborreu les peticions existents i executeu una conversió deixant anar un fitxer WebP. Filtreu la llista de peticions per Fetch, XHR o All. La llista mostra zero peticions de sortida que continguin dades d'imatge durant l'escriptura. Les úniques peticions de xarxa presents són els recursos de la càrrega inicial de la pàgina i els senyals d'analítica habituals, que registren només visites a la pàgina i dades de rendiment de Core Web Vitals, sense cap contingut d'imatge. Tots els convertidors remots importants de WebP a PNG generen com a mínim un POST de pujada i un GET de baixada per conversió, tots dos registrats al servidor. L'arquitectura al dispositiu significa que aquestes entrades de registre no existeixen, que és la diferència significativa per als usuaris que converteixen fitxers amb contingut sensible.