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 dovrebbero renderlo più efficiente rispetto ai 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 ha la parità di funzionalità (profilo di colore, metadati, animazioni, ecc.) anche con altri formati. Questo documento descrive la struttura di un file WebP.
Il contenitore WebP (ovvero il contenitore RIFF per WebP) consente il supporto di funzionalità oltre il caso d'uso di base di WebP (ovvero un file contenente una singola immagine codificata come frame 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 contenere metadati archiviati nel file di immagine scambiabile Formato (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 del formato del contenitore | WebP |
| Estensione nome file | .webp |
| MIME-type | immagine/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 solo quando e quando vengono visualizzati in maiuscolo, come mostrato qui.
Un file WebP contiene un'immagine statica (ovvero una matrice codificata di pixel) o un'animazione. Se vuoi, puoi anche includere informazioni sulla trasparenza, 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 altri termini utilizzati in questo documento:
- Lettore/autore
- Il codice che legge i file WebP è definito lettore, mentre il codice che li scrive è definito writer.
- uint16
- Un numero intero senza segno, small-endian a 16 bit.
- uint24
- Un numero intero senza segno, small-endian a 24 bit.
- uint32
- Un numero intero senza segno, small-endian a 32 bit.
- 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 uno
- Ad esempio, un campo di interi non firmati che memorizza valori con un offset di
-1memorizzerebbe il valore 25 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 file RIFF (Resource Interchange File Format) formato documento.
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 blocco o spaziatura interna.
- Payload del chunk: Dimensioni chunk byte
- Il payload dei dati. Se Dimensione chunk è dispari, viene aggiunto un singolo byte di riempimento, che DEVE essere
0per essere conforme a RIFF.
Nota: RIFF segue una convenzione secondo cui i FourCC con blocchi tutto maiuscolo sono standard che si applicano a qualsiasi formato di file RIFF, mentre i componenti FourCC specifici di un file sono tutte minuscole. 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, pertanto le dimensioni dell'intero file non superano i 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 codice FourCC "WEBP". 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 i dati
specificate in base alle dimensioni del file. I lettori POSSONO analizzare questi file, ignorando le
e i dati di Google Cloud. Poiché la dimensione di qualsiasi chunk è pari, anche la dimensione indicata dall'intestazione RIFF è pari. I contenuti dei singoli blocchi sono descritti di seguito
sezioni.
Formato file semplice (con perdita di dati)
Questo layout DEVE essere utilizzato se l'immagine richiede una codifica con perdita e non richiede trasparenza o altre funzionalità avanzate fornite dal formato esteso. I file con questo layout sono più piccoli e 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: Dimensioni chunk in byte
- Dati del flusso di bit VP8.
Tieni presente che il quarto carattere del codice FourCC "VP8" è uno spazio ASCII (0x20).
La specifica del formato bitstream VP8 è descritta nella sezione Formato dati VP8 e Guida alla decodifica. 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.
La specifica VP8 descrive come decodificare l'immagine in formato Y'CbCr. A convertire in RGB, DOVREBBE utilizzare il Recommendation BT.601. Le applicazioni POSSONO utilizzare un altro metodo di conversione, ma i risultati visivi possono variare in base ai decodificatori.
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: Dimensione chunk in byte
- Dati dello stream di bit VP8L.
La specifica attuale del flusso di bit VP8L è disponibile all'indirizzo WebP Lossless Bitstream Format. 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 chunk "ICCP" facoltativo con un profilo di colore.
Un chunk "ANIM" facoltativo con i dati di controllo dell'animazione.
Dati immagine.
Un chunk "EXIF" facoltativo 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 blocco secondario alpha facoltativo.
Per un'immagine animata, i dati immagine sono costituiti da più frame. Ulteriori dettagli sui frame sono disponibili nella sezione Animazione.
Tutti i chunk 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 DOVREBBERO non riuscire se i blocchi necessari per la ricostruzione e la correzione del colore non sono nell'ordine corretto.
I metadati e i blocchi sconosciuti POTREBBERO apparire fuori da ordine.
Motivazione: i chunk 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 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 chunk "ICCP".
- Alfa (L): 1 bit
- Imposta se uno o più frame dell'immagine contengono informazioni sulla trasparenza ("alpha").
- Metadati EXIF (E): 1 bit
- Imposta se il file contiene metadati EXIF.
- Metadati XMP (X): 1 bit
- Imposta 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 del canvas è
1 + Canvas Width Minus One. - Altezza canvas meno uno: 24 bit
- Altezza del canvas in pixel in base a uno.
L'altezza effettiva del canvas è
1 + Canvas Height Minus One.
I valori di Larghezza canvas e Altezza canvas DEVONO 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".
Blocco "ANIM":
Per un'immagine animata, questo blocco contiene i parametri globali del l'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 POTREBBE essere utilizzato per riempire lo spazio inutilizzato sulla tela
intorno ai frame, nonché ai pixel trasparenti del primo frame.
Il colore di sfondo viene utilizzato anche quando il metodo di smaltimento è
1.
Nota:
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 e non sono tenute a utilizzarlo.
La tela viene cancellata all'inizio di ogni loop. Il colore di sfondo POTREBBE essere usato per ottenere questo risultato.
- Conteggio loop: 16 bit (uint16)
- Il numero di volte in cui eseguire il loop dell'animazione. Se è
0, significa all'infinito.
Questo blocco DEVE essere visualizzato se il flag Animation nella sezione "VP8X" Il chunk è impostato. 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 del frame è
Frame X * 2. - Frame Y: 24 bit (uint24)
- La coordinata Y dell'angolo in alto a sinistra dell'inquadratura è
Frame Y * 2. - Larghezza telaio meno uno: 24 bit (uint24)
- La larghezza basata su 1 del frame.
La larghezza del frame è
1 + Frame Width Minus One. - Altezza fotogramma meno uno: 24 bit (uint24)
- L'altezza in base a uno del frame.
L'altezza del frame è
1 + Frame Height Minus One. - Durata del 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 frame pari a 0 (e spesso <= 10) è definiti dall'implementazione. Molti strumenti e browser assegnano una durata minima simile a quella delle GIF.
- Riservato: 6 bit
- DEVE essere
0. I lettori DEVONO ignorare questo campo. - Metodo di combinazione (B): 1 bit
Indica come devono essere uniti i pixel trasparenti del frame corrente con i pixel corrispondenti del canvas precedente:
0: usa alpha-blending. 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 il frame corrente sull'area di lavoro 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 invariata la tela.1: elimina il colore di sfondo. Riempi il rettangolo sulla tela coperto dal frame corrente con il colore di sfondo specificato nel chunk "ANIM".
Note:
Lo smaltimento dei frame si applica solo al rettangolo del frame, ovvero al rettangolo definito da Frame X, Frame Y, Larghezza frame e Altezza frame. Potrebbe coprire o meno l'intera tela.
Combinazione alpha:
Considerato che ognuno dei canali R, G, B e A è a 8 bit, e la memoria RGB i canali non vengono premoltiplicati per alfa, la formula per combinare "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.AL'unione alfa DEVE essere eseguita nello spazio di colore lineare, tenendo conto del profilo di colore dell'immagine. Se il profilo di colore non è presente, si presume che sia RGB standard (sRGB). Tieni presente che anche sRGB deve essere linearizzato a causa di una gamma di circa 2,2.
- Dati frame: dimensione blocco byte -
16 Composto da:
Un sottoblocco alfa facoltativo per il frame.
Un subchunk bitstream 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. - Preelaborazione (P): 2 bit
Questi bit informativi vengono utilizzati per segnalare la pre-elaborazione eseguita durante la compressione. Il decodificatore può utilizzare queste informazioni per, ad esempio, applicare il dithering ai valori o smussare i gradienti prima della visualizzazione.
0: nessuna pre-elaborazione.1: riduzione di livello.
I decodificatori non sono tenuti a utilizzare queste informazioni in alcun modo specifico.
- Metodo di filtrazione (F): 2 bit
I metodi di filtro utilizzati sono descritti di seguito:
0: nessuna.1: filtro orizzontale.2: filtro verticale.3: filtro Gradiente.
Per ogni pixel, il filtro viene eseguito utilizzando i seguenti calcoli.
Supponiamo che i valori alfa che circondano la posizione X corrente siano etichettati come:
C | B |
---+---+
A | X |
Cerchiamo di calcolare il valore alpha nella posizione X. Innanzitutto, una previsione è
in base al metodo di filtro:
- 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 con 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 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 elaborati non compressi (quando è "0") o compresso usando il formato senza perdita di dati (quando il metodo di compressione è "1").
Dati non elaborati: si tratta di una sequenza di byte di lunghezza = larghezza * altezza, contenente tutti i valori di trasparenza a 8 bit in ordine di scansione.
Compressione con formato senza perdita di dati: la sequenza di byte è un stream di immagini compresso (come descritto in "Formato stream di bit WebP senza perdita di dati") di dimensioni implicite larghezza x altezza. In altre parole, questo stream di immagini NON contiene intestazioni che descrivono le dimensioni delle immagini.
Motivazione: le dimensioni sono già note da altre fonti, quindi archiviarle di nuovo sarebbe ridondante e soggetta a errori.
Una volta decodificato lo stream di immagini in valori di colore Alpha, Rosso, Verde, Blu (ARGB), seguendo la procedura descritta nella specifica del formato senza perdita di dati, le informazioni sulla trasparenza devono essere estratte dal canale verde del quadruplo ARGB.
Motivazione: per il canale verde sono consentite trasformazioni aggiuntive. passaggi nella specifica, a differenza degli altri canali, 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: Dimensioni chunk in byte
- Profilo ICC.
Questo chunk DEVE apparire prima dei dati dell'immagine.
DOVREBBE esserci al massimo un blocco di questo tipo. Se sono presenti altri blocchi di questo tipo, i lettori possono ignorarli tutti tranne il primo. Per maggiori dettagli, consulta la specifica ICC.
Se questo chunk non è presente, DEBBA essere assunto sRGB.
Metadati
I metadati possono essere archiviati nel file "EXIF" o "XMP" Pezzi.
DEVE essere presente al massimo un blocco di ciascun tipo ("EXIF" e "XMP"). Se ci sono ci sono più blocchi di questo tipo, i lettori POTREBBERO ignorarli tutti tranne il primo.
I chunk 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.
"XMP" 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('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 nelle "Linee guida per la gestione dei metadati" del gruppo di lavoro sui metadati.
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: la possibilità di consentire chunk sconosciuti consente di estendere il formato in futuro e di archiviare eventuali 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 autori DOVREBBERO conservarli nell'ordine originale (a meno che non intendano specificamente modificare questi blocchi).
Assemblaggio della tela da cornici
Di seguito viene fornita una panoramica di come un lettore DEVE assemblare una tela nel caso di un'immagine animata.
Il processo inizia con la creazione di una tela utilizzando le dimensioni indicate nel Chunk "VP8X", Canvas Width Minus One + 1 pixel di larghezza e Canvas Height Minus
One + 1 pixel di altezza. Il campo Loop Count del chunk "ANIM" controlla il numero di volte in cui viene ripetuta la procedura di animazione. 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.
"ANMF" I chunk contengono singoli frame specificati in ordine di visualizzazione. Prima del rendering
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.
La tela viene visualizzata per Frame Duration millisecondi. Questo continua finché non vengono visualizzati tutti i frame forniti dai chunk "ANMF". Una nuova iterazione in loop è
successivamente, oppure la tela viene lasciata nello stato finale se tutte le iterazioni sono state
completata.
Il seguente pseudocodice illustra il processo di rendering. La notazione VP8X.field indica il campo nella sezione "VP8X" Unità 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 di dati e alpha 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 potrebbe 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)