Introduzione
WebP è un formato di immagine che utilizza (i) la codifica dei fotogrammi chiave VP8 per comprimere i dati delle immagini con perdita di dati o (ii) la codifica WebP senza perdita di dati. 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 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 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 un supporto aggiuntivo per quanto segue:
Compressione senza perdita di dati: un'immagine può essere compressa senza perdita di dati utilizzando il formato WebP Lossless.
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 può 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 utilizzare i seguenti tipi quando si fa riferimento al contenitore WebP:
| Nome del formato del contenitore | WebP |
| Estensione nome file | .webp |
| Tipo MIME | image/webp |
| Uniform Type Identifier | org.webmproject.webp |
Terminologia e nozioni di base
Le parole chiave "DEVE", "NON DEVE", "OBBLIGATORIO", "DEVE", "NON DEVE", "DEVE", "NON DEVE", "CONSIGLIATO", "NON CONSIGLIATO", "PUÒ" e "FACOLTATIVO" in questo documento devono essere interpretate come descritto in BCP 14 RFC 2119 RFC 8174 quando e solo quando vengono visualizzate in maiuscolo, come mostrato qui.
Un file WebP contiene un'immagine fissa (ovvero una matrice codificata di pixel) o un'animazione. Se vuoi, puoi anche includere informazioni sulla trasparenza, un profilo di colore e metadati. La matrice dei pixel è la canvas dell'immagine.
La numerazione dei bit nei diagrammi di blocchi inizia da 0 per il bit più significativo
('MSB 0'), come descritto in RFC 1166.
Di seguito sono riportati altri termini utilizzati in questo documento:
- Lettore/scrittore
- Il codice che legge i file WebP è definito lettore, mentre il codice che li scrive è denominato writer.
- uint16
- Un numero intero non firmato a 16 bit in little-endian.
- uint24
- Un numero intero non firmato a 24 bit in little endian.
- uint32
- Un numero intero non firmato a 32 bit in little-endian.
- FourCC
- Un codice di quattro caratteri (FourCC) è un uint32 creato concatenando quattro caratteri ASCII in ordine little-endian. Ciò significa che "aaaa" (0x61616161) e "AAAA" (0x41414141) vengono trattati come FourCCs diversi.
- In base a 1
- 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 di documento RIFF (Resource Interchange File Format).
L'elemento 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, l'identificatore del blocco o la spaziatura interna.
- Payload del chunk: Dimensione del chunk byte
- Il payload di dati. Se il valore Chunk Dimensione è dispari, viene aggiunto un singolo byte di spaziatura interna, che DEVE essere
0per essere conforme al RIFF.
Nota: RIFF prevede una convenzione per cui i chunk FourCC 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 del 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". La dimensione del file nell'intestazione è la dimensione totale dei blocchi che seguono più 4 byte per il FourCC "WEBP". 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 chunk è pari, anche la dimensione indicata dall'intestazione RIFF è pari. 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 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: Dimensione 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. Per convertirlo in RGB, DEVE essere utilizzato 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 di dati)
Nota: i lettori meno recenti potrebbero non supportare i file nel formato lossless.
Questo layout DEVE essere utilizzato se l'immagine richiede una 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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk "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. Tieni presente che l'intestazione VP8L contiene la larghezza e l'altezza dell'immagine VP8L. ovvero la larghezza e l'altezza del canvas.
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 blocco "ANIM" facoltativo con i dati di controllo dell'animazione.
Dati immagine.
Un chunk "EXIF" facoltativo con metadati EXIF.
Un chunk "XMP" facoltativo con metadati XMP.
Un elenco facoltativo di chunk sconosciuti.
Per un'immagine statica, i dati immagine sono costituiti da un singolo frame, composto da:
Un blocco secondario 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 frammenti 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 a leggere quando i chunk necessari per la ricostruzione e la correzione del colore non sono in ordine.
I metadati e i chunk sconosciuti POTREBBERO non essere in 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 dei blocchi personalizzati in base all'implementazione.
Intestazione del 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 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
- Imposta se il file contiene metadati XMP.
- Animazione (A): 1 bit
- Imposta 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 tela 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 del canvas in pixel in base a uno.
L'altezza effettiva della tela è
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".
Blocco "ANIM":
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 del canvas in ordine di byte [Blu, Verde, Rosso, Alfa]. Questo colore POTREBBE essere utilizzato per riempire lo spazio inutilizzato sulla tela
circa i frame, nonché i pixel trasparenti del primo frame.
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 e non sono tenute a utilizzarlo.
La tela viene cancellata all'inizio di ogni ciclo. Il colore di sfondo PUÒ essere utilizzato per ottenere questo risultato.
- Conteggio loop: 16 bit (uint16)
- Il numero di volte in cui eseguire il loop dell'animazione. Se è
0, significa infinitamente.
Questo blocco DEVE essere visualizzato se è impostato il flag Animation nel Chunk "VP8X". Se il flag Animation non è impostato e questo chunk è 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 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 struttura meno uno: 24 bit (uint24)
- La larghezza basata su 1 del frame.
La larghezza del frame è
1 + Frame Width Minus One. - Altezza struttura meno uno: 24 bit (uint24)
- L'altezza in base a uno del frame.
L'altezza della cornice è
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 del frame pari a 0 (e spesso <= 10) è definita 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 fusione (B): 1 bit
Indica in che modo i pixel trasparenti del frame corrente devono essere miscelati con i pixel corrispondenti della tela precedente:
0: usa alpha-blending. Dopo aver eliminato il frame precedente, esegui il rendering del frame corrente sulla tela utilizzando l'alpha blending (vedi di seguito). Se il frame corrente non ha un canale alfa, si presume che il valore alfa sia 255, sostituendo effettivamente il rettangolo.1: non mescolare. 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 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.
Fusione alfa:
Dato che ciascuno dei canali R, G, B e A è a 8 bit e che i canali RGB non sono 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.ALa combinazione alpha DEVE essere eseguita nello spazio 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: 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: il payload "ANMF", Frame Data, è costituito da singoli frammenti con spaziatura, 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 decoder può usare queste informazioni, ad esempio, per eseguire il dithering dei valori o per sfumare i gradienti 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 filtrazione (F): 2 bit
I metodi di filtro utilizzati sono descritti di seguito:
0: nessuno.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 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 fatta una previsione in base al metodo di filtrazione:
- Metodo
0: predittore = 0 - Metodo
1: predictor = A - Metodo
2: predittore = B - Metodo
3: predictor = 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 scompresso X al predittore e utilizzando l'aritmetica modulo 256 per avvolgere l'intervallo [256..511] in quello [0..255]:
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 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: compresso utilizzando il formato WebP lossless.
- Bitstream alpha: Dimensione chunk in byte -
1 Bitstream alpha codificato.
Questo chunk facoltativo contiene i dati alfa codificati per questo frame. Un frame contenente un Chunk "VP8L" NON DEVE contenere questo blocco.
Motivazione: le informazioni sulla trasparenza fanno già parte del modulo "VP8L".
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: 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. Ciò significa che questo flusso di immagini 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.
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: 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 blocco contiene dati di flussi di bit compressi per un singolo frame.
Un blocco di bitstream può essere (i) un Chunk "VP8", utilizzando "VP8" (nota il significativo spazio di quarto carattere) come FourCC oppure (ii) un Chunk "VP8L", utilizzando "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 informazioni dettagliate, consulta la specifica ICC.
Se questo blocco non è presente, DEVE essere usato il valore sRGB.
Metadati
I metadati possono essere archiviati in blocchi "EXIF" o "XMP".
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 chunk sono definiti come segue:
Unità "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: Dimensioni chunk in byte
- Metadati delle immagini in formato XMP.
Tieni presente che il quarto carattere del codice 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 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 nella sezione Intestazione del file WebP, oppure
- alla fine dei chunk "ANMF", come descritto nella sezione Animazione.
I lettori DEVONO ignorare questi blocchi. Gli autori DOVREBBERO conservarli nell'ordine originale (a meno che non intendano specificamente modificare questi blocchi).
Assemblaggio di Canvas 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 'elemento "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. Si tratta di 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 del 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 continua finché non vengono visualizzati tutti i frame forniti dai chunk "ANMF". 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 il processo 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 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)