di  -  mercoledì 20 ottobre 2010

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…

8 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Massimo C
     scrive: 

    Insomma come è successo per il video, hanno tirato fuori in fretta e furia l’ENNESIMO formato per immagini con mille mancanze tanto per poter dire “anche noi ne abbiamo uno (di formato)”.

    Bho prima era microsoft che ogni due per tre sputava nuovi formati che, forte del 90% e oltre dello share di windows, incasinavano la vita della gente in un periodo relativamente breve.
    Ora ci si mette Google, forte del dominio in rete, a voler incasinare la questione con altri formati.
    Si la differenza è che sono liberi e bla bla, ma a noi utenti sta cosa importa molto poco. A me irrita particolarmente dover gestire nmila formati diversi che fanno la stessa cosa.
    E per fortuna che si era arrivati ad un punto di semplificazione: JPEG/PNG per immagini (più i formati lossless come tiff), mp3/aac per l’audio (anche qui con uno o due formati lossless di riferimento) e H264 per il video (con divx e xvid in declino vista l’ascesa dell’hd).
    Cioè si erano sostanzialmente eliminati i formati windows media qualcosa e gli altri formati che non si filava nessuno (tipo ogg per l’audio).
    Ora arriva google e complica di nuovo la questione.

  • # 2
    [D]
     scrive: 

    Credo che l’unica preoccupazione di google sia di mettere le mani avanti e ridurre al minimo il consumo di banda in vista di un’invasione di dispositivi social costruiti con in testa solo il cloud. Il successo o meno di questa nuova bolla (meglio traducibile in “quanto ci metterà a scoppiare”) è strettamente legato dal numero di servizi locali che millanterà di sostituire quindi alla capacità delle varie infrastrutture di rete di reggere il gioco. Come possiamo già vedere adesso i carrier non si impegnano concretamente nell’ampliamento delle infrastrutture di rete e stanno spingendo sempre più sull’uso esasperato di filtri, servizi come twitter, già adesso mostrano tutti i loro limiti a volte rendendo difficile perfino mandare un messaggio o consultare eventuali aggiornamenti quindi chi può cerca di mettere le mani avanti in attesa, nella speranza che qualcosa cambi dove serve sul serio.

  • # 3
    Nessuno
     scrive: 

    I dati rindontanti per la correzione di errore all’interno dello stream sono inutili. Visto che è un formato pensato per essere trasportato da protocolli che ha già la correzione d’errore ed eventualmente la ritrasmissione dei dati corrotti non recuperabili, non serve a nulla rindondare ulteriormente le cose.
    Non essenndo nemmeno un flusso video, il ritardo necessario per avere le infomrazioni è ininfluente.
    In questo senso la semplificazione del formato è un vantaggio per quanto riguarda la massima compattezza dei dati. Che è l’obiettivo primo di Google.

  • # 4
    Emanuele Rampichini
     scrive: 

    I dati rindontanti per la correzione di errore all’interno dello stream sono inutili. Visto che è un formato pensato per essere trasportato da protocolli che ha già la correzione d’errore ed eventualmente la ritrasmissione dei dati corrotti non recuperabili, non serve a nulla rindondare ulteriormente le cose.

    In effetti il dubbio sulla parte degli errori era venuto anche a me. Tutto sommato TCP garantisce l’affidabilità del canale “virtuale” con checksum e ritrasmissione. Impacchettare ulteriormente e aggiungere ridondanza in questo specifico caso mi sembra superfluo.

  • # 5
    banryu
     scrive: 

    @Nessuno & @Rampichini:
    Leggendo i vostri commenti mi è venuto in mente che forse le ridondanze presenti nel formato JPEG2000 hanno lo scopo di agevolare eventuali algoritmi di “error recovery” non soltanto per quanto riguarda eventuali errori di trasmissione (data loss) ma anche per quanto riguarda eventuali errori in fase di codifica dell’immagine (data truncation).
    Potrebbe essere così?

  • # 6
    Cesare Di Mauro (Autore del post)
     scrive: 

    E’ chiaro che gli errori non erano certo un problema che Google credeva di risolvere aggiungendo un po’ di ridondanza, a maggior ragione visto che l’obiettivo primario era quello di ridurre lo spazio.

    Nello specifico l’articolo tocca diverse punti o caratteristiche con cui si hanno a che fare quando di parla di formati per memorizzare delle immagini, come tra l’altro avevo anticipato già all’inizio. Ed è il motivo per cui ne ho parlato, appunto: una visione a 360° sull’argomento.

    Personalmente credo che, visto il tipo di contenitore adottato e il modo in cui è stato incanalato lo stream VP8, quello della error resilience sia stato l’ultimo dei pensieri (sempre che c’abbiano pensato :P).

    Non mi trovo d’accordo sulla mancanza della scansione progressiva. Per immagini di piccole o medie dimensioni è influenti, ma se vi capita di doverne visualizzare di dimensioni e/o spazio considerevoli, torna sicuramente utile avere subito un’anteprima, anziché aspettare che dall’alto verso il basso si formi un po’ alla volta l’immagine.

    @banryu: sì, lo scopo è anche quello. La segmentazione articolata e molto fine di JPEG 2000 consente di avere ampi margini per decidere come e dove “tagliare” le informazioni in base all’obiettivo di bit rate desiderato.

    In più, appunto, ha il pregevole vantaggio di isolare i singoli blocchi in modo che, in caso di errori, l’eliminazione di un blocco o il suo parziale utilizzo non “pesi” eccessivamente sulla qualità dell’immagine decodificata.

    Per rendersene conto basta prendere una qualunque immagine, comprimerla nei formati che vogliamo, introdurre errori dello stesso tipo, e provare a decodificarli. Penso che i classici “blocchettoni” che appaiono con JPEG o MPEG siano ben noti a tutti; artefatti di questo tipo sono del tutto assenti in JPEG 2000, dove l’errore si trova invece “spalmato” sull’immagine, che per questo conserva buona parte dell’informazione.

  • # 7
    Emanuele Rampichini
     scrive: 

    Nello specifico l’articolo tocca diverse punti o caratteristiche con cui si hanno a che fare quando di parla di formati per memorizzare delle immagini, come tra l’altro avevo anticipato già all’inizio. Ed è il motivo per cui ne ho parlato, appunto: una visione a 360° sull’argomento.

    Il mio era solo un dubbio infatti. Mi chiedevo se dall’alto della mia inesperienza mi fosse sfuggito qualcosa o non avessi considerato qualche altra “variabile in gioco”.

  • # 8
    del viero
     scrive: 

    Credo che molti si aspettavano da Google che tirasse fuori dal cappello la soluzione di ogni male al mondo!
    In realtà non credo che fosse loro intenzione sopprimere tutti i formati grafici esistenti.
    Credo che la loro ambizione più grande fosse quella di prendere il posto di jpg sul web dove non è strettamente necessario avere codifiche lossless.
    Se poi un particolare sito presenta delle foto che hanno bisogno di massima qualità è libero di mantenere un formato png.
    Webp nn contiene codifiche lossless principalmente per 2 motivi:
    1) non era loro intendimento rimpiazzare i formati esistenti che hanno questa qualità ( sul web le immagini in questi formati non sono moltissime in percentuale)
    2) molto probabilmente, anche tentando, al momento attuale non si conosce un sistema di codifica lossless migliore di quelli esistenti e utilizzati. (almeno non in modo significativo)

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.