E’ di pochi giorni la notizia che Google ha realizzato un nuovo formato di compressione delle immagini. Sulla carta dovrebbe rappresentare il santo Graal, e a tesserne le lodi ovviamente non poteva che essere lo stesso colosso di Mountain View, ormai lanciato nella ridefinizione degli strumenti che utilizziamo nella nostra quotidianità.
In realtà WebP nasce per soddisfare un’esigenza che BigG sente pesante, com’è attestato nel blog in cui è stata comunicata la notizia: il 65% dei dati scaricati da pagine web è costituito da immagini. Poiché il core business di quest’azienda è incentrato in questo settore, si fa presto a comprendere il suo interesse nella riduzione dello spazio da esse occupato.
L’idea alla base è piuttosto semplice: impiegare il codice del codec video VP8 (di cui di recente ha rilasciato i sorgenti) sfruttandone la parte dedicata alla compressione dei cosiddetti intra-frame (chiamati spesso anche key frame; per semplicità: immagini che non hanno bisogno di altre informazioni per poter essere codificate), incapsulando il risultato in un file RIFF di appena 20 byte.
Si tratta, quindi, di due aspetti diversi, che sono stati combinati per ottenere la migliore soluzione dal punto di vista del mero spazio occupato. Da una parte c’è l’esigenza di risparmiare quanti più byte possibili per la mera informazione dell’immagine, e dall’altra la necessità di impacchettare questi dati in un contenitore minimale (ma estendibile) per poterli leggere.
Ognuno presenta pregi e difetti nella propria area di competenza, ma è chiaro che la parte del leone è costituita dal primo tipo. Non può certo essere il contenitore il problema principale da risolvere, anche se ha sicuramente il suo peso (per le limitazioni che ne possono derivare, e per il parser che dovrà leggerlo e interpretarne il contenuto; ne parleremo in futuro).
La qualità dell’immagine dipende dal tipo di codifica utilizzata e, dai test effettuati in casa, Google dichiara che, su un campione di 1 milione di immagini prese a caso fra JPEG, GIF e PNG, il risultato ottenuto da WebP è di una riduzione media del 39%, “senza aver compromesso in maniera percettibile la qualità visiva”.
Questa metodologia di test è, però, ampiamente criticabile. In primo luogo non si prendono immagini a caso. Lo sanno bene le aziende che operano nel settore, che nel tempo hanno creato archivi di foto che riproducono gli ambienti e le situazioni più comuni, in modo da avere un campione realmente rappresentativo da utilizzare per effettuare confronti durante la sperimentazione di nuovi algoritmi.
Secondo, ricomprimere immagini già compresse con JPEG dovrebbe essere evitato, perché l’operazione ha distrutto il segnale originale, introducendo tra l’altro artefatti visivi. Inoltre esistono diversi codec JPEG, implementati in maniera diversa (e magari con diverse tabelle di quantizzazione), ma soprattutto chi ha prodotto l’immagine avrà usato un diverso livello di quantizzazione (il famoso parametro “qualità”). Quindi è bene partire sempre dal segnale originale, e vedere come si comporta il nuovo codec.
Terzo, è vero che il formato di per sé è lossless (senza perdita), ma le GIF hanno già subito una pesante operazione di quantizzazione, dovuta alla riduzione della palette dei colori ai soli 256 permessi da questo formato. Per cui parecchia dell’informazione del segnale è andata perduta.
Rimane il PNG quale formato utile allo scopo, che è lossless e non opera alcuna operazione sull’immagine di partenza, preservando quindi il segnale.
L’operazione corretta, quindi, dovrebbe essere quella di comprimere le sole immagini PNG con un buon codec JPEG e il nuovo WebP, assicurandosi che le immagini risultanti siano quasi del tutto indistinguibili visivamente, e comparando poi la dimensione dei file ottenuti.
Da quanto riportato da Google sembra, però, che sia stata “bovinamente” eseguita una compressione di tutte le immagini campione, conteggiando poi la dimensione dei file e tirando fuori la famigerata media del 39%. Tutto ciò mi sembra insensato, alla luce di quanto esposto finora e dal fatto che il conteggio su file GIF e PNG andava assolutamente evitato.
Il che è a dir poco lapalissiano, visto che un’immagine lossless occuperà generalmente di gran lunga più spazio rispetto alla medesima, ma compressa in un formato lossy. Il tutto falsando le statistiche, ovviamente, ed è tanto più importante sottolinearlo, quanto maggior enfasi sia stata data ai “numeri”, appunto.
Leggendo lo studio comparativo saltano fuori altre cose interessanti. Vediamo che è stato scelto un PSNR di 42 come target per la “qualità” delle immagini risultati, ma questa è una misura ampiamente opinabile. Ne esistono di migliori (come la SSIM), ma il giudizio finale di un occhio esperto lo ritengo insostituibile.
La seconda è che, non paghi di aver usato immagini già compresse in JPEG, queste sono state a loro volta ricompresse per ottenere il suddetto PSNR di 42… No comment.
Detto ciò, i risultati sembrano lusinghieri, numeri alla mano, ma non eccezionali, e presentano artefatti visivi che sono tutt’altro che “impercettibili”, come si può vedere anche dal set di immagini scaricabile dal sito (il pacchetto si trova qui) .
In particolare si può notare una distorsione dei colori originali che sembrano più opachi (che vengono invece preservati da altri codec, come quello del JPEG 2000), l’evidenza di alcuni “blocchi” (dovuti alla suddivisione in blocchi, appunto, usata dall’algoritmo), ma soprattutto la presenza di texture “smussate” (come ad esempio l’increspatura della corteccia di un albero, che risulta invece “liscia”).
Riguardo a quest’ultima ho letto in giro ottimi giudizi da gente che trova il risultato “morbido” e più gradevole alla vista. Mi ricorda un proverbio arabo, di come un cammello possa trovare gustosi i rovi che mastica, non curandosi del sangue della sua bocca che fa da condimento…
E’ chiaro che da un formato lossy ci aspettiamo un “taglio” delle informazioni, e quindi dei dettagli: non si otterrebbero altrimenti fattori di compressione così elevati. Ma compiacersi della perdita di dettaglio lo trovo, diciamo, “singolare”.
Per il momento mi fermo, e invito chi fosse interessato a scaricare l’archivio con le immagini e visionarle (magari con l’aiuto dello zoom) per rendersi conto di quanto esposto finora. Nel prossimo articolo riguardo a WebP parlerò del contenitore e delle problematiche che si devono affrontare quando parliamo di formati per memorizzare immagini, alla luce anche della mia esperienza nello sviluppo di un decoder JPEG 2000.
