Specifiche container WebP

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 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 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 immagine 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 contenere metadati archiviati nel file di immagine scambiabile Formato (Exif) o Extensible Metadata Platform (XMP).

• Trasparenza: un'immagine può avere trasparenza, ossia un canale alfa.

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

• Animazione: un'immagine può avere più frame con una pausa tra loro. trasformandola in un'animazione.

Denominazione

È CONSIGLIATO di usare i seguenti tipi quando fai riferimento al WebP contenitore:

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. 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 di blocchi inizia da 0 per il bit più significativo ("MSB 0"), come descritto in 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 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. Significa "aaaa". (0x61616161) e "AAAA" (0x41414141) vengono trattate come FourCCs diverse.

In base a uno

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 le intestazioni FourCC e Chunk Dimensione dei singoli blocchi, dove "ABCD" è il FourCC per il chunk. La dimensione di questo elemento è di 8 byte.

Formato file RIFF

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

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 a quattro caratteri utilizzato per l'identificazione del blocco.

Dimensione chunk: 32 bit (uint32)

La dimensione del blocco in byte, escluso questo campo e il blocco o spaziatura interna.

Payload chunk: dimensione blocco byte

Il payload dei dati. Se il valore Chunk Dimensione è dispari, un singolo byte di spaziatura interna, che DEVE essere 0 per essere conforme al RIFF -- viene aggiunto.

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 di 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 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 blocco è pari, la dimensione fornita dall'intestazione RIFF è in modo uniforme. I contenuti dei singoli blocchi sono descritti di seguito sezioni.

Formato file semplice (perdita)

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 da software meno recenti.

Formato file WebP semplice (con perdita):

 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                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"VP8" 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('VP8 ')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                           VP8 data                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Dati VP8: dimensione blocco byte

Dati bitstream VP8.

Il quarto carattere nella tabella "VP8 " FourCC è uno spazio ASCII (0x20).

La specifica del formato bitstream VP8 è descritta nella sezione Formato dati VP8 e Guida alla decodifica. Si noti che l'intestazione del frame VP8 contiene il frame VP8 e larghezza e altezza. 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 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: dimensioni blocco byte

Dati bitstream VP8L.

Le specifiche attuali del bitstream VP8L sono disponibili all'indirizzo Formato Bitstream senza perdita di dati WebP. L'intestazione VP8L contiene la larghezza e l'altezza dell'immagine VP8L. che si presume sia 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 esteso è costituito da:

• Un file "VP8X" Chunk con informazioni sulle caratteristiche utilizzate nel file.

• Un "ICCP" facoltativo Gruppo con un profilo di colore.

• Una "ANIM" facoltativa Chunk con 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.

• Un subchunk bitstream.

Per un'immagine animata, i dati immagine sono costituiti da più frame. Altro 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", DEVE comparire 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 blocchi sconosciuti POTREBBERO apparire fuori da 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 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

Indica se il file contiene metadati XMP.

Animazione (A): 1 bit

Imposta questo valore se si tratta di un'immagine animata. Dati in "ANIM" e "ANMF" I chunk dovrebbero essere utilizzata 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 del canvas in pixel in base a uno. 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 da "ANIM" e "ANMF" Pezzi.

"ANIM" Unità:

Per un'immagine animata, questo blocco contiene i parametri globali del metodo 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 POTREBBE contenere un valore alfa non opaco, anche se il flag Alpha in "VP8X" Il blocco 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 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 il flag Animation nella sezione "VP8X" Il chunk è impostato. Se il flag Animation non è impostato e questo blocco è presente, DEVE essere ignorato.

"ANMF" Unità:

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 del frame è Frame Y * 2.

Larghezza telaio meno uno: 24 bit (uint24)

La larghezza in base a uno 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 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 un numero simile a quella del GIF.

Riservato: 6 bit

DEVE essere 0. I lettori DEVONO ignorare questo campo.

Metodo di fusione (B): 1 bit

Indica come unire 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 mescolare. 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 che è stato visualizzate (prima di visualizzare il frame successivo) sulla tela:

• 0: non smaltire. Lascia invariata la tela.

• 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.

• 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.A
  

• La 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: dimensione blocco - 16 byte

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.

Pre-elaborazione (P): 2 bit

Questi bit informativi vengono utilizzati per segnalare la pre-elaborazione che ha 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 pre-elaborazione.
• 1: riduzione di 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 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, una previsione è in base al metodo di filtro:

• Metodo 0: predittore = 0
• Metodo 1: predittore = 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 gradiente, i pixel più in alto nella le posizioni (x, 0) vengono previste 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.

Flusso di bit alpha: Dimensioni blocco - 1 byte

Alpha bitstream codificato.

Questo blocco facoltativo contiene 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: 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 archiviarli di nuovo sarebbe ridondante e soggetta a errori.

  Dopo aver decodificato lo stream di immagini 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: 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 blocco contiene dati di flussi di bit compressi per un singolo frame.

Un blocco bitstream può essere (i) un "VP8" Chunk, utilizzando "VP8 " (tieni presente che uno spazio significativo di quarto carattere) come FourCC o (ii) un valore "VP8L" Chunk, utilizzando "VP8L" come FourCC.

I formati di "VP8" e "VP8L" I chunk sono descritti nelle sezioni Formato file semplice (perdita) e Simple File Format (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 blocco DEVE essere visualizzato 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 informazioni dettagliate, 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.

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 blocchi sono definiti come segue:

"EXIF" 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('EXIF')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        Exif Metadata                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Metadati EXIF: Dimensioni blocco 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 nel "Linee guida per la gestione dei metadati" di Metadata Working Group.

Chunk sconosciuti

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

Motivazione: consentire l'utilizzo di blocchi sconosciuti consente di eseguire estensioni future del formato e consente anche l'archiviazione dei dati specifici dell'applicazione.

Un file POTREBBE contenere blocchi 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 un canvas utilizzando le dimensioni specificate nel "VP8X" Unità, Canvas Width Minus One + 1 pixel di larghezza per 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 in loop, il canvas viene riempito utilizzando il colore di sfondo della "ANIM" Un chunk 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 del canvas come origine. Frame Width Minus One + 1 pixel di larghezza per Frame Height Minus One + 1 pixel alti 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. Una nuova iterazione in loop è o 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 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ò 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 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)