Con perdita vs senza perdita: perché i formati di immagine dimenticano di proposito

Prendi la stessa foto da 12 MP (4000 x 3000 pixel) e salvala due volte: una volta in PNG (24 MB), una volta in JPEG a qualità 90 (3,4 MB). Affiancale sullo schermo e non le distingui. Ingrandisci al 400% e le differenze cominciano a vedersi: un leggero ammorbidimento su capelli ed erba, aloni tenui lungo i contorni più marcati.

Due file, un'immagine sola, e uno pesa sette volte l'altro. Nessuno dei due è difettoso: hanno semplicemente fatto scelte diverse. PNG ha scelto di conservare ogni bit, JPEG di conservare tutto quello che avresti notato. Quasi tutto quello che c'è da sapere sui formati di immagine discende da questa scelta di fondo.

Perché la compressione si è divisa in due schieramenti

Nel 1948 Claude Shannon pubblicò "A Mathematical Theory of Communication" e fissò per la compressione un limite teorico invalicabile. Il suo teorema della codifica di sorgente dice che non è possibile rappresentare dei dati senza perdita al di sotto della loro entropia, cioè il contenuto medio di informazione per simbolo. Un'immagine perfettamente casuale non si comprime per niente; un'immagine tutta bianca si riduce quasi a zero. Ogni immagine reale si colloca da qualche parte lungo questa scala, e nessun algoritmo senza perdita può scendere sotto quel limite.

La compressione con perdita esiste grazie a una scappatoia: il limite dell'entropia vale per i dati che hai, non per quelli che conservi. Se prima sostituisci l'immagine con una versione leggermente diversa, a entropia più bassa, il limite si abbassa insieme a lei. Il trucco è tutto qui: prima cambi i dati, poi li impacchetti. Il vero problema di progettazione è decidere quali cambiamenti sono accettabili.

La risposta dipende da due cose: dal contenuto e da chi lo consuma. Per il contenuto, uno screenshot di un pannello di impostazioni è fatto soprattutto di colore uniforme e forme ripetute, quindi bassa entropia, facile da prevedere; una foto di un bosco, a livello di pixel, è shot noise dei fotoni e rumore di lettura del sensore, quindi alta entropia, impossibile da prevedere. Per il consumatore, un programma che legge il file ha bisogno dei bit esatti, mentre un essere umano che lo guarda tollera gli errori per costituzione: ha un'acutezza spaziale limitata per il colore, nota poco le texture fini ad alta frequenza e percepisce la luminosità in rapporti anziché in valori assoluti (è la legge di Weber: si distinguono gradini di luminanza dell'1-2% circa).

Da qui la divisione. Se il contenuto è prevedibile e chi lo consuma è una macchina, o una persona che ingrandisce ogni pixel, la scelta è il senza perdita. Se il contenuto è rumoroso e chi lo guarda è una persona a un braccio di distanza dallo schermo, puoi permetterti di dimenticare qualcosa.

Come funziona la compressione con perdita

Si dice spesso che i codec con perdita "buttano via dati": vero, ma impreciso. Buttano via dati ben precisi, scelti in base a un modello della visione umana. Ecco la pipeline:

1. Conversione da RGB a uno spazio colore luma-croma (YCbCr per JPEG, schemi analoghi negli altri codec). L'occhio distingue i dettagli di luminanza molto meglio di quelli di colore, quindi i canali croma si memorizzano a un quarto della risoluzione (sottocampionamento 4:2:0). Questo solo passaggio riduce i dati grezzi di circa il 50% e nella maggior parte delle foto non si nota.

2. Trasformazione di ogni blocco in frequenze. JPEG usa la trasformata discreta del coseno su blocchi di 8 x 8, JPEG 2000 usa le wavelet, AV1 e HEVC trasformate più grandi e di dimensione variabile. Il risultato ha sempre la stessa forma: pochi coefficienti grandi per le forme ampie e tanti coefficienti piccoli per le texture fini.

3. Quantizzazione. Ogni coefficiente viene diviso per un passo e arrotondato all'intero, e i coefficienti piccoli diventano zero. È l'unico passaggio con perdita di tutta la pipeline: il parametro di qualità dell'encoder non è altro che un moltiplicatore applicato a quei passi. Qualità 95 usa passi piccoli e conserva quasi tutto; qualità 30 usa passi grandi e azzera gran parte delle texture fini.

4. Codifica entropica di quello che sopravvive. Scansione a zig-zag, codifica run-length, Huffman o codifica aritmetica. Questo stadio è senza perdita: si limita a impacchettare i numeri già quantizzati.

Rileggi la lista. I passaggi 1, 2 e 4 si limitano a riorganizzare i dati e sono tutti reversibili. Il passaggio 3 è quello che distrugge davvero l'immagine: di proposito, un arrotondamento alla volta.

E il danno si riconosce. Se spingi la qualità troppo in basso compaiono il blocking (la griglia di blocchi 8 x 8 che si vede nei cieli e sui muri), il ringing (aloni intorno al testo e ai bordi ad alto contrasto) e il banding (le sfumature continue che si spezzano in gradini). Se risalvi un file con perdita, la pipeline riparte su dati già danneggiati, ed è per questo che la perdita di generazione (generation loss) si accumula: al decimo salvataggio, un JPEG sembra l'acquerello di se stesso.

Come funziona la compressione senza perdita

I codec senza perdita non si prendono libertà di questo tipo: il file decodificato deve coincidere con l'originale bit per bit, quindi l'unica cosa che possono fare è modellare i dati e impacchettarli. La ricetta standard prevede due stadi.

Primo stadio: decorrelazione. PNG filtra ogni riga di pixel prima di comprimerla. Per ciascuna riga l'encoder sceglie uno dei cinque predittori (None, Sub, Up, Average, Paeth) e memorizza la differenza tra il pixel reale e il valore previsto. Una riga tutta bianca diventa un singolo pixel bianco seguito da migliaia di zeri; una sfumatura regolare diventa una serie di residui piccoli che variano dolcemente. In entrambi i casi i numeri si fanno piccoli e si addensano intorno allo zero, che è esattamente quello che serve allo stadio successivo.

Secondo stadio: codifica entropica. PNG usa DEFLATE, lo stesso algoritmo di gzip e zip, costruito su due idee degli anni '70. LZ77 cerca le sequenze di byte che si ripetono e sostituisce ogni ripetizione con un puntatore (distanza, lunghezza) ai 32 KB di dati precedenti; la codifica di Huffman assegna poi codici brevi ai valori frequenti e codici lunghi a quelli rari. Nessuno dei due passaggi perde nulla: dal flusso compresso si può sempre risalire ai byte originali.

È per questo che PNG è formidabile con gli screenshot e disarmato con le foto. La grafica delle interfacce è ripetitiva per natura: righe identiche, icone che tornano, lunghe campiture di colore uniforme. LZ77 trova corrispondenze ovunque e i filtri riducono quello che resta a residui quasi nulli. Una fotografia non ripete niente: lo shot noise rende ogni pixel leggermente diverso dai vicini, i predittori sbagliano, i residui restano grandi e casuali e LZ77 non trova nulla a cui puntare. Su una foto da 12 MP, PNG arriva in genere a un rapporto tra 1,3:1 e 1,6:1 rispetto ai pixel grezzi. JPEG, a parità di qualità percepita, arriva a 10:1.

Il prezzo da pagare sono file più grandi, ma in cambio c'è una garanzia assoluta: decodifichi un PNG, calcoli l'hash dei pixel e quell'hash coincide con la sorgente, ogni volta. Per gli screenshot che finiranno in un OCR, per le scansioni che verranno rielaborate, per le immagini mediche e scientifiche che possono finire in una pubblicazione o in un tribunale, quella garanzia è il motivo stesso per cui il formato esiste.

Perché JPEG scommise sul con perdita nel 1992

Il Joint Photographic Experts Group iniziò i lavori nel 1986, e i vincoli di quell'epoca spiegano ogni sua decisione. Un hard disk da 20 MB costava centinaia di dollari. Il floppy da 1,44 MB era il modo normale di spostare i file. I modem viaggiavano a 14,4 kbps, quando andava bene: scaricare una singola foto VGA non compressa da 921 KB richiedeva circa nove minuti. La stessa foto compressa 10:1 con perdita arrivava in meno di un minuto; una versione senza perdita a 2:1 ne chiedeva comunque più di quattro.

I test condotti dal comitato dicevano del resto la stessa cosa: con il senza perdita non si sarebbe andati lontano. Il contenuto fotografico, l'obiettivo dichiarato del gruppo ("immagini a tono continuo"), non contiene abbastanza ridondanza. Visti i numeri, decisero di lavorare sull'unico margine rimasto: chi guarda.

Quello che si sa meno è che lo standard pubblicato nel 1992 (ISO/IEC 10918-1) prevede anche una modalità senza perdita: salta del tutto la DCT, calcola ogni pixel a partire da un massimo di tre pixel adiacenti usando uno dei sette predittori fissi e applica la codifica entropica ai residui. Concettualmente è lo stesso trucco che PNG avrebbe adottato tre anni dopo. Non la implementò quasi nessuno: la ignorarono i decoder, la ignorarono gli encoder, e quando l'imaging medico ebbe bisogno per davvero di un JPEG senza perdita, ricevette uno standard a parte (JPEG-LS, ISO/IEC 14495, 1999).

Il comitato dovette anche fare i conti con i brevetti. La codifica aritmetica prevista da JPEG era coperta dai brevetti Q-coder di IBM, così il profilo baseline, quello royalty-free, ripiegò sulla codifica di Huffman, e quasi nessuna implementazione usò mai il ramo aritmetico. La paura dei brevetti che condiziona la progettazione dei codec non era una novità del 1992. E stava per peggiorare parecchio.

In fondo JPEG fu una scommessa psicovisiva: l'ultimo 5x di compressione non è matematica, è biologia.

Perché PNG scommise sul senza perdita nel 1995

PNG non nacque come un progetto di ingegneria. Nacque come un'emergenza legale.

Nel dicembre 1994 Unisys annunciò che avrebbe fatto pagare una licenza per il software che usava GIF: la compressione di GIF si basava sull'algoritmo LZW, coperto da un brevetto del 1985 che Unisys aveva ereditato. CompuServe, che aveva creato GIF, trovò un accordo e girò il costo sugli sviluppatori. Le comunità grafiche di Usenet andarono su tutte le furie: GIF era gratis da sette anni e tutte le immagini e gli strumenti della prima web si erano ritrovati di colpo su terreno brevettato.

Nel giro di poche settimane, ai primi di gennaio 1995, Thomas Boutell pubblicò la prima bozza di un formato sostitutivo. Un gruppo di volontari lo mise a punto discutendo sulle mailing list per qualche mese. PNG 1.0 arrivò nell'ottobre 1996 come raccomandazione W3C e poi, nel marzo 1997, come RFC 2083.

Su due requisiti non si discusse mai. Ogni algoritmo doveva essere libero da brevetti, il che voleva dire DEFLATE (la combinazione di LZ77 e Huffman del PKZIP di Phil Katz, implementata in zlib da Jean-loup Gailly e Mark Adler). E il formato doveva essere senza perdita, punto e basta. La comunità stava sostituendo GIF: un sostituto che degradava le immagini sarebbe stato morto in partenza, e il vaglio dei brevetti non lasciava comunque spazio ai trucchi percettivi su cui si reggeva JPEG.

Contava anche il contenuto. PNG fu costruito per quello che GIF trasportava davvero: loghi, diagrammi, disegni al tratto, icone, screenshot. Bordi netti e colore uniforme, cioè esattamente il materiale su cui gli artefatti di ringing di JPEG si vedono di più. Rincorrere le fotografie avrebbe voluto dire reinventare la DCT e sfidare un JPEG ormai radicato e royalty-free. PNG scelse la battaglia che poteva vincere e la vinse in pieno: il brevetto di GIF scadde nel 2003 (2004 fuori dagli Stati Uniti), ma a quel punto PNG gli aveva già preso il posto.

Perché il con perdita ha vinto comunque il mercato

A PNG andò la sua nicchia. A JPEG, il mondo.

Il motivo è il volume. Le immagini del web sono in stragrande maggioranza fotografie, e per le fotografie il con perdita non è un compromesso: è lo strumento giusto. Il Web Almanac 2025 colloca JPEG a circa il 57% di tutte le immagini servite, dopo più di trent'anni. Feed social, foto di cronaca, immagini di prodotto, annunci immobiliari: tutto materiale a tono continuo, su cui una codifica con perdita a qualità 75 è indistinguibile dalla sorgente sugli schermi che la gente usa davvero.

L'economia spinge nella stessa direzione. Spazio disco e banda si pagano a byte, e 10:1 contro 2:1 non è un margine: a parità di qualità accettabile, è una differenza di cinque volte nel costo di distribuzione. La velocità di una pagina dipende dalla dimensione dei file, e la dimensione dei file dipende dalla compressione. Ogni fotocamera e ogni telefono salvano per impostazione predefinita in un formato con perdita (JPEG o HEIC). Ogni CMS genera miniature con perdita. Le piattaforme social ricodificano ogni caricamento, in parte per ridurre le dimensioni, in parte per eliminare i metadati ed eventuali sorprese malevole nascoste dentro. Un fotografo può caricare un TIFF impeccabile: quello che la timeline serve è un JPEG a qualità 85.

Il senza perdita non ha tanto perso, quanto piuttosto si è ritirato nei territori dove la sua garanzia conta: screenshot e risorse di interfaccia, dove gli artefatti saltano subito all'occhio e il contenuto si comprime comunque bene; master nelle pipeline di editing, dove ogni generazione con perdita si somma alle precedenti; imaging medico, legale e scientifico, dove "quasi uguale" non è una prova. In quelle nicchie PNG e TIFF non hanno rivali. Ma il traffico è da un'altra parte.

Dove sono arrivati i formati

Spiccano due tendenze. La prima: i codec nuovi non scelgono più una fazione. WebP, HEIC, AVIF e JPEG XL includono entrambe le modalità in un'unica specifica, e JPEG 2000 lo faceva già nel 2000: la domanda non è più "quale formato" ma "quale modalità". La seconda: i casi di confine continuano ad arrivare. JPEG XL può ricomprimere un JPEG esistente senza perdita fino a circa l'80% della dimensione originale, un trucco possibile solo perché i due schieramenti hanno passato trent'anni a imparare l'uno la matematica dell'altro.

Come scegliere nella pratica

L'albero decisionale è breve:

• Pubblichi una foto? Con perdita: JPEG quando conta la compatibilità, WebP o AVIF quando contano le dimensioni.
• Salvi uno screenshot, un logo o qualunque cosa con testo e colore uniforme? Senza perdita: PNG.
• Stai modificando un'immagine? Tieni il master senza perdita, esporta copie con perdita e non risalvare mai un file con perdita nello stesso formato: il danno si accumula a ogni generazione.
• Devi convertire? Adatta il formato di uscita allo scopo, non a quello di partenza. Uno screenshot PNG destinato a una galleria fotografica diventa JPEG o WebP. Un JPEG destinato a un progetto grafico diventa PNG, non perché guadagna qualità (impossibile), ma perché smette di perderne.

È su questo ultimo punto che molti inciampano con le foto dell'iPhone. HEIC è già compressione HEVC con perdita: convertire un HEIC in PNG non ripristina niente, congela lo stato attuale e mette al riparo da ulteriori perdite, il che resta utile se pensi di lavorarci ancora. Per condividere, la strada giusta è convertire direttamente in JPEG. I nostri convertitori da HEIC a JPG, da HEIC a PNG e da HEIC a WebP girano in locale nel tuo browser, quindi il file non lascia mai il tuo dispositivo.

Lo stesso ragionamento vale per tutte le altre conversioni. Portare un JPEG in un flusso di lavoro senza perdita: da JPG a PNG. Alleggerire uno screenshot PNG per il web: da PNG a JPG, oppure da PNG a WebP se vuoi file più piccoli senza rinunciare alla trasparenza. Nel verso opposto, da WebP a PNG e da WebP a JPG restituiscono la compatibilità con il software più vecchio. Se ti ritrovi con scansioni BMP non compresse, da BMP a JPG, da BMP a PNG e da BMP a WebP ti offrono la stessa scelta tra con perdita e senza perdita in un solo passaggio. Anche esportare un documento porta allo stesso bivio: una pagina PDF salvata come immagine diventa da PDF a JPG se è fotografica, da PDF a PNG quando il testo deve restare nitido.

Trent'anni dopo, i formati sopravvissuti sono quelli che hanno capito esattamente cosa i loro utenti potevano permettersi di dimenticare, e cosa no.