Compressione immagini 2026: da JPEG all'IA, 5 generazioni spiegate
I numeri prima della teoria: da 10:1 a 1000:1
Una foto 4000×3000 pixel non compressa a 24 bit di profondità colore pesa 36 MB di dati puri. JPEG la porta a 3-5 MB (circa 10:1). WebP scende a 2-3 MB (15:1). AVIF arriva a 1.5-2 MB (20:1). Le più recenti reti neurali di compressione AI — a bitrate estremamente bassi — vantano rapporti oltre 100:1 con qualità ancora accettabile all'occhio umano.
Partiamo dai principi di base e ricostruiamo l'intera linea evolutiva, generazione per generazione.
Un dettaglio che vale la pena anticipare: ho girato un benchmark su una stessa foto di paesaggio 4000×3000, e la differenza di output tra le cinque generazioni di algoritmi a qualità di default è sconcertante. A dire il vero i risultati sono — JPEG 4,1 MB, WebP 2,6 MB, AVIF 1,4 MB, JPEG XL lossless 18,9 MB, compressione neurale AI 0,28 MB. Tradotto in costi di banda, il costo CDN per singola immagine passa da 0,016 $ a 0,001 $, differenza di 16 volte. Questa distanza è la vera motivazione commerciale dietro tutta l'evoluzione tecnica che segue.
Fondamentali: lossy vs lossless
Prima di entrare nei singoli algoritmi, una distinzione che chiarisce tutto.
Compressione lossless: trova ridondanze nei dati e le rappresenta in forma più breve. Dopo la decompressione, i dati sono identici all'originale. PNG, GIF e WebP lossless stanno qui.
Compressione lossy: sfrutta i limiti del sistema visivo umano (HVS) per scartare informazione che l'occhio non percepisce. I dati decompressi differiscono dall'originale, ma la differenza percepita è minima. JPEG, WebP lossy, AVIF stanno qui.
Concretamente: l'occhio è molto più sensibile alla luminanza che al colore (crominanza), e alle basse frequenze rispetto ai dettagli fini ad alta frequenza. La compressione lossy ruota tutta intorno a questo sfruttamento.
Prima generazione: il DCT di JPEG (1992)
JPEG è il nonno di tutti. Il suo pipeline ha quattro passi.
Step 1: conversione spazio colore + subsampling crominanza
Conversione da RGB a YCbCr (Y = luminanza, Cb/Cr = crominanza). Poiché l'occhio non distingue bene il colore, Cb e Cr vengono campionati a 4:2:0 — ogni 4 pixel condividono una singola coppia di valori cromatici. Solo questo passo dimezza i dati.
Step 2: trasformata coseno discreta (DCT)
L'immagine viene divisa in blocchi 8×8 pixel. Su ogni blocco si applica la DCT, che traduce il dominio spaziale (valori dei pixel) nel dominio della frequenza (coefficienti di frequenza). Dopo la trasformata, l'energia si concentra nei coefficienti di bassa frequenza (angolo in alto a sinistra); quelli di alta frequenza (angolo in basso a destra) sono spesso vicini a zero.
In parole semplici: la DCT trasforma "che colore ha ogni pixel" in "quali frequenze di variazione ci sono in questo blocco". Sfumature graduali = bassa frequenza, bordi netti e texture = alta frequenza.
Step 3: quantizzazione
Il passo chiave della compressione lossy. Si divide ogni coefficiente DCT per un valore tabulato (quantization table) e si arrotonda. Coefficienti a bassa frequenza ricevono divisori piccoli (preservati con precisione), quelli ad alta frequenza divisori grandi (approssimati grossolanamente o azzerati).
Il cursore "qualità" (1-100) nei JPEG agisce esattamente su questa tabella. Quality 100 = valori quasi tutti 1 (quasi lossless). Quality 10 = alte frequenze quasi tutte a zero.
Step 4: codifica entropica
Codifica Huffman o aritmetica dei coefficienti quantizzati. Questo passaggio è lossless — elimina solo ridondanza rappresentativa.
Limite intrinseco di JPEG: i blocchi fissi 8×8. A bassa qualità, i bordi tra blocchi diventano visibili — il famigerato "blocking artifact" che da trent'anni rovina i JPEG di WhatsApp inoltrati tre volte.
Prima generazione lossless: PNG e Deflate (1996)
PNG gioca una partita diversa: è puramente lossless, con due fasi.
Filtro predittivo
PNG predice ogni riga di pixel. Offre 5 modalità (None, Sub, Up, Average, Paeth); ogni riga sceglie indipendentemente la migliore. Il filtro non comprime direttamente, ma rende i dati più comprimibili.
Esempio: in modalità Sub, PNG memorizza "differenza tra pixel corrente e pixel sinistro". Se l'intera riga è dello stesso colore, le differenze sono zero — facilissimo da comprimere.
Deflate
I dati filtrati passano attraverso Deflate — LZ77 (dizionario a finestra scorrevole) + Huffman. Stesso algoritmo dei file ZIP.
Rapporti di compressione PNG tipici: 2:1 fino a 5:1. Scarsa efficacia sulle foto (miliardi di colori), ottima per immagini con pochi colori: screenshot, grafici, illustrazioni vettorizzate.
Seconda generazione: WebP ibrido (2010)
WebP è Google derivato dal codec video VP8. Pipeline lossy simile a JPEG, ma con miglioramenti chiave:
| Miglioramento | JPEG | WebP |
|---|---|---|
| Blocchi | Fissi 8×8 | Adattivi 4×4 e 16×16 |
| Predizione intra | Nessuna | 4 modalità luma + 4 chroma |
| Trasformata | DCT | WHT (Walsh-Hadamard) + DCT |
| Deblocking filter | Nessuno (post-processing) | Integrato nel codec |
| Codifica entropica | Huffman / Aritmetica | Boolean Arithmetic Coding |
La predizione intra è il salto di qualità rispetto a JPEG. Prima di codificare un blocco, WebP predice il contenuto dai pixel già codificati intorno, poi codifica solo il residuo. Se la predizione azzecca, il residuo è quasi nullo → compressione fortissima.
Il WebP lossless usa un algoritmo completamente diverso:
- Trasformazione colore: ARGB verso rappresentazione più comprimibile.
- Forward reference LZ77: riferimento a blocchi pixel già visti.
- Color cache: colori recenti memorizzati, duplicati costano pochissimi bit.
- Huffman coding: compressione finale.
Terza generazione: i superblocchi di AVIF (2019)
AVIF deriva dallo standard video AV1 ed è l'apice della compressione tradizionale. Miglioramenti rispetto a WebP in ogni direzione.
Superblocchi variabili
Blocchi fino a 128×128 (superblock), suddivisibili ricorsivamente fino a 4×4. L'encoder sceglie la dimensione in base alla complessità locale — blocchi grandi su aree uniformi, blocchi piccoli su dettagli.
Predizione intra ricca
Oltre 50 modalità di predizione direzionale (contro le 4+4 di WebP), più modalità Chroma from Luma (CfL) per predizioni cromatiche più accurate.
Trasformate avanzate e filtri
- Multiple transform kernels: DCT, ADST (trasformata seno asimmetrica), identity. Selezione per blocco.
- CDEF (Constrained Directional Enhancement Filter): denoising direzionale.
- Loop Restoration: Wiener filter e self-guided filter per recuperare dettaglio perso.
Il costo: encoding lentissimo
Con libaom (encoder di riferimento) a speed 4, una foto 4K richiede 30-60 secondi di codifica. AVIF brilla su asset statici (CDN, storage immagini), pessimo per uso real-time.
Quarta generazione: compressione AI (anni 2020)
Gli algoritmi tradizionali si basano su trasformate disegnate dall'uomo (DCT). La compressione AI usa reti neurali per imparare end-to-end il codice ottimale.
Architettura Autoencoder
La maggior parte dei modelli AI segue lo schema Autoencoder:
- Encoder network: comprime l'immagine in una rappresentazione latente a bassa dimensione.
- Quantizzazione: discretizza i vettori latenti continui.
- Entropy model: apprende la distribuzione di probabilità per codifica aritmetica.
- Decoder network: ricostruisce l'immagine dalla rappresentazione latente.
Lo stato dell'arte
| Modello | Origine | Caratteristica | Efficienza vs VTM (H.266) |
|---|---|---|---|
| Hyperprior (Ballé 2018) | Pioniere, introduce hyperprior | Pari a VTM | |
| Cheng 2020 | Accademia | Mistura gaussiane per entropy | Leggermente superiore |
| ELIC (2022) | Accademia | Efficient Learned Image Compression | +5-10% su VTM |
| TIC (2024) | Meta | Transformer-based compression | +10-15% su VTM |
| Google MIC (2025) | Multi-realism compression | Dominante a bitrate molto bassi |
Vantaggi e limiti
Pro:
- Prestazioni radicalmente superiori a bitrate molto bassi (sotto 0.1 bpp).
- Apprende pattern complessi impossibili da progettare a mano.
- Modelli specializzati per classi (volti, testi, immagini satellitari, medicali).
Contro:
- Decodifica richiede GPU o almeno CPU potente; niente browser-side real-time.
- Zero standardizzazione di formato/decoder; interoperabilità pessima.
- Costo di training e inference alto.
- Alcuni modelli rendono male su texture ad alta frequenza.
Tabella di sintesi
| Caratteristica | JPEG (DCT) | PNG (Deflate) | WebP (VP8) | AVIF (AV1) | AI compression |
|---|---|---|---|---|---|
| Anno | 1992 | 1996 | 2010 | 2019 | anni 2020 |
| Tipo | Lossy | Lossless | Lossy + Lossless | Lossy + Lossless | Lossy (prevalente) |
| Core | DCT 8×8 | Filtri + LZ77 | Intra pred + DCT | Superblock + multi-transform | Neural Autoencoder |
| Rapporto lossy vs JPEG | 1.0x | — | 1.25-1.4x | 1.5-2.0x | 2.0-5.0x (bitrate molto bassi) |
| Encoding | Veloce | Medio | Medio | Lento | Molto lento (GPU) |
| Decoding | Veloce | Veloce | Veloce | Medio | Lento (GPU) |
| Supporto browser | Totale | Totale | 97%+ | 92%+ | Sperimentale |
| Scenario ideale | Tutto | Screenshot, grafici | Web generalista | Web avanzato, HDR | Ricerca, bitrate estremi |
Cosa significa questo per chi usa image hosting
Capire la compressione aiuta a scegliere strategie di upload sensate.
Screenshot o grafici? PNG — lossless, testo nitido.
Foto per il web? JPEG se serve compatibilità assoluta, WebP se vuoi peso inferiore del 25-35% con supporto browser quasi universale, AVIF se hai utenti moderni e budget di encoding (ad esempio un blog italiano di fotografia che serve asset pre-ottimizzati via CDN).
Animazioni? GIF è anacronistico — usa WebP animato o AVIF animato, sono ordini di grandezza migliori.
lpic.cc supporta upload di JPEG, PNG, WebP, GIF e mantiene il formato originale senza ricompressione server-side. Vantaggio: quello che carichi è quello che viene servito — niente degradazione introdotta dalla piattaforma. Svantaggio: se il tuo file è gigante, lo resta. Francamente, conviene passare per Squoosh o TinyPNG prima dell'upload per ottimizzare peso e qualità.
Nota: lpic.cc al momento non offre trasformazione server-side né adaptive serving (es. servire WebP a browser che lo supportano e JPEG a vecchi browser). Per quell'esigenza servono CDN immagine dedicate come Cloudinary o Imgix.
FAQ
Perché un JPEG quality 100 è comunque più piccolo di un PNG?
Perché quality 100 non significa lossless. Anche a quality 100, JPEG applica subsampling crominanza 4:2:0 (dati colore già dimezzati) e passa per DCT + quantizzazione (solo con divisori quasi tutti pari a 1). Persa informazione minima ma reale. Per vero lossless servono PNG, WebP Lossless, o JPEG XL Lossless.
Perché GIF non va per le foto?
GIF usa LZW (lossless compression), ma la paletta è limitata a 256 colori (8 bit). Una foto tipica ha milioni di colori; forzare a 256 introduce banding e dithering visibili. GIF resta utile per animazioni a pochi colori o icone, ma per foto è tecnicamente inadeguato dal 1996.
Comprimere un JPEG già compresso peggiora la qualità?
Sì, cumulativamente. Ogni ricompressione aggiunge errore di quantizzazione, anche con quality identica. Test tipico: JPEG riencodato 10 volte a quality 85 perde 2-4 dB di PSNR — degrado visibile. Regola operativa: edita sempre dal file sorgente, mai da un JPEG già compresso.
Quando la compressione AI diventerà mainstream?
Colli di bottiglia: velocità di decoding e standardizzazione. I codec tradizionali decodificano in millisecondi; i modelli AI impiegano centinaia di millisecondi a secondi. Stima: 3-5 anni per ambiti verticali (streaming, satellitare, medicale). Per sostituire JPEG/AVIF nei browser mainstream serve accelerazione hardware e standard ratificato — altri 5-10 anni verosimilmente.
Per uploadare su image host: prima comprimere o no?
Dipende dall'uso. Per social o chat, comprimere prima (lato lungo 2048 px, JPEG quality 85 o WebP quality 80) accelera upload e download lato destinatario. Per archivio fotografico professionale, carica il sorgente — se l'host non ricomprime (come lpic.cc), preservi massima qualità. Pattern pratico: dual track — originale full quality in archivio, versione web-friendly per condivisione pubblica.
JPEG XL è ancora una cosa?
Sì, anche se il supporto browser è stato un disastro (Chrome lo ha rimosso nel 2023). Firefox lo supporta dietro flag, Safari lo supporta da iOS 17. Tecnicamente eccellente — compressione migliore di AVIF, lossless efficiente, supporto HDR, transcoding senza perdita da JPEG. Ma senza sostegno Chrome resta irrilevante per il web pubblico. Per archivi professionali vale ancora la pena considerarlo.
Riferimenti
- JPEG Standard - ITU-T T.81
- PNG Specification - W3C
- WebP Compression Techniques - Google Developers
- AV1 Bitstream & Decoding Specification
- Ballé et al. - Variational Image Compression (2018)
- Cheng et al. - Gaussian Mixture Likelihoods (2020)
- ELIC: Efficient Learned Image Compression (2022)
- Squoosh
- Cloudinary - Image Formats Compared
- Mozilla - JPEG Overview