Nel precedente articolo su WebP abbiamo analizzato le motivazioni che hanno portato Google a tirare fuori dal cilindro questo nuovo formato per memorizzare le immagini, in che modo sono stati realizzati i test, e la qualità dei file generati col nuovo arrivato.
Oltre all’algoritmo che determina in maniera preponderante lo spazio occupato, a contribuire allo scopo è anche il cosiddetto “contenitore” necessario per memorizzare in maniera opportuna i dati compressi, e di cui avevamo accennato prima.
In realtà la scelta del contenitore cela anche l’operazione che è stata fatta per arrivare a definire il WebP, per cui l’argomento non meritava di essere liquidato in poche righe ma, al contrario, sviscerato per comprenderne meglio la portata e le implicazioni.
Sappiamo che Google ha deciso di sfruttare l’esistente RIFF (nato, fra l’altro, dal famosissimo IFF onnipresente su Amiga) introducendo appositi tag (“chunk” nel gergo IFF/RIFF) per identificare correttamente WebP, e permetterne il corretto parsing e/o manipolazione.
Lo schema è estremamente semplice:
Come si può vedere, occupa appena 20 byte, di cui 12 dedicati ai 3 chunk (ognuno occupa sempre 4 byte) necessari a identificarlo. A RIFF e VP8 seguono sempre 4 byte che specificano la lunghezza del chunk (rispettivamente quella dell’intero file, e dei dati dell’immagine compressa), mentre soltanto WEBP non è dotato del campo lunghezza e serve esclusivamente a specificare il tipo di file RIFF che si sta leggendo (WEBP, appunto).
Dopo i dati del chunk VP8 possono essere presenti i chunk ICMT, ICOP, IART, e INAM, utilizzati per memorizzare i metadati opzionali relativi ai commenti, al copyright, al nome dell’artista e al titolo.
Ciò che balza immediatamente all’occhio è l’assenza dei metadati fondamentali, quelli che descrivono le caratteristiche intrinseche dell’immagine: risoluzione, profondità (numero di bit per componente cromatica), spazio colore utilizzato, e numero di componenti cromatiche (eventualmente incluso l’alpha channel). Eventualmente anche il formato di compressione utilizzato, per poterne specificarne altri in futuro.
Queste informazioni sono generalmente disponibili nella struttura del contenitore, come si può verificare facilmente andando ad analizzare altri formati grafici:
Appare chiara e netta la suddivisione fra i metadati e i dati dell’immagine effettivamente codificati. Questo anche nel PNG, che è un formato molto simile a WEBP (poiché basato anch’esso sull’idea dei chunk).
Anche volendosi sforzare, cercando nei 20 byte del RIFF non esiste nessun metadato disponibile. Per cui è chiaro, a questo punto, che l’unico posto in cui si possano trovare è all’interno dei dati del chunk VP8. Come suggerisce la FAQ, bisogna conoscere la struttura dello stream di dati VP8, che si trova a pagina 10 e seguenti.
Scopriamo, così, che i dati degli intra-frame (o key-frame) sono costituiti da un header di 10 byte, a cui seguono i dati (suddivisi in macroblocchi). Poiché WebP memorizza una sola immagine VP8, di tipo intra-frame, sappiamo che i primi 10 byte del chunk VP8 forniranno le informazioni sui metadati che cerchiamo, che troviamo, infatti, a partire da pagina 28.
Da qui emergono, oltre a quelli cercati (risoluzione, eventuale scaling orizzontale e/o verticale dell’immagine, filtro di postprocessing da utilizzare, spazio colore), diversi attributi che riguardano esclusivamente il segnale video, segno di come questo formato sia giustamente stato pensato per questo tipo di applicazioni.
La cosa più importante di cui prendere atto è che i metadati sono confluiti nei dati dello stream codificato, anziché essere messi a disposizione nella struttura del file RIFF. Questo significa che, se in futuro si dovesse adottare una nuova codifica (una VP9, ad esempio), un’applicazione che fornisce informazioni sul file dovrà necessariamente essere aggiornata per parserizzare il relativo chunk ed estrarre ciò che le serve.
Se, invece, fossero state disponibili nella struttura RIFF, l’astrazione fornita avrebbe consentito di leggerle e mostrarle a prescindere dalla codifica utilizzata per i dati, similmente a quanto avviene, ad esempio, coi JPEG, dove i dati possono essere codificati in maniera diversa (compressione di Huffman o aritmetica) ma i metadati sono disponibili a prescindere da ciò. La separazione fra metadati e dati ha un vantaggio non indifferente.
A conti fatti, inoltre, l’overhead del contenitore scelto non può certo limitarsi ai 20 byte sbandierati, ma deve necessariamente includere anche le strutture che conservano i citati metadati, per cui vanno conteggiati almeno 30 byte (più diversi altri bit utilizzati a seguire). Rimane indubbiamente una quantità effimera, ma per correttezza va messa in evidenza.
Come va sottolineato il fatto che l’utilizzo di strutture dati così piccole e già ampiamente utilizzate (sono pochi i bit rimasti liberi, quindi senza aggiungere ulteriori strutture che produrrebbero stream incompatibili con l’esistente VP8) pone serii problemi all’espandibilità futura, già minata da forti limitazioni, come l’uso di un solo spazio colore (cioè lo YUV), il sampling delle componenti cromatiche fissato a 4:2:0, e la presenza di tre componenti fisse (Y, U, e V appunto). Sarà interessante vedere, a questo punto, in che modo introdurranno l’alpha channel (magari come chunk a parte).
In conclusione, la mia impressione è che la scelta del contenitore rifletta una banale operazione di copia & incolla. Google aveva già tra le mani la libreria in grado di codificare un’immagine in uno stream VP8 di tipo key-frame, e non ha fatto altro che prenderne il risultato e copiarlo integralmente, senza alcuna modifica, subito dopo il contenitore RIFF fisso di 20 byte. Idem per il processo di decodifica, in maniera speculare.
Un esercizietto di poca roba, insomma. Nulla di trascendentale e, soprattutto, che abbia richiesto tempi di sviluppo consistenti. WebP nasce, quindi, da un’idea che si è concretizzata molto velocemente e, da quanto detto finora, altrettanto in fretta ha mostrato già diversi limiti, mentre di altri ne discuteremo prossimamente.
Ottima analisi… ma ancora non riesco a intravedere le reali ragioni per la sua promozione da parte di google.
Come abbiamo già visto nel tuo articolo precedente, il guadagno di compressione è molto inferiore a quello sbandierato, la qualità dell’immagine è scarsa (a quanto pare la causa è data dalla mancanza di filtri psico-visuali) e la struttura del file riflette la metodologia di sviluppo adottata (un palese copia-incolla di codice).
La domanda che continuo a pormi non è “come”, “cosa”… ma “perchè” promuovere WebP? Hanno forse bisogno di monetizzare le licenze di VP8 vendendo dei codec ottimizzati ai produttori di dispositivi embedded (magari integrandolo come componente opzionale in android)?
Beh, prima dovrebbero ottimizzare i loro codec… :D Il codice di VP8 sembra non sia il massimo per com’è scritto, ma soprattutto in termini puramente prestazionali.
Francamente non saprei cosa rispondere alle tue domande, perché sono perplesso quanto te.
Forse si sono gasati con l’acquisizione di On2, tirando fuori WebM prima e WebP, volendo dimostrare di essere sempre i migliori e di imporre la loro strada e visione delle cose, ma devono fare i conti anche loro con la realtà.
Oppure pensano veramente che questi formati possano risolvere i loro problemi, ma non sono certamente i migliori nei rispettivi campi.
Onestamente non mi viene in mente altro…
Ciao Cesare,
ottimo articolo, analisi impeccabile, e argomento molto interessante anche per le implicazioni.
Sono anche io perplesso circa la “ratio” che spinge Google a promuovere questo formato.
Da ignorante butto là un’ipotesi: non è che il motivo da cercare non sia appunto nel merito tecnico del formato e dunque nei presunti vantaggi tecnici e nemmeno in un aspetto economico di facile individuazione, come nell’ipotesi della vendita delle licenze evidenziata da TheKaneB, ma magari in un qualche aspetto più indiretto che potrebbe essere legato agli effetti che l’introduzione e la diffusione del formato WebP, qualora ampiamente accettato, avrebbe?
Magari “soppianterebbe” in larga misura qualche altro formato in qualche contesto specifico (con quali conseguenze rilevanti per Gooogle non saprei)?
Complimenti di nuovo, trovo i tuoi articoli sempre molto interessanti e “succosi” :)
Intanto vi ringrazio per i complimenti. :)
Riguardo ai vantaggi, non credo che si risolva in un aspetto economico “diretto” visto che WebM e WebP sono stati rilasciati gratuitamente.
Penso ad altro, invece.
Per WebM al risparmio sulle licenze del consorzio H.264, ma mi sembra che l’acquisizione di On2 per avere VP8 sia costata parecchio, per cui qui, almeno per il momento, non vedo vantaggi.
Per WebP è un discorso di banda risparmiata, questo l’hanno detto loro stessi fin dall’inizio, e dovrebbe essere consistente (il 39% in meno non è poco).
Dovrebbe soppiantare JPEG, GIF e PNG (anche questo l’hanno detto loro) ma, per quanto scritto nell’altro articolo, non mi sembra possibile.
Io invece sono contento che ci sia qualcuno che pensi anche allo spazio occupato o alla banda usata.
Ho l’hard disk pieno di robaccia che ogni tanto mi devo mettere li a cancellare.
E mi dispiace anche sprecare la poca banda a disposizione che ho, visto che a casa mia non arriva la banda larga, in inutili immagini pubblicitarie ad alta risoluzioni.
Anche qui devo fare le mie a lasciar fuori dalla porta qui simpatici consigli per gli acquisti.
Beh, se la tua preoccupazione è quella, da 10 anni esiste il JPEG 2000 per comprimere le immagini (anche lossless, tra l’altro), e da un po’ di anni l’MPEG-4 AVC profilo 10 per i filmati.
non credo fosse necessario scrivere un ulteriore articolo sul formato webP…google ad oggi vende servizi e non tecnologie software…anche il buon chrome è solo un esercizio di stile rispetto agli altri browser…analogamente per googledocs…insomma alla pari di apple google vende fumo….
per quanto riguarda la compressione del formato delle immagini esistono in realtà numerose teorie tra quelle più solide sono quelle che interessano l’evoluzione dell’hardware, ossia per migliorare la compressione delle immagini è necessario avere nuovi strumenti hardware…i cosidetti ana-bit…ossia dei bit che hanno una oscillazione analogica che sarebbe capace di simulare l’impulso luminoso, questo permette di ottenere una descrizione dei dati video compatta e veloce e con una minima perdita di qualità, paradossalmente il futuro sembra essere un mix di digitale ed analogico…
OT: continua lo sviluppo del CELL ed io sono contento che questo accada faccio il tipo per IBM…
@homero
> “chrome solo un esercizio di stile rispetto agli altri browser”
è il browser che è cresciuto più di tutti negli ultimi anni, se l’avessi provato almeno una volta capiresti anche il perchè.
> “google vende fumo”?
guardati i risultati di questo trimestre appena usciti, nonostante la crisi continui (+32% di utile rispetto allo stesso periodo del 2009).
> “ana-bit”?
ma che stai dicendo? che viaggi ti fai?
io non so certi post da dove saltino fuori
the_m
forse si riferiva a questo
http://arstechnica.com/hardware/news/2010/08/probabilistic-processors-possibly-potent.ars
(anche se in quel caso si parla di p-bit, in quanto associati a valori di “probabilità” non discretizzati – alla fin fine è sostanzialmente logica fuzzy applicata al design di un chip)