Introduzione
WebP è un formato di immagine che utilizza (i) la codifica del frame chiave VP8 per comprimono i dati delle immagini in modo lossy o (ii) tramite la codifica senza perdita di dati WebP. Questi schemi di codifica devono renderlo più efficiente dei formati precedenti, come JPEG, GIF e PNG. È ottimizzato per il trasferimento rapido delle immagini sulla rete (ad esempio per i siti web). Il formato WebP offre la parità di funzionalità (profilo di colore, metadati, animazione e così via) anche con 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à rispetto al caso d'uso di base di WebP (ovvero un file contenente un singolo codificata come fotogramma chiave VP8). Il contenitore WebP fornisce dati aggiuntivi per quanto riguarda:
Compressione senza perdita: un'immagine può essere compressa senza perdita di dati utilizzando il metodo Formato WebP senza perdita di dati.
Metadati: un'immagine potrebbe avere metadati archiviati nel formato Exchangeable Image File Format (Exif) o Extensible Metadata Platform (XMP).
Trasparenza: un'immagine può avere trasparenza, ovvero un canale alfa.
Profilo colore: un'immagine potrebbe avere un profilo ICC incorporato come descritto dall'International Color Consortium.
Animazione: un'immagine può avere più fotogrammi con interruzioni tra di loro, rendendola un'animazione.
Denominazione
È CONSIGLIATO di usare i seguenti tipi quando fai riferimento al WebP container:
| Nome formato contenitore | WebP |
| Estensione nome file | .webp |
| MIME-type | image/webp |
| Uniform Type Identifier (identificatore del tipo uniforme) | org.webmproject.webp |
Terminologia e Nozioni di base
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "NON DOVREBBE", "CONSIGLIATO", "NON CONSIGLIATO", "MAGGIO" e "FACOLTATIVO" in questo devono essere interpretati come descritto in BCP 14 RFC 2119 RFC 8174 quando e solo quando appaiono in maiuscolo, come mostrato qui.
Un file WebP contiene un'immagine statica (ovvero una matrice codificata di pixel) o un'animazione. Facoltativamente, può contenere anche informazioni, un profilo di colore e metadati. Ci riferiamo alla matrice dei pixel canvas dell'immagine.
La numerazione dei bit nei diagrammi dei chunk inizia da 0 per il bit più significativo
('MSB 0'), come descritto nel documento RFC 1166.
Di seguito sono riportati i termini aggiuntivi utilizzati nel documento:
- Lettore/autore
- Il codice che legge i file WebP è definito lettore, mentre il codice che li scrive è definito writer.
- uint16
- Un numero intero non firmato a 16 bit in little-endian.
- uint24
- Un numero intero senza segno, small-endian a 24 bit.
- uint32
- Un numero intero non firmato a 32 bit in little-endian.
- 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 FourCC diversi.
- In base a 1
- Un campo intero senza segno in cui si memorizza l'offset dei valori di
-1, ad esempio, il valore 25 verrà memorizzato come 24. - ChunkHeader('ABCD')
- Utilizzato per descrivere l'intestazione FourCC e Dimensione chunk dei singoli chunk, dove "ABCD" è il FourCC del chunk. Le dimensioni di questo elemento sono pari a 8 byte.
Formato file RIFF
Il formato file WebP si basa sul formato di documento RIFF (Resource Interchange File Format).
L'elemento di base di un file RIFF è un chunk. Si compone di:
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Chunk FourCC: 32 bit
- Codice ASCII di quattro caratteri utilizzato per l'identificazione dei chunk.
- Dimensione chunk: 32 bit (uint32)
- La dimensione del blocco in byte, escluso questo campo e il valore o spaziatura interna.
- Payload chunk: dimensioni blocco byte
- Il payload di dati. Se Dimensione chunk è dispari, viene aggiunto un singolo byte di riempimento, che DEVE essere
0per essere conforme a RIFF.
Nota: RIFF prevede una convenzione per cui i FourCC dei chunk in maiuscolo sono chunk standard che si applicano a qualsiasi formato file RIFF, mentre i FourCC specifici per un formato file sono tutti in minuscolo. 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 e quindi la dimensione dell'intero file è massimo 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 nome "WEBP" di FourCC. Le dimensioni del file
nell'intestazione è la dimensione totale dei blocchi che seguono più 4 byte per
il "WEBP" FourCC. Il file NON DEVE contenere dati dopo quelli
specificati da Dimensione file. I lettori POSSONO analizzare questi file, ignorando i dati finali. Poiché la dimensione di qualsiasi blocco è pari, la dimensione fornita dall'intestazione RIFF è
in modo uniforme. I contenuti dei singoli chunk sono descritti nelle sezioni seguenti.
Formato file semplice (con perdita di dati)
Questo layout DEVE essere utilizzato se l'immagine richiede la codifica lossy e non richiedono la trasparenza o altre funzionalità avanzate fornite dal formato esteso. I file con questo layout sono più piccoli e supportati dal software precedente.
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: Dimensioni chunk in byte
- Dati bitstream VP8.
Tieni presente che il quarto carattere del codice FourCC "VP8" è uno spazio ASCII (0x20).
La specifica del formato del flusso di bit 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 si tratti della larghezza e dell'altezza della tela.
La specifica VP8 descrive come decodificare l'immagine in formato Y'CbCr. A convertire in RGB, DOVREBBE utilizzare il Recommendation BT.601. Le domande MAGGIO utilizzare un altro metodo di conversione, ma i risultati visivi possono variare da un decoder.
Formato file semplice (senza perdita)
Nota: i lettori meno recenti potrebbero non supportare i file che utilizzano il formato senza perdita di dati.
Questo layout DEVE essere utilizzato se l'immagine richiede la codifica lossless (con un valore canale facoltativo per la trasparenza) e non richiede la fornitura di funzionalità avanzate 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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"VP8L" Unità:
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: Dimensione chunk in byte
- Dati bitstream VP8L.
Le specifiche attuali del bitstream VP8L sono disponibili all'indirizzo Formato Bitstream senza perdita di dati WebP. Tieni presente che l'intestazione VP8L contiene la larghezza e l'altezza dell'immagine VP8L. Si presume che si tratti della larghezza e dell'altezza della tela.
Formato file esteso
Nota: i lettori meno recenti potrebbero non supportare i file che utilizzano il formato esteso.
Un file in formato avanzato è costituito da:
Un chunk "VP8X" con informazioni sulle funzionalità utilizzate nel file.
Un "ICCP" facoltativo Blocco con un profilo di colore.
Un chunk "ANIM" facoltativo con i dati di controllo dell'animazione.
Dati immagine.
Un elemento "EXIF" facoltativo Chunk con metadati EXIF.
Un file "XMP" facoltativo chunk con metadati XMP.
Un elenco facoltativo di chunk sconosciuti.
Per un'immagine statica, i dati immagine sono costituiti da un singolo frame, che viene fatto su:
Un sottoblocco alpha facoltativo.
Per un'immagine animata, i dati di immagine sono costituiti da più fotogrammi. Ulteriori 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 descritti in precedenza. I lettori DOVREBBERO non riuscire se i blocchi necessari per la ricostruzione e la correzione del colore non sono nell'ordine corretto.
I metadati e i chunk sconosciuti POTREBBERO non essere in ordine.
Motivo: le porzioni necessarie per la ricostruzione devono apparire per prime in del file per consentire a un lettore di iniziare a decodificare un'immagine prima di ricevere tutti i i dati. Un'applicazione può trarre vantaggio dalla variazione dell'ordine dei metadati e di chunk personalizzati in base all'implementazione.
Intestazione file WebP estesa:
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 "ICCP" chunk.
- Alfa (L): 1 bit
- Imposta se uno dei frame dell'immagine contiene informazioni sulla trasparenza ("alpha").
- Metadati EXIF (E): 1 bit
- Imposta se il file contiene metadati EXIF.
- Metadati XMP (X): 1 bit
- Indica se il file contiene metadati XMP.
- Animazione (A): 1 bit
- Imposta questo valore se si tratta di un'immagine animata. I dati nei chunk "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 Larghezza
- basata su 1 della tela in pixel.
La larghezza effettiva della tela è
1 + Canvas Width Minus One. - Altezza canvas meno uno: 24 bit Altezza
- basata su 1 della tela in pixel.
L'altezza effettiva del canvas è
1 + Canvas Height Minus One.
Il prodotto di Larghezza tela e Altezza tela DEVE essere al massimo 2^32 - 1.
Le specifiche future potrebbero aggiungere altri campi. I campi sconosciuti DEVONO essere ignorati.
Animazione
Un'animazione è controllata dai chunk "ANIM" e "ANMF".
"ANIM" Unità:
Per un'immagine animata, questo chunk 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 dell'area di disegno nei colori [Blu, Verde, Rosso, Alfa]
in un ordine di byte. Questo colore PUÒ essere utilizzato per riempire lo spazio inutilizzato sulla tela
intorno ai fotogrammi, nonché i pixel trasparenti del primo fotogramma.
Il colore di sfondo viene utilizzato anche quando il metodo di smaltimento è
1.
Note:
Il colore di sfondo PUÒ contenere un valore alpha non opaco, anche se il flag Alpha nel chunk "VP8X" non è impostato.
Le applicazioni di visualizzazione DEVONO trattare il valore del colore di sfondo come un suggerimento non sono tenuti a utilizzarlo.
La tela viene cancellata all'inizio di ogni ciclo. Il colore di sfondo POTREBBE usato per ottenere questo risultato.
- Conteggio loop: 16 bit (uint16)
- Il numero di ripetizioni dell'animazione. Se è
0, significa infinitamente.
Questo chunk DEVE essere visualizzato se è impostato il flag Animation nel chunk "VP8X". Se il flag Animation non è impostato e questo blocco è presente, DEVE essere ignorato.
Blocco "ANMF":
Per le immagini animate, questo chunk contiene informazioni su un singolo frame. Se il flag dell'animazione non è impostato, questo blocco NON DEVE 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 dell'inquadratura è
Frame X * 2. - Frame Y: 24 bit (uint24)
- La coordinata Y dell'angolo in alto a sinistra del frame è
Frame Y * 2. - Larghezza fotogramma meno uno: 24 bit (uint24)
- La larghezza in base a uno del frame.
La larghezza del frame è
1 + Frame Width Minus One. - Altezza frame meno uno: 24 bit (uint24)
- L'altezza basata su 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à di 1 millisecondo. Tieni presente che l'interpretazione della durata del frame pari a 0 (e spesso <= 10) è definita dall'implementazione. Molti strumenti e browser assegnano un numero simile a quella del GIF.
- Riservato: 6 bit
- DEVE essere
0. I lettori DEVONO ignorare questo campo. - Metodo di combinazione (B): 1 bit
Indica in che modo i pixel trasparenti del frame corrente devono essere miscelati con i pixel corrispondenti della tela precedente:
0: utilizza la fusione alfa. Dopo aver eliminato il frame precedente, esegui il rendering frame corrente sul canvas utilizzando la combinazione alpha (vedi sotto). Se il frame corrente non ha un canale alfa, supponiamo che il valore alfa sia 255, sostituendo il rettangolo.1: non unire. Dopo aver eliminato il frame precedente, esegui il rendering del frame corrente sulla tela sovrascrivendo il rettangolo coperto dal frame corrente.
- Metodo di smaltimento (D): 1 bit
Indica come deve essere trattato il frame corrente dopo essere stato visualizzato (prima del rendering del frame successivo) sulla tela:
0: non smaltire. Lascia invariato il canvas.1: elimina il colore di sfondo. Riempi il rettangolare sulla tela coperto dal frame corrente con il colore di sfondo specificato "ANIM" chunk.
Note:
Lo smaltimento dei frame si applica solo al rettangolo del frame, ovvero rettangolo definito da Frame X, Frame Y, larghezza fotogramma e frame altezza. Potrebbe coprire o meno l'intera tela.
Fusione alfa:
Poiché ciascuno dei canali R, G, B e A è di 8 bit e i canali RGB non sono premoltiplicati per alpha, la formula per la miscela 'dst' su '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.ALa combinazione alfabetica DEVE essere eseguita nello spazio colore lineare, tenendo conto il profilo di colore dell'immagine. Se il profilo di colore è non presente, si presume il valore RGB standard (sRGB). Tieni presente che anche sRGB deve essere linearizzato a causa di una gamma di ~2,2).
- Dati frame: Dimensioni chunk in byte -
16 Composto da:
Un subchunk alpha facoltativo per l'inquadratura.
Un sottochunk del flusso di bit per il frame.
Un elenco facoltativo di chunk sconosciuti.
Nota: l'API "ANMF" il payload, Dati frame, è composto da singole di chunk riempiti, come descritto dal 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, puoi applicare il tethering dei valori o attenuare le sfumature prima della visualizzazione.
0: nessuna preelaborazione.1: riduzione di livello.
I decodificatori non sono tenuti a utilizzare queste informazioni in alcun modo specifico.
- Metodo di filtro (F): 2 bit
I metodi di filtro utilizzati sono descritti di seguito:
0: nessuna.1: filtro orizzontale.2: filtro verticale.3: filtro Gradiente.
Per ciascun pixel, l'applicazione di filtri viene eseguita con i calcoli riportati di seguito.
Supponiamo che i valori alpha che circondano la posizione corrente di X siano etichettati come:
C | B |
---+---+
A | X |
Cerchiamo di calcolare il valore alpha nella posizione X. Innanzitutto, viene fatta una previsione in base al metodo di filtrazione:
- Metodo
0: predittore = 0 - Metodo
1: predictor = A - Metodo
2: predittore = B - Metodo
3: predittore = clip(A + B - C)
dove clip(v) è uguale a:
- 0 se v < 0,
- 255 se v > 255 o
- v altrimenti
Il valore finale viene ottenuto aggiungendo il valore decompresso X alla
predittore e utilizzo dell'aritmetica modulo-256 per racchiudere l'intervallo [256..511]
in [0..255]:
alpha = (predictor + X) % 256
Esistono casi speciali per le posizioni dei pixel più a sinistra e più in alto. Per Ad esempio, il valore in alto a sinistra nella posizione (0, 0) utilizza 0 come valore del predittore. Altrimenti:
- Per i metodi di filtro orizzontale o gradiente, i pixel più a sinistra nella le località (0, y) vengono previste utilizzando la posizione (0, y-1) appena sopra.
- Per i metodi di filtro verticale o con 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: viene compresso utilizzando il formato senza perdita di dati WebP.
- Bitstream alpha: Dimensione chunk in byte -
1 Bitstream alfa codificato.
Questo chunk facoltativo contiene i dati alfa codificati per questo frame. Una cornice contenente un carattere "VP8L" Il chunk NON DEVE contenere questo blocco.
Motivazione: le informazioni sulla trasparenza fanno già parte della richiesta "VP8L" Chunk.
I dati del canale alfa vengono memorizzati come dati non compressi (se il metodo di compressione è "0") o compressi utilizzando il formato senza perdita di dati (se 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 scansione.
Compressione del formato senza perdita di dati: la sequenza di byte è una flusso di immagini (come descritto in "Formato Bitstream senza perdita di dati WebP") di dimensioni implicite larghezza x altezza. Vale a dire che image-stream NON contiene intestazioni che descrivono le dimensioni dell'immagine.
Motivazione: le dimensioni sono già note da altre fonti, quindi archiviarle di nuovo sarebbe ridondante e soggetta a errori.
Dopo che lo stream di immagini è stato decodificato nei colori Alfa, Rosso, Verde e Blu (ARGB) seguendo il processo descritto nel formato senza perdita di dati specifica, le informazioni sulla trasparenza devono essere estratte canale verde del quadruplo ARGB.
Motivazione: a differenza degli altri canali, il canale verde è consentito nella specifica per gli ulteriori passaggi di trasformazione che possono migliorare la compressione.
Bitstream (VP8/VP8L)
Questo chunk contiene dati del flusso di bit compressi per un singolo frame.
Un chunk del flusso di bit può essere (i) un chunk "VP8", che utilizza "VP8" (nota lo spazio significativo del quarto carattere) come FourCC, o (ii) un chunk "VP8L", che utilizza "VP8L" come FourCC.
I formati dei chunk "VP8" e "VP8L" sono descritti rispettivamente nelle sezioni Formato file semplice (con perdita di dati) e Formato file semplice (senza perdita di dati).
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 chunk DEVE apparire prima dei dati dell'immagine.
DOVREBBE essere al massimo un blocco di questo tipo. Se ci sono più blocchi di questo tipo, i lettori POTREBBE ignorarle tutte tranne la prima. Per maggiori dettagli, consulta la specifica ICC.
Se questo blocco non è presente, DEVE essere usato il valore sRGB.
Metadati
I metadati possono essere archiviati nel file "EXIF" o "XMP" Pezzi.
DOVREBBE esserci al massimo un chunk di ogni tipo ("EXIF" e "XMP"). Se esistono più chunk di questo tipo, i lettori POSSONO ignorarli 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 chunk in 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: dimensione blocco byte
- Metadati delle immagini in formato XMP.
Tieni presente che il quarto carattere nella sezione "XMP" FourCC è uno spazio ASCII (0x20).
Ulteriori indicazioni sulla gestione dei metadati sono disponibili nel "Linee guida per la gestione dei metadati" di Metadata Working Group.
Blocchi sconosciuti
Un chunk RIFF (descritto nella sezione Formato file RIFF) il cui FourCC è diverso da quello di qualsiasi altro chunk descritto in questo documento è considerato un chunk sconosciuto.
Motivazione: consentire l'utilizzo di blocchi sconosciuti consente di eseguire estensioni future del formato e consente anche di archiviare i dati specifici dell'applicazione.
Un file POTREBBE contenere chunk sconosciuti:
- alla fine del file, come descritto in File WebP esteso intestazione oppure
- alla fine di "ANMF" Chunk, come descritto Animazione.
I lettori DEVONO ignorare questi blocchi. Gli scrittori DEVONO conservarli nella loro nell'ordine originale (a meno che non abbiano intenzione di modificare questi blocchi).
Assemblaggio della tela da cornici
Qui forniamo una panoramica di come un lettore DEVE assemblare una tela nella custodia. di un'immagine animata.
Il processo inizia con la creazione di una tela utilizzando le dimensioni indicate nel 'elemento "VP8X", Canvas Width Minus One + 1 pixel di larghezza e Canvas Height Minus
One + 1 pixel di altezza. Il campo Loop Count della "ANIM" Il chunk controlla come
molte volte il processo di animazione si ripete. Questo è Loop Count - 1 per
valori Loop Count diversi da zero o infinito se Loop Count è zero.
All'inizio di ogni iterazione del loop, la tela viene riempita utilizzando il colore di sfondo del chunk "ANIM" o un colore definito dall'applicazione.
I chunk "ANMF" contengono singoli frame nell'ordine di visualizzazione. Prima di eseguire il rendering di ogni frame, viene applicato il Disposal method del frame precedente.
Il rendering del frame decodificato inizia dalle coordinate cartesiane (2 *
Frame X, 2 * Frame Y), utilizzando l'angolo in alto a sinistra della tela come origine.
Frame Width Minus One + 1 pixel di larghezza e Frame Height Minus One + 1 pixel di altezza vengono visualizzati sulla tela utilizzando Blending method.
Il canvas viene visualizzato per Frame Duration millisecondi. Questo processo continua fino a
tutti i frame forniti da "ANMF" I chunk sono stati visualizzati. Viene quindi avviata una nuova iterazione del loop oppure la tela viene lasciata nel suo stato finale se tutte le iterazioni sono state completate.
Il seguente pseudocodice illustra la procedura di rendering. La notazione VP8X.field indica il campo nel chunk "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 or
application-defined 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
apply dispose_method.
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 e alfa potrebbe avere il seguente aspetto:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ALPH (alpha bitstream)
+- VP8 (bitstream)
Un'immagine con codifica senza perdita di dati potrebbe 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ò avrà il seguente aspetto:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ICCP (color profile)
+- VP8L (lossless bitstream)
+- XMP (metadata)
Un'immagine animata con metadati EXIF potrebbe 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)