Dopo aver trattato della qualità delle immagini e del contenitore utilizzato per il nuovo formato di casa Google, passiamo ad alcune considerazioni su WebP sulla base di alcune esigenze comuni e confrontandolo, ove necessario, con gli altri formati esistenti.
Come abbiamo visto, l’utilizzo di una struttura “ridotta all’osso”, e con pochissimo spazio a disposizione, comporta non pochi problemi per introdurre delle innovazioni. Già adesso sono presenti delle carenze non di poco conto, come l’assenza dell’alpha channel e la compressione esclusivamente lossy, ad esempio.
Si tratta di caratteristiche di fondamentale importanza, specialmente alla luce del fatto che WebP si propone come soluzione orientata al web (il nome è piuttosto eloquente), che ne fa largo uso.
Per il primo sappiamo che Google è già all’opera per introdurlo al più presto e, come anticipato, a mio avviso la soluzione che potrebbe essere adottata per non toccare lo stream VP8 sarà quella di utilizzare un apposito chunk nella struttura RIFF utilizzata.
Ciò pone alcuni problemi non di poco conto. Ad esempio, i dati dell’alpha channel saranno compressi o lasciati “grezzi”? Se compressi, con quale algoritmo? Inoltre, sarà lossy (con perdita, come per lo stream VP8) oppure lossless (senza perdita, tipo PNG)? I dati rappresenteranno il livello di trasparenza / opacità, oppure un semplice bitplane (ad esempio 0 -> pixel trasparente, 1 -> pixel opaco / che appartiene all’immagine; quindi soltanto per “forare” i pixel, some si usa dire in gergo)?
Ovviamente il massimo della flessibilità sarebbe rappresentato dal poter scegliere fra queste possibilità, ma dubito che la soluzione finale le contemplerà tutte. In particolare, utilizzare livelli di trasparenza oppure un singolo bitplane “discreto” richiede un approccio molto differente, specialmente a livello di algoritmi di compressione.
Riguardo la compressione lossless penso, invece, che non arriverà mai. VP8 è un formato strettamente lossy (e con pochi parametri selezionabili per regolare il livello di compressione), e modificarlo per eliminare la perdita di informazioni dei dati significherebbe snaturarlo.
Questo lo taglierà fuori dagli ambiti in cui serve ancora un’immagine compressa in formato lossless, poiché non sempre è desiderabile guadagnare spazio a discapito del dettaglio, per cui PNG rimarrà ancora a lungo a dominare in quest’ambito (e GIF in quello delle immagini animate).
Tornando ai canali, difficilmente ne vedremo altri, oltre al supporto al già citato alpha, come pure spazi colore diversi. VP8 è basato esclusivamente sulla compressione di immagini YUV (tra l’altro subscalate solo in formato 4:2:0), quindi usando sempre tre canali e questo spazio.
Comprimere immagini CMYK, o altre immagini che usano spazi colore con più di 3 componenti cromatiche non è, pertanto, possibile, come pure pensare di supportare l’HDR o più di 8 bit per componente.
Un’altra caratteristica, ormai poco diffusa, è la scansione progressiva delle immagini che consente, in ambito di trasmissione, di visualizzare già i dettagli macroscopici delle stesse, fino ad arrivare, man mano, a completare il livello di dettaglio restituendo l’immagine integrale. WebP, manco a dirlo, non la supporta, e finora non ho letto in giro di idee in proposito, per cui è probabile che questa non arriverà mai.
Idem per le ROI e la resistenza agli errori tipiche del JPEG 2000. Le ROI, acronimo di Region Of Interest, consentono di definire delle aree (rettangolari) di maggior interesse, per le quali sarà riservata una maggior banda (o spazio, che dir si voglia).
Questo significa che quelle regioni conserveranno molte più informazioni rispetto alle altre, migliorando anche in maniera sensibile la qualità di queste porzioni dell’immagine. Basti pensare a una foto in cui è stato messo a fuoco un pezzo, che risulta estremamente dettagliato rispetto al resto, per rendere l’idea.
Sulla resistenza agli errori non ho visto test sul VP8, ma leggendo le specifiche e analizzando la codifica dello stream dei dati, non mi sembra ci sia nulla di paragonabile a JPEG 2000.
Quest’ultimo, infatti, adotta precise misure atte ad attutire il più possibile l’impatto dovuto alla presenza di uno o più errori nell’immagine codificata, introducendo apposite ridondanze nello stream di dati e suddividendo le informazioni in piccoli blocchi (in modo da isolarli il più possibile). Oltre a ciò, è opzionalmente possibile ridondare alcune informazioni riducendo drasticamente gli artefatti visivi causati dagli errori.
Il prezzo da pagare è uno stream molto più complesso da parserizzare, e che richiede più spazio. Da questo punto di vista WebP si pone in una posizione diametralmente opposta, avendo fatto della semplicità del formato e dello spazio ridotto i suoi punti di forza fin dall’inizio, per cui certamente non è ipotizzabile un cambio di direzione da parte di Google per rendere più robusto il suo formato.
Se è vero che il parsing richiede meno risorse, un’ultima considerazione va comunque fatta proprio su questo piano. Al momento, infatti, non risulta alcun supporto all’accelerazione della compressione o, meglio ancora, della decompressione per lo stream VP8 contenuto in WebP, per cui tutto rimane a carico della CPU.
E’ sicuramente vero che in futuro la situazione è destinata a migliorare, con la diffusione di WebM per i video in particolare, ma non sappiamo quando ciò si verificherà, e in che misura.
Paradossalmente H.264, che è un formato più oneroso in termini computazionali (ma di qualità ben più elevata), presenta un vasto supporto, essendo presente ormai un’apposita sezione nelle GPU (anche a basso costo) da qualche anno a questa parte, tanto che perfino un netbook basato su Atom e con un chipset economico come lo ION di nVidia riesce a riprodurre in scioltezza filmati in alta definizione, tra l’altro con consumi particolarmente ridotti (e anche questo ha il suo peso nelle valutazioni).
Personalmente, e chiudo, questo formato mi lascia più che perplesso, come ho anche scritto nei commenti al precedente articolo a esso dedicato, e ancora oggi stento a capire quale spazio potrebbe ritagliarsi, vista l’agguerrita concorrenza che esiste da tempo.
In particolare di JPEG 2000 che ha tutte le carte in regola per dominare, e JPEG XR che si pone come interessante e papabile erede del JPEG (in quanto richiede risorse computazionali paragonabili, pur presentando una qualità migliore a parità di dimensione del file, e caratteristiche simili al JPEG 2000 a livello di funzionalità, più qualche innovazione).
Al solito, il successo dipenderà dalla diffusione e, quindi, da quanto Google sarà capace di “spingere” i suoi nuovi formati, ma uccidere JPEG, GIF e PNG rappresenta la classica “mission: impossible“. Molti hanno già provato e fallito, e Google, pur forte della sua nomea, potrebbe fare la stessa fine…
