Specifiche container WebP

Introduzione

WebP è un formato dell'immagine che utilizza (i) la codifica dei fotogrammi chiave VP8 per comprimere i dati dell'immagine con perdita di dati o (ii) la codifica senza perdita di dati WebP. Questi schemi di codifica dovrebbero renderla più efficiente rispetto ai formati precedenti, come JPEG, GIF e PNG. È ottimizzato per un trasferimento rapido di immagini sulla rete (ad esempio per i siti web). Il formato WebP offre parità di funzionalità (profilo colore, metadati, animazione ecc.) anche con gli altri formati. Questo documento descrive la struttura di un file WebP.

Il container WebP (ovvero il container RIFF per WebP) consente il supporto delle funzionalità oltre al caso d'uso di base di WebP, ovvero un file contenente una singola immagine codificata come frame chiave VP8. Il container WebP offre ulteriore supporto per:

  • Compressione senza perdita di dati: un'immagine può essere compressa senza perdita di dati utilizzando il formato senza perdita di dati WebP.

  • Metadati: un'immagine può contenere metadati archiviati in formato Exchangeable Image File Format (Exif) o Extensible Metadata Platform (XMP).

  • Trasparenza: un'immagine può essere trasparente, ovvero un canale alfa.

  • Profilo colore: un'immagine può avere un profilo ICC incorporato, come descritto dall'International Color Consortium.

  • Animazione: un'immagine può avere più frame separati da pause, che ne creano un'animazione.

Denominazione

È CONSIGLIATO utilizzare i seguenti tipi quando si fa riferimento al container WebP:

Nome formato contenitoreWebP
Estensione nome file.webp
Tipo MIMEimmagine/webp
Identificatore di tipo uniformeorg.webmproject.webp

Terminologia e nozioni di base

Le parole chiave "DEV", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nel documento BCP 14 RFC 2119 RFC 8174 quando e solo quando appaiono in maiuscolo.

Un file WebP contiene un'immagine statica (ovvero una matrice codificata di pixel) o un'animazione. Può contenere anche informazioni sulla trasparenza, un profilo colore e metadati. Ci riferiamo alla matrice di pixel come la tela dell'immagine.

La numerazione dei bit nei diagrammi dei blocchi inizia da 0 per il bit più significativo ("MSB 0"), come descritto in RFC 1166.

Di seguito sono riportati i termini aggiuntivi utilizzati in questo documento:

Lettore/autore
Il codice che legge i file WebP viene definito lettore, mentre il codice che li scrive viene definito writer.
uint16
Un numero intero a 16 bit, small-endian, senza segno.
uint24
Un numero intero a 24 bit, small-endian, senza segno.
uint32
Un numero intero a 32 bit, small-endian, senza segno.
FourCC
Un codice a quattro caratteri (FourCC) è un codice uint32 creato concatenando quattro caratteri ASCII in ordine small-endian. Ciò significa che "aaaa" (0x61616161) e "AAAA" (0x41414141) vengono trattati come FourCCs diversi.
In base a 1
Un campo intero senza segno che memorizza i valori con un offset di -1, ad esempio, un campo di questo tipo memorizzerà il valore 25 come 24.
ChunkHeader('ABCD')
Utilizzato per descrivere le intestazioni FourCC e Chunk size dei singoli blocchi, dove "ABCD" è il FourCC del blocco. Le dimensioni di questo elemento sono 8 byte.

Formato file RIFF

Il formato file WebP si basa sul formato documento RIFF (Resource Interchange File Format).

L'elemento base di un file RIFF è un blocco. È composto da:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Chunk FourCC                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Chunk Size                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                         Chunk Payload                         :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Blocco FourCC: 32 bit
Codice ASCII a quattro caratteri utilizzato per l'identificazione dei blocchi.
Dimensione blocco: 32 bit (uint32)
La dimensione del blocco in byte, escluso questo campo, l'identificatore del blocco o la spaziatura interna.
Payload blocco: dimensioni blocco byte
Il payload dei dati. Se Dimensioni chunk è dispari, viene aggiunto un singolo byte di spaziatura interna, che DEVE essere 0 per conformarsi a RIFF.

Nota: RIFF ha una convenzione secondo la quale le FourCC dei blocchi tutti maiuscole sono blocchi standard che si applicano a qualsiasi formato di file RIFF, mentre i FourCC specifici di un formato file sono tutti minuscoli. WebP non segue questa convenzione.

Intestazione del file WebP

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      'R'      |      'I'      |      'F'      |      'F'      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           File Size                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      'W'      |      'E'      |      'B'      |      'P'      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"RIFF": 32 bit
I caratteri ASCII "R", "I", "F", "F".
Dimensioni file: 32 bit (uint32)
Le dimensioni del file in byte, a partire dall'offset 8. Il valore massimo di questo campo è 2^32 meno 10 byte, quindi la dimensione dell'intero file è al massimo di 4 GiB meno 2 byte.
"WEBP": 32 bit
I caratteri ASCII "W", "E", "B", "P".

Un file WebP DEVE iniziare con un'intestazione RIFF con il "WEBP" di FourCC. La dimensione del file nell'intestazione corrisponde alla dimensione totale dei blocchi che seguono più 4 byte per il FourCC "WEBP". Il file NON DEVE contenere dati dopo i dati specificati da Dimensioni file. I lettori POSSONO analizzare tali file, ignorando i dati finali. Poiché la dimensione di ogni blocco è uniforme, anche le dimensioni fornite dall'intestazione RIFF sono pari. I contenuti dei singoli blocchi sono descritti nelle sezioni seguenti.

Formato file semplice (non più stabile)

Questo layout DEVE essere utilizzato se l'immagine richiede la codifica lossy e non richiede trasparenza o altre funzionalità avanzate fornite dal formato esteso. I file con questo layout sono di dimensioni inferiori e sono supportati da software meno recenti.

Formato file WebP semplice (con perdita di dati):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    WebP file header (12 bytes)                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        'VP8 ' Chunk                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Blocco "VP8":

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('VP8 ')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                           VP8 data                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dati VP8: byte Chunk size
Dati bitstream VP8.

Notate che il quarto carattere nel FourCC "VP8" è uno spazio ASCII (0x20).

La specifica del formato bitstream VP8 è descritta nella Guida al formato e alla decodifica dei dati VP8. Tieni presente che l'intestazione del frame VP8 contiene la larghezza e l'altezza del frame VP8. Si presume che siano la larghezza e l'altezza del canvas.

Le specifiche VP8 descrivono come decodificare l'immagine nel formato Y'CbCr. Per convertire in RGB, DOVREBBE essere utilizzato il Consiglio BT.601. Le applicazioni POTREBBERO utilizzare un altro metodo di conversione, ma i risultati visivi possono differire tra i decoder.

Formato file semplice (senza perdita)

Nota: i lettori meno recenti potrebbero non supportare i file in formato senza perdita di dati.

Questo layout DEVE essere utilizzato se l'immagine richiede la codifica senza perdita di dati (con un canale di trasparenza facoltativo) e non richiede funzionalità avanzate fornite dal formato esteso.

Formato file WebP semplice (senza perdita di dati):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    WebP file header (12 bytes)                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                         'VP8L' Chunk                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Blocco "VP8L":

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('VP8L')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                           VP8L data                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dati VP8L: byte Chunk size
Dati bitstream VP8L.

Le specifiche attuali del bitstream VP8L sono disponibili nel formato WebP Lossless Bitstream Format. Tieni presente che l'intestazione VP8L contiene la larghezza e l'altezza dell'immagine VP8L. Si presume che siano la larghezza e l'altezza del canvas.

Formato file esteso

Nota: i lettori meno recenti potrebbero non supportare i file nel formato esteso.

Un file di formato esteso è costituito da:

  • Un blocco "VP8X" con informazioni sulle funzionalità utilizzate nel file.

  • Un blocco "ICCP" facoltativo con un profilo colore.

  • Un blocco "ANIM" facoltativo con dati di controllo dell'animazione.

  • Dati dell'immagine.

  • Un blocco "EXIF" facoltativo con metadati EXIF.

  • Un blocco "XMP" facoltativo con metadati XMP.

  • Un elenco facoltativo di blocchi sconosciuti.

Per un'immagine statica, i dati dell'immagine sono costituiti da un singolo frame, composto da:

Per un'immagine animata, i dati immagine sono costituiti da più frame. Maggiori dettagli sui frame sono disponibili nella sezione Animazione.

Tutti i blocchi necessari per la ricostruzione e la correzione del colore, ovvero "VP8X", "ICCP", "ANIM", "ANMF", "ALPH", "VP8" e "VP8L", DEVONO apparire nell'ordine descritto in precedenza. I lettori DEVONO avere errori quando i blocchi necessari per la ricostruzione e la correzione del colore non sono nell'ordine corretto.

I metadati e i blocchi sconosciuti POTREBBERO apparire nell'ordine sbagliato.

Motivazione: i blocchi necessari per la ricostruzione devono apparire per primi nel file per consentire a un lettore di iniziare a decodificare un'immagine prima di ricevere tutti i dati. Un'applicazione può trarre vantaggio dal variare l'ordine dei metadati e dei blocchi personalizzati in base all'implementazione.

Intestazione file WebP esteso: 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                   WebP file header (12 bytes)                 |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('VP8X')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv|I|L|E|X|A|R|                   Reserved                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Canvas Width Minus One               |             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...  Canvas Height Minus One    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Riservato (Rsv): 2 bit
DEVE essere 0. I lettori DEVONO ignorare questo campo.
Profilo ICC (I): 1 bit
Imposta se il file contiene un blocco "ICCP".
Alpha (L): 1 bit
Imposta se uno dei frame dell'immagine contiene informazioni di trasparenza ("alpha").
Metadati EXIF (E): 1 bit
Da impostare se il file contiene metadati EXIF.
Metadati XMP (X): 1 bit
Imposta se il file contiene metadati XMP.
Animazione (A): 1 bit
Imposta se questa è un'immagine animata. I dati nei blocchi "ANIM" e "ANMF" devono essere utilizzati per controllare l'animazione.
Riservato (R): 1 bit
DEVE essere 0. I lettori DEVONO ignorare questo campo.
Riservato: 24 bit
DEVE essere 0. I lettori DEVONO ignorare questo campo.
Larghezza canvas meno uno: 24 bit
1 in base Larghezza del canvas in pixel. La larghezza effettiva del canvas è 1 + Canvas Width Minus One.
Altezza canvas meno uno: 24 bit
1-in base Altezza della tela in pixel. L'altezza effettiva del canvas è 1 + Canvas Height Minus One.

Il prodotto tra Larghezza tela e Altezza tela DEVE essere al massimo 2^32 - 1.

In futuro potrebbero essere aggiunti altri campi. I campi sconosciuti DEVONO essere ignorati.

Animazione

Un'animazione è controllata da blocchi "ANIM" e "ANMF".

Blocco "ANIM":

Per un'immagine animata, questo blocco contiene i parametri globali dell'animazione.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ANIM')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Background Color                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Loop Count           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Colore di sfondo: 32 bit (uint32)
Il colore di sfondo predefinito del canvas, nell'ordine in byte [blu, verde, rosso, alpha]. Questo colore POTREBBE essere utilizzato per riempire lo spazio inutilizzato sul canvas intorno ai frame, nonché per i pixel trasparenti del primo frame. Il colore di sfondo viene utilizzato anche quando il metodo di smaltimento è 1.

Nota:

  • Il colore di sfondo POTREBBE contenere un valore alfa non opaco, anche se il flag Alpha nel blocco "VP8X" non è impostato.

  • Le applicazioni di visualizzazione DEVONO trattare il valore del colore di sfondo come suggerimento e non è necessario utilizzarlo.

  • Il canvas viene cancellato all'inizio di ogni loop. Il colore di sfondo POTREBBE essere usato per ottenere questo risultato.

Conteggio loop: 16 bit (uint16)
Il numero di ripetizioni dell'animazione. Se è 0, significa all'infinito.

Questo blocco DEVE essere visualizzato se è impostato il flag Animazione nel blocco "VP8X". Se il flag Animazione non è impostato e questo blocco è presente, DEVE essere ignorato.

Blocco "ANMF":

Per le immagini animate, questo blocco contiene informazioni su un singolo frame. Se il flag dell'animazione non è impostato, questo blocco NON DOVREBBE essere presente.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ANMF')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Frame X                |             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...          Frame Y            |   Frame Width Minus One     ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...             |           Frame Height Minus One              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Frame Duration                |  Reserved |B|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                         Frame Data                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame X: 24 bit (uint24)
La coordinata X dell'angolo in alto a sinistra del frame è Frame X * 2.
Frame Y: 24 bit (uint24)
La coordinata Y dell'angolo in alto a sinistra del frame è Frame Y * 2.
Larghezza frame meno uno: 24 bit (uint24)
La larghezza in base a del frame. La larghezza del frame è 1 + Frame Width Minus One.
Altezza frame meno uno: 24 bit (uint24)
L'altezza in base a 1 del frame. L'altezza del frame è 1 + Frame Height Minus One.
Durata frame: 24 bit (uint24)
Il tempo di attesa prima di visualizzare il frame successivo, in unità da 1 millisecondo. Tieni presente che l'interpretazione della durata frame pari a 0 (e spesso <= 10) è definita dall'implementazione. Molti strumenti e browser assegnano una durata minima simile alla GIF.
Riservato: 6 bit
DEVE essere 0. I lettori DEVONO ignorare questo campo.
Metodo di fusione (B): 1 bit

Indica come i pixel trasparenti del frame corrente devono essere uniti ai pixel corrispondenti del canvas precedente:

  • 0: usa l'alpha-blending. Dopo aver eliminato il frame precedente, esegui il rendering del frame corrente sul canvas utilizzando l'alpha-blending (vedi sotto). Se il frame corrente non ha un canale alfa, supponiamo che il valore alfa sia 255, sostituendo di fatto il rettangolo.

  • 1: non unire. Dopo aver eliminato il frame precedente, visualizza il frame corrente sul canvas sovrascrivendo il rettangolo coperto dal frame corrente.

Metodo di smaltimento (D): 1 bit

Indica come il frame corrente deve essere trattato dopo che è stato visualizzato (prima di eseguire il rendering del frame successivo) sul canvas:

  • 0: non smaltire. Lascia invariata la tela.

  • 1: smaltisci in base al colore di sfondo. Riempi il rettangolo sul canvas coperto dal frame corrente con il colore di sfondo specificato nel blocco "ANIM".

Note:

  • Lo smaltimento del frame si applica solo al rettangolo del frame, ovvero al rettangolo definito da Frame X, Frame Y, larghezza del frame e altezza frame. Potrebbe coprire o meno l'intera tela.

  • Alpha-blending:

    Dato che ciascuno dei canali R, G, B e A è a 8 bit e i canali RGB non sono premoltiplicati tramite alfa, la formula per combinare "dst" in "src" è:

    blend.A = src.A + dst.A * (1 - src.A / 255)
if blend.A = 0 then
  blend.RGB = 0
else
  blend.RGB =
      (src.RGB * src.A +
       dst.RGB * dst.A * (1 - src.A / 255)) / blend.A

  • La combinazione dell'alpha DEVE essere eseguita nello spazio colore lineare, tenendo conto del profilo colore dell'immagine. Se il profilo di colore non è presente, si deve utilizzare la tecnologia RGB standard (sRGB). Tieni presente che anche sRGB deve essere linearizzato a causa di una gamma di ~2,2.

Dati frame: Dimensione blocco - 16 byte

Composta da:

Nota: il payload "ANMF", Frame Data, è costituito da singoli blocchi riempiti, come descritto nel formato file RIFF.

Alpha

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ALPH')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv| P | F | C |     Alpha Bitstream...                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Riservato (Rsv): 2 bit
DEVE essere 0. I lettori DEVONO ignorare questo campo.
Pre-elaborazione (P): 2 bit

Questi bit informativi vengono utilizzati per segnalare la pre-elaborazione eseguita durante la compressione. Il decoder può usare queste informazioni, ad esempio, per applicare il dithering dei valori o attenuare i gradienti.

  • 0: nessuna pre-elaborazione.
  • 1: riduzione del livello.

I decoder non sono tenuti a utilizzare queste informazioni in alcun modo specificato.

Metodo di filtro (F): 2 bit

I metodi di filtro utilizzati sono descritti come segue:

  • 0: nessuno.
  • 1: filtro orizzontale.
  • 2: filtro verticale.
  • 3: filtro gradiente.

Per ogni pixel, il filtro viene eseguito utilizzando i calcoli riportati di seguito. Supponi che i valori alfa che circondano la posizione X corrente siano etichettati come:

 C | B |
---+---+
 A | X |

Cerchiamo di calcolare il valore alfa nella posizione X. Innanzitutto, viene eseguita una previsione in base al metodo di filtro:

  • Metodo 0: predittore = 0
  • Metodo 1: predittivo = A
  • Metodo 2: predittivo = B
  • Metodo 3: predittivo = clip(A + B - C)

dove clip(v) è uguale a:

  • 0 se v < 0,
  • 255 se v > 255 oppure
  • V altrimenti

Il valore finale viene ottenuto aggiungendo il valore decompresso X al predittore e utilizzando l'aritmetica del modulo-256 per inserire l'intervallo [256..511] in [0..255] uno:

alpha = (predictor + X) % 256

Esistono casi speciali per le posizioni dei pixel più a sinistra e più in alto. Ad esempio, il valore in alto a sinistra nella posizione (0, 0) utilizza 0 come valore predittivo. Altrimenti:

  • Per i metodi di filtro orizzontale o a gradiente, i pixel più a sinistra nella posizione (0, y) vengono previsti utilizzando la posizione (0, y-1) appena sopra.
  • Per i metodi di filtro verticale o gradiente, i pixel più in alto nella posizione (x, 0) vengono previsti utilizzando la posizione (x-1, 0) a sinistra.
Metodo di compressione (C): 2 bit

Il metodo di compressione utilizzato:

  • 0: nessuna compressione.
  • 1: compressione mediante il formato senza perdita di dati WebP.
Flusso di bit alpha: Dimensione blocco - 1 byte

Flusso di bit alpha codificato.

Questo blocco facoltativo contiene dati alpha codificati per questo frame. Un frame contenente un blocco "VP8L" NON DEVE contenere questo blocco.

Motivazione: le informazioni sulla trasparenza fanno già parte del gruppo "VP8L".

I dati del canale alfa vengono archiviati come dati non compressi non compressi (quando il metodo di compressione è "0") o compressi utilizzando il formato senza perdita di dati (quando il metodo di compressione è "1").

  • Dati non elaborati: sono costituiti da una sequenza di byte di lunghezza = larghezza * altezza, contenente tutti i valori di trasparenza a 8 bit nell'ordine di analisi.

  • Compressione dei formati senza perdita di dati: la sequenza di byte è un flusso di immagini compresso (come descritto in "Formato WebP Lossless Bitstream") di dimensioni implicite larghezza x altezza. Ciò significa che questo flusso di immagini NON contiene intestazioni che descrivono le dimensioni dell'immagine.

    Motivazione: le dimensioni sono già note da altre origini, pertanto archiviarle di nuovo sarebbe ridondante e soggetta a errori.

    Una volta decodificato il flusso di immagini nei valori di colore Alpha, Red, Green, Blue (ARGB), seguendo il processo descritto nella specifica del formato senza perdita di dati, le informazioni sulla trasparenza devono essere estratte dal canale verde della quadrupla ARGB.

    Motivazione: il canale verde è consentito in passaggi di trasformazione aggiuntivi nella specifica, a differenza degli altri canali, che possono migliorare la compressione.

Bitstream (VP8/VP8L)

Questo blocco contiene dati bitstream compressi per un singolo frame.

Un blocco di bitstream può essere (i) un blocco "VP8", che utilizza "VP8" (nota lo spazio di quarto carattere significativo) come FourCC, oppure (ii) un blocco "VP8L", utilizzando "VP8L" come FourCC.

I formati dei blocchi "VP8" e "VP8L" sono descritti, rispettivamente, nelle sezioni Formato di file semplice (Lossy) e Formato di file semplice (senza perdita).

Profilo colore

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ICCP')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                       Color Profile                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Profilo colore: dimensione Chunk byte
Profilo ICC.

Questo blocco DEVE apparire prima dei dati dell'immagine.

DEVE essere presente al massimo un blocco di questo tipo. Se ci sono più blocchi di questo tipo, i lettori POSSONO ignorare tutti tranne il primo. Consulta la Specifica ICC per maggiori dettagli.

Se questo blocco non è presente, DOVE essere presumibile sRGB.

Metadati

I metadati possono essere archiviati in blocchi "EXIF" o "XMP".

DOVREBBE essere presente al massimo un blocco di ogni tipo ("EXIF" e "XMP"). Se ci sono più blocchi di questo tipo, i lettori POSSONO ignorare tutti tranne il primo.

I blocchi sono definiti come segue:

Blocco "EXIF":

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('EXIF')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        Exif Metadata                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Metadati EXIF: dimensioni blocco byte
Metadati delle immagini in formato EXIF.

Blocco "XMP":

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('XMP ')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        XMP Metadata                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Metadati XMP: dimensioni blocco byte
Metadati delle immagini in formato XMP.

Notate che il quarto carattere nel FourCC 'XMP ' è uno spazio ASCII (0x20).

Ulteriori indicazioni sulla gestione dei metadati sono disponibili nelle "Linee guida per la gestione dei metadati" del Gruppo di lavoro sui metadati.

Blocchi sconosciuti

Un blocco RIFF (descritto nella sezione Formato file RIFF) il cui FourCC è diverso da uno qualsiasi dei blocchi descritti in questo documento viene considerato un blocco sconosciuto.

Motivazione: l'autorizzazione di blocchi sconosciuti consente di prevedere un'estensione futura del formato e di archiviare dati specifici dell'applicazione.

Un file POTREBBE contenere blocchi sconosciuti:

I lettori DEVONO ignorare questi blocchi. Gli autori DEVONO conservarli nel loro ordine originale (a meno che non intendano modificare specificamente questi blocchi).

Gruppo canvas dalle cornici

Qui forniamo una panoramica di come un lettore DEVE assemblare una tela nel caso di un'immagine animata.

Il processo inizia con la creazione di un canvas utilizzando le dimensioni specificate nel blocco "VP8X", ovvero Canvas Width Minus One + 1 pixel di larghezza per Canvas Height Minus One + 1 pixel di altezza. Il campo Loop Count del blocco "ANIM" controlla quante volte viene ripetuto il processo di animazione. Il valore è Loop Count - 1 per i valori Loop Count diversi da zero o infinito se il valore di Loop Count è zero.

All'inizio di ogni iterazione in loop, il canvas viene riempito con il colore di sfondo del blocco "ANIM" o un colore definito dall'applicazione.

I blocchi "ANMF" contengono singoli frame indicati nell'ordine di visualizzazione. Prima di eseguire il rendering di ogni frame, viene applicato il valore Disposal method del frame precedente.

Il rendering del frame decodificato inizia in base alle coordinate cartesiane (2 * Frame X, 2 * Frame Y), utilizzando l'angolo in alto a sinistra del canvas come origine. Il rendering di Frame Width Minus One + 1 pixel di larghezza per Frame Height Minus One + 1 pixel di altezza nella tela viene eseguito utilizzando Blending method.

La tela viene visualizzata per Frame Duration millisecondi. L'operazione continua fino a quando non vengono visualizzati tutti i frame forniti dai blocchi "ANMF". Viene quindi avviata una nuova iterazione del loop oppure il canvas rimane nello stato finale se tutte le iterazioni sono state completate.

Il seguente pseudocodice illustra il processo di rendering. La notazione VP8X.field indica il campo nel blocco "VP8X" con la stessa descrizione.

VP8X.flags.hasAnimation MUST be TRUE
canvas ← new image of size VP8X.canvasWidth x VP8X.canvasHeight with
         background color ANIM.background_color.
loop_count ← ANIM.loopCount
dispose_method ← Dispose to background color
if loop_count == 0:
  loop_count = ∞
frame_params ← nil
next chunk in image_data is ANMF MUST be TRUE
for loop = 0..loop_count - 1
  clear canvas to ANIM.background_color or application-defined color
  until eof or non-ANMF chunk
    frame_params.frameX = Frame X
    frame_params.frameY = Frame Y
    frame_params.frameWidth = Frame Width Minus One + 1
    frame_params.frameHeight = Frame Height Minus One + 1
    frame_params.frameDuration = Frame Duration
    frame_right = frame_params.frameX + frame_params.frameWidth
    frame_bottom = frame_params.frameY + frame_params.frameHeight
    VP8X.canvasWidth >= frame_right MUST be TRUE
    VP8X.canvasHeight >= frame_bottom MUST be TRUE
    for subchunk in 'Frame Data':
      if subchunk.tag == "ALPH":
        alpha subchunks not found in 'Frame Data' earlier MUST be
          TRUE
        frame_params.alpha = alpha_data
      else if subchunk.tag == "VP8 " OR subchunk.tag == "VP8L":
        bitstream subchunks not found in 'Frame Data' earlier MUST
          be TRUE
        frame_params.bitstream = bitstream_data
    render frame with frame_params.alpha and frame_params.bitstream
      on canvas with top-left corner at (frame_params.frameX,
      frame_params.frameY), using Blending method
      frame_params.blendingMethod.
    canvas contains the decoded image.
    Show the contents of the canvas for
    frame_params.frameDuration * 1 ms.
    dispose_method = frame_params.disposeMethod

Layout di file di esempio

Un'immagine con codifica con perdita di dati e alpha può avere il seguente aspetto:

RIFF/WEBP
+- VP8X (descriptions of features used)
+- ALPH (alpha bitstream)
+- VP8 (bitstream)

Un'immagine con codifica senza perdita di dati può avere il seguente aspetto:

RIFF/WEBP
+- VP8X (descriptions of features used)
+- VP8L (lossless bitstream)
+- XYZW (unknown chunk)

Un'immagine senza perdita di dati con un profilo ICC e metadati XMP può avere il seguente aspetto:

RIFF/WEBP
+- VP8X (descriptions of features used)
+- ICCP (color profile)
+- VP8L (lossless bitstream)
+- XMP  (metadata)

Un'immagine animata con metadati EXIF può avere il seguente aspetto:

RIFF/WEBP
+- VP8X (descriptions of features used)
+- ANIM (global animation parameters)
+- ANMF (frame1 parameters + data)
+- ANMF (frame2 parameters + data)
+- ANMF (frame3 parameters + data)
+- ANMF (frame4 parameters + data)
+- EXIF (metadata)