Note del team su artigianato, formati e le piccole decisioni dietro un buon risultato.
Perché il WebP non è supportato ovunque nei programmi desktop
Il WebP è stato rilasciato da Google nel 2010, ma l'adozione da parte dei programmi desktop è rimasta molto indietro rispetto al supporto dei browser. I browser hanno adottato il WebP presto perché controllano i propri motori di rendering e Google ha ottimizzato attivamente il supporto WebP di Chrome come vantaggio competitivo. Le applicazioni desktop impiegano più tempo ad adottare un nuovo formato immagine perché ognuna mantiene il proprio stack di decodifica, e supportare un formato nuovo richiede di testarlo contro una lunga serie di casi limite. Adobe Photoshop, usato dalla maggioranza dei fotografi e dei designer professionisti, ha aggiunto il supporto nativo al WebP solo con la versione 23.2 alla fine del 2022. Le applicazioni Microsoft Office gestiscono ancora il WebP in modo incoerente tra le piattaforme nel 2026. Il software RIP per la stampa e gran parte dei programmi legacy di archiviazione non hanno mai adottato il WebP. In pratica, un file perfetto nel browser può essere rifiutato dal programma dell'utente. Convertire in PNG è la soluzione affidabile.
Come il WebP ottiene il suo vantaggio di compressione sul PNG
Il PNG usa la compressione DEFLATE, un algoritmo senza perdita di uso generale del 1996. Applica una serie di filtri reversibili sulle righe prima della compressione e codifica il risultato con un flusso zlib. È efficace ma è stato progettato prima che l'apprendimento automatico e la ricerca sui codec video producessero tecniche migliori. La modalità con perdita del WebP usa una trasformazione a blocchi derivata dalla compressione video VP8, applicando previsione intra-fotogramma e una trasformata coseno discreta a unità di macroblocchi 16x16. La modalità senza perdita del WebP usa previsione spaziale, trasformazione del colore e una fase di codifica LZ77 strutturalmente più efficiente del DEFLATE per i contenuti immagine tipici. I dati di Google mostrano il WebP senza perdita circa il 26% più piccolo del PNG su immagini standard. Il WebP con perdita e alfa è circa tre volte più piccolo a qualità visiva comparabile. La direzione da PNG a WebP sfrutta questi guadagni, la direzione da WebP a PNG li annulla, da cui il file in uscita più grande.
Esempi misurati di crescita della dimensione del file
Misurato su Chrome 148, desktop Linux, usando il percorso di scrittura PNG del sistema applicato a input WebP decodificati. Una piccola grafica in stile vettoriale a 400x300 pixel, salvata come WebP a qualità 80, viene decodificata e riscritta come PNG in circa 15-25 ms con una crescita tipica della dimensione del 20-30 percento. Un WebP fotografico a 1024x768, intorno a dimensioni ridotte, viene decodificato e riscritto in PNG in meno di 100 ms con una crescita tipica da 3 a 5 volte. Un WebP fotografico grande a 3840x2160, intorno a dimensioni maggiori, viene scritto in PNG in circa 1,2 secondi con una crescita da 5 a 10 volte a seconda della complessità della scena. Il limite superiore pratico è all'incirca una grande fotografia WebP che diventa un PNG molte volte più pesante. Questi numeri riflettono la differenza di efficienza di compressione tra i due formati e crescono in modo lineare con il numero di pixel.
La trasparenza alfa nel viaggio di andata e ritorno
Il canale di trasparenza a 8 bit in WebP e PNG usa lo stesso intervallo di valori, dove 0 è completamente trasparente e 255 è completamente opaco. Quando il browser decodifica un WebP con alfa, produce un buffer di pixel con valori RGBA dove la componente A riflette i dati alfa originali. Quando quel buffer viene riscritto come PNG, lo scrittore PNG inserisce i valori A direttamente nel canale di trasparenza del PNG. Non avviene alcun passo di composizione, non viene applicato alcun colore di sfondo e nessun effetto di premoltiplicazione altera i valori dei pixel. Il risultato è un trasferimento senza perdita del canale di trasparenza, dove il valore di opacità di ogni pixel nel PNG corrisponde a quello che il WebP aveva memorizzato. Per le immagini con anti-aliasing fine ai bordi, ogni valore alfa intermedio, per esempio un pixel al 40 percento di opacità sul bordo di un testo, sopravvive intatto al viaggio. Questa fedeltà è ciò che rende il PNG la scelta giusta rispetto al JPG quando l'applicazione di destinazione deve mostrare l'immagine su sfondi diversi.
Comportamento di EXIF e metadati
Il percorso di riscrittura toglie i metadati EXIF, IPTC e XMP dal PNG in uscita. I file WebP possono portare dati EXIF incorporati nel loro blocco di metadati, e quei dati vanno persi quando il browser decodifica e riscrive l'immagine. I profili colore ICC seguono un percorso diverso, dove Chrome e Safari conservano l'etichetta del profilo ICC sRGB nel PNG in uscita dopo aver decodificato il WebP, mentre Firefox toglie tutti i metadati incluso il profilo ICC. La conseguenza pratica è un risultato sicuro in sRGB su tutti i browser, ma un eventuale profilo a gamut esteso incorporato nel WebP di partenza non sopravvive in Firefox. Per i flussi di lavoro fotografici professionali che si basano su viaggi con etichetta ICC, usa uno strumento di conversione che gestisce i metadati. Per la normale gestione delle immagini web, la rimozione dei metadati è di solito accettabile e ha il piccolo vantaggio di ridurre leggermente la dimensione del file in uscita.
Verifica della privacy nella pratica
L'affermazione che nessun dato del file lascia il browser si può controllare senza alcuno strumento speciale. Apri il tuo browser, vai alla pagina webp-to-png, poi apri gli strumenti di sviluppo con F12 o con il menu del tasto destro. Passa alla scheda Rete, cancella le richieste esistenti ed esegui una conversione trascinando un file WebP. Filtra l'elenco delle richieste per Fetch, XHR o Tutto. L'elenco mostra zero richieste in uscita con dati immagine durante la scrittura. Le uniche richieste di rete sono le risorse del caricamento iniziale e i normali ping di analisi. Questi registrano solo visualizzazioni di pagina e dati di prestazione, senza contenuto delle immagini. Ogni convertitore WebP in PNG remoto di rilievo genera come minimo una POST di caricamento e una GET di download per conversione, entrambe registrate sul server. L'architettura sul dispositivo fa sì che quelle voci di registro non esistano, il che è la differenza significativa per gli utenti che convertono file con contenuti sensibili.
