JPEG, PNG, WebP o AVIF: quale formato e perché

Due domande, e il formato ne discende

Domanda uno: l'immagine è fotografica o a tinte piatte? Fotografica significa tono continuo — pelle, cielo, fogliame, rumore del sensore, nessuna zona in cui il valore salti da un pixel al successivo. A tinte piatte significa l'opposto: screenshot, loghi, grafici, schemi, tratto, testo, tutto ciò che ha grandi aree uniformi e bordi netti fra loro. Non è un'etichetta stilistica. È una descrizione statistica dei pixel, e le due famiglie di compressione sono state costruite per statistiche opposte.

Domanda due: all'immagine serve un canale alfa o l'animazione? Il JPEG non ha né l'uno né l'altra e non li avrà mai. Il PNG ha l'alfa e anima solo tramite APNG, un'estensione assente dalla specifica originale. WebP e AVIF hanno entrambi l'alfa ed entrambi animano. Se un logo deve stare su uno sfondo ignoto, il JPEG è fuori prima ancora di parlare di dimensioni: un logo JPEG arriva con un rettangolo di sfondo incorporato.

Che cosa fanno davvero DCT e DEFLATE ai pixel

Il JPEG taglia l'immagine in blocchi 8 × 8 e riscrive ogni blocco come somma di onde coseno, poi divide quei coefficienti per una tabella di quantizzazione e arrotonda. Il dettaglio fine vive nei coefficienti ad alta frequenza, proprio quelli che la tabella divide più forte: si arrotondano a zero e spariscono. Una foto lo tollera perché le sue alte frequenze sono in gran parte rumore. Un bordo netto no: un gradino brusco richiede molti termini ad alta frequenza, e cancellandoli la ricostruzione sovraelonga e sottoelonga ai due lati del bordo. È il ringing, ed è perché il testo in un JPEG appare sfocato ai bordi anche in alta qualità.

L'effetto è misurabile ed è strettamente locale ai bordi. Nella nostra immagine di test piatta abbiamo preso una fascia larga 1040 pixel e alta 70 attorno al titolo. Nell'originale, 56 119 pixel di quella fascia valgono esattamente 255,255,255. Dopo un solo passaggio JPEG in qualità 75, 6 352 di essi — l'11,3 % — non sono più bianco puro, con scarti fino a 14 livelli. In una fascia bianca vuota di 86 400 pixel lontana da ogni bordo, non è cambiato un solo pixel. Il JPEG non degrada l'immagine in modo uniforme: la degrada esattamente dove vive il disegno a tinte piatte.

Il PNG lavora al contrario. Prevede ogni pixel dai suoi vicini, sottrae la previsione e passa i residui a DEFLATE — lo stesso algoritmo di un file zip. Una sequenza di pixel identici si comprime quasi a nulla, ed è perché uno screenshot si riduce così bene. Una foto non ha sequenze: ogni pixel differisce leggermente dal vicino, i residui sono rumore e DEFLATE non ha presa. È tutta la spiegazione dei 2 021 576 byte richiesti dalla nostra foto in PNG contro 311 380 in JPEG.

Le stesse due immagini, quattro encoder, misurati

Sulla foto la classifica è quella che tutti si aspettano. PNG 2 021 576 byte, JPEG in qualità 75 311 380, AVIF alla qualità 75 dell'encoder 174 774, WebP con perdita in qualità 75 105 608. Ma leggi quell'ultima coppia con attenzione prima di concludere: la qualità 75 di un codec non è la qualità 75 di un altro. Quel numero è un indice nel quantizzatore proprio di quell'encoder, niente di più. Quei valori dicono solo che i due encoder, a impostazioni nominalmente identiche, sono finiti su punti diversi della curva dimensione-qualità — non che WebP batta AVIF. Un confronto onesto fra due codec fissa prima una metrica di qualità e poi confronta i byte, ed è un esercizio molto più lungo di quello di questa pagina.

Lo screenshot piatto è dove avviene il ribaltamento interessante. PNG 88 693 byte. JPEG con la stessa qualità 75: 152 065 byte — 1,71 volte il PNG, e per giunta buttando via pixel. WebP con perdita: 40 060 byte. WebP senza perdita: 36 074 byte, insieme più piccolo della versione con perdita ed esatto al pixel. Non è un'anomalia. Il WebP con perdita sottocampiona sempre la crominanza a 4:2:0: testo colorato e filetti sottili colorati perdono metà della risoluzione cromatica orizzontale e verticale, e l'encoder spende poi bit per ricostruire bordi che ha appena sfocato lui stesso. Sul disegno a tinte piatte, il senza perdita è spesso insieme più piccolo e migliore.

La porta a senso unico — e il mito del risalvataggio

La perdita è davvero a senso unico. Abbiamo convertito il nostro master PNG in JPEG qualità 75 e di nuovo in PNG: il PNG di ritorno pesa 1 470 130 byte, contro 2 021 576 dell'originale. È più piccolo perché il passaggio JPEG ha levigato via dettaglio dall'immagine, e nessun encoder PNG può rimetterlo. Da quel momento il file è senza perdita, ma conserva senza perdita un'immagine danneggiata. PNG → JPEG → PNG non restituisce mai l'originale, e la dimensione minore è la prova, non un premio.

La versione popolare — che ogni singolo risalvataggio aggravi il danno — risulta falsa così come di solito viene enunciata, e l'abbiamo misurata. Ricodificare dieci volte lo stesso JPEG con l'identica impostazione di qualità, senza ritaglio, senza ridimensionamento e senza ritocco fra i passaggi, ha spostato l'errore assoluto medio da 1,7591 a 1,7670 livelli. È una deriva di otto millesimi di livello su dieci generazioni: la riquantizzazione JPEG è vicina a un punto fisso finché la griglia 8 × 8 resta allineata e la tabella di quantizzazione non cambia.

Cambia qualcosa fra un salvataggio e l'altro e l'accumulo è immediato. Abbiamo ripetuto la catena con un piccolo ritaglio centrato prima di ogni salvataggio, che sposta l'immagine rispetto alla griglia 8 × 8. Dopo sei cicli l'errore assoluto medio rispetto a una codifica in un solo passaggio dello stesso ritaglio era salito da 1,76 a 2,32 livelli — 32 % di errore in più — mentre codificare quello stesso ritaglio una sola volta dal master intatto restava piatto attorno a 1,77 in qualunque ciclo confrontato. La regola pratica non è quindi «non risalvare mai»: conserva il master senza perdita, modifica sempre a partire da esso ed esporta in JPEG o WebP come ultimo passo, non come file di lavoro.

Alfa, profondità di bit e i limiti che nessuno cita

Il PNG memorizza fino a 16 bit per canale; il JPEG, come lo implementano i browser, 8. Il WebP è a 8 bit in entrambe le modalità, e la sua modalità con perdita è sempre 4:2:0. L'AVIF arriva a 10 e 12 bit e può codificare in 4:4:4, ed è per questo l'unico dei quattro a gestire un ampio gradiente morbido senza banding, e l'unico con una risposta vera per l'HDR. Se la tua immagine è un cielo al tramonto o uno sfondo prodotto tutto morbido, quella profondità vale più di qualsiasi conteggio di byte della tabella sopra.

Il WebP porta un tetto rigido che sorprende la prima volta: il contenitore codifica larghezza e altezza in 14 bit, quindi nessun WebP può superare 16 383 pixel per lato. Irrilevante per una foto web, fatale per una mappa scansionata o un lungo panorama cucito. AVIF e PNG non hanno un limite comparabile alle dimensioni che produrrai. Conviene saperlo prima di costruire una pipeline che converta tutto in WebP per impostazione predefinita.

Supporto e costo di codifica, e la regola che ne esce

Il supporto non è più il fattore decisivo di cinque anni fa. Il WebP è arrivato in Chrome da tempo, in Firefox 65 a gennaio 2019 e in Safari 14 a settembre 2020. L'AVIF è arrivato in Chrome 85 ad agosto 2020, Firefox 93 a ottobre 2021, Safari 16 a settembre 2022 e infine Edge 121 a gennaio 2024 — Edge è stato l'ultimo grande browser. Ogni versione attuale di ogni browser principale decodifica entrambi. Resta una coda lunga di sistemi vecchi che non possono più aggiornare il browser: è esattamente a questo che serve l'elemento picture con più sorgenti e un ripiego JPEG.

Il vincolo vivo è invece il costo di codifica. Sulla stessa macchina e la stessa foto 1600 × 900, migliore di cinque esecuzioni: WebP 287 ms, AVIF 1 163 ms, JPEG 119 ms. L'AVIF ha impiegato quattro volte il WebP, e quasi dieci volte il JPEG prodotto dallo stesso strumento. Sono coinvolti encoder diversi — cwebp per WebP, il framework immagini di sistema per AVIF e JPEG — quindi tratta il rapporto esatto come indicativo, non universale. La direzione però non è in dubbio: l'AVIF è codifica intra AV1, esplora uno spazio molto più ampio ed è lento per costruzione. Su un lotto di centomila immagini è una voce di budget reale, ed è il motivo per cui molte squadre si fermano al WebP.

La regola che ne discende sta in tre righe. Foto senza trasparenza: WebP o AVIF, con il JPEG dietro per i client vecchi. Screenshot, logo, grafico, qualsiasi cosa a tinte piatte: prima WebP senza perdita, PNG come ripiego sicuro, e mai JPEG. Tutto ciò che richiede alfa o animazione: WebP o AVIF, oppure PNG se la palette è piccola e il senza perdita conta più dei byte.

Domande frequenti

Il WebP è sempre più piccolo del JPEG?

No. Di solito lo è sulle foto, e sulla nostra era il 66 % più piccolo a impostazione nominalmente uguale — ma quelle impostazioni non sono confrontabili fra codec, e un JPEG già molto compresso può crescere passando a WebP, perché l'encoder deve ora riprodurre i blocchi del JPEG come se fossero dettaglio. Misura sempre sulle tue immagini invece di fidarti di una percentuale da titolo.

Convertire un vecchio JPEG in WebP o AVIF ripristina la qualità?

Non può. Il dettaglio scartato dal JPEG non è nel file, quindi nulla a valle può recuperarlo. Convertire conviene comunque per risparmiare banda, e un buon encoder non aggiungerà molti danni nuovi, ma il tetto è fissato dal JPEG di partenza. Se il raw o il PNG originale esiste ancora, riesporta da quello: non costa nulla in più e il risultato è davvero migliore.

Devo ancora pubblicare JPEG?

Come ripiego dentro un elemento picture, sì: costa un file in più e copre qualsiasi dispositivo mai costruito. Come formato principale per lavoro nuovo, non c'è più un caso fotografico in cui il JPEG vinca in dimensione a parità di qualità, né un caso a tinte piatte in cui vinca affatto. Resta anche la cosa più sicura da consegnare a chi lo aprirà con software ignoto, ed è perché allegati e-mail e tipografie ci ricadono ancora.

PNG-8 o PNG-24 per un logo?

Il PNG-8 memorizza una palette indicizzata di al più 256 colori ed è nettamente più piccolo quando il disegno ha davvero pochi colori — la maggior parte dei loghi piatti. Il PNG-24 memorizza il colore pieno e serve solo per gradienti o ombre morbide. Verifica il risultato invece dell'etichetta: se la versione a palette è visivamente identica, tienila. E confronta entrambe col WebP senza perdita, che ha battuto il PNG del 59 % sulla nostra immagine piatta di test.

L'AVIF vale il tempo di codifica in più?

Dipende interamente da quante volte ogni file viene codificato rispetto a quante viene servito. Un'immagine di apertura codificata una volta e consegnata un milione di volte: codificala in AVIF e accetta il secondo in più. Contenuti caricati dagli utenti e codificati al volo: quattro volte la CPU per immagine è un costo operativo serio, e il WebP è la scelta pragmatica. L'AVIF si guadagna il posto anche sui gradienti ampi e morbidi, dove le sue modalità a 10 e 12 bit evitano il banding che i formati a 8 bit non possono evitare.

Perché il WebP senza perdita ha battuto quello con perdita sullo screenshot?

Perché la codifica con perdita è lo strumento sbagliato per quei dati. Lo screenshot è fatto soprattutto di lunghe sequenze di pixel identici, che la modalità senza perdita codifica quasi gratis, mentre quella con perdita prima sottocampiona il colore e poi spende bit a descrivere i bordi che ha sfocato. Abbiamo misurato 36 074 byte senza perdita contro 40 060 con perdita — più piccolo ed esatto al pixel. Se la tua immagine è a tinte piatte, prova il senza perdita prima di toccare il cursore della qualità.