Especificação de contêiner WebP

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Introdução

WebP é um formato de imagem que usa (i) a codificação de frame de chave VP8 para compactar dados de imagem com perda ou (ii) a codificação sem perda do WebP e, possivelmente, outras codificações no futuro. Esses esquemas de codificação precisam tornar os formatos mais eficientes do que os atualmente usados. Ele é otimizado para uma transferência rápida de imagens pela rede (por exemplo, sites). O formato WebP tem paridade de recursos (perfil de cor, metadados, animação etc.) com outros formatos também. Este documento descreve a estrutura de um arquivo WebP.

O contêiner do WebP (ou seja, O contêiner RIFF para WebP) permite a compatibilidade com recursos acima e acima do caso de uso básico de WebP (ou seja, um arquivo que contém uma única imagem codificada como frame-chave VP8). O contêiner do WebP oferece compatibilidade adicional para:

  • Compactação sem perdas. Uma imagem pode ser compactada sem perdas usando o formato WebP sem perda.

  • Metadados. Uma imagem pode ter metadados armazenados em formatos Exif ou XMP.

  • Transparência. Uma imagem pode ter transparência, ou seja, um canal Alfa.

  • Perfil de cor. Uma imagem pode ter um perfil ICC incorporado conforme descrito pelo International Color Consortium (em inglês).

  • Animação. Uma imagem pode ter vários frames com pausas entre eles, tornando-a uma animação.

As palavras-chave "O que você acha", "O que você pode usar, abaixo, e os resultados abaixo," e os métodos abaixo,

A numeração de bits em diagramas de partes começa em 0 para o bit mais significativo ('MSB 0'), conforme descrito na RFC 1166.

Nomeação

É RECOMENDADO usar os seguintes tipos ao fazer referência ao contêiner WebP:

Nome do formato do contêinerWebP
Extensão do nome de arquivo.webp
Tipo MIMEimagem/webp
Identificador de tipo uniformeorg.webmproject.webp

Terminologia e noções básicas

Um arquivo WebP contém uma imagem estática (ou seja, uma matriz codificada de pixels) ou uma animação. Também é possível que ele contenha informações de transparência, perfil de cor e metadados. Caso precisemos fazer referência apenas à matriz de pixels, vamos chamá-la de tela da imagem.

Veja abaixo os termos adicionais usados neste documento:

Leitor/escritor
O código que lê arquivos WebP é chamado de leitor, enquanto o código que escreve esses arquivos é chamado de escritor.
Uint16 (link em inglês)
Um número inteiro de 16 bits, pequeno e sem assinatura.
Uint24 (link em inglês)
Um número inteiro de 24 bits, pequeno e sem assinatura.
uint32
Um número inteiro de 32 bits, pequeno e sem assinatura.
Quatrocentos
O FourCC (código de quatro caracteres) é um uint32 criado pela concatenação de quatro caracteres ASCII em ordem pequena. Isso significa que 'aaaa' (%x61.61.61.61) e 'AAAA' (%x41.41.41.41) são tratadas como diferentes FourCCs.
Baseada em 1
Um campo de número inteiro não assinado que armazena valores de deslocamento de -1. Por exemplo, Esse campo armazenaria o valor 25 como 24.
ChunkHeader('ABCD')
É usado para descrever o cabeçalho FourCC e Chunk Size de blocos individuais, em que 'ABCD' é o FourCC para o bloco. O tamanho desse elemento é de 8 bytes.

Formato de arquivo RIFF

O formato de arquivo WebP é baseado no formato RIFF (Resource Interchange File Format).

O elemento básico de um arquivo RIFF é um blocos. Ela é composta por:

 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 bits
Código ASCII de quatro caracteres usado para identificação de bloco.
Tamanho do bloco: 32 bits (uint32)
O tamanho do bloco sem incluir este campo, o identificador ou o padding do bloco.
Chunk Payload: tamanho do tamanho do bloco
O payload de dados. Se o Tamanho do pedaço for ímpar, um único byte de padding (que DEVE ser 0 para estar em conformidade com o RIFF) é adicionado. Os aplicativos PODEM usar outro valor, mas os leitores podem não analisar o arquivo.

Observação:o RIFF tem uma convenção de que os blocos FourCCs em letras maiúsculas são blocos padrão que se aplicam a qualquer formato de arquivo RIFF, enquanto os FourCCs específicos de um formato de arquivo são minúsculas. O WebP não segue essa convenção.

Cabeçalho de arquivo 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 bits
Os caracteres ASCII 'R' 'I' 'F' 'F'.
Tamanho do arquivo: 32 bits (uint32)
O tamanho do arquivo em bytes a partir do deslocamento 8. O valor máximo desse campo é 2^32 menos 10 bytes e, portanto, o tamanho do arquivo inteiro é no máximo 4 GiB menos 2 bytes.
'WEBP': 32 bits
Os caracteres ASCII 'W' 'E' 'B' 'P'.

Um arquivo WebP PRECISA começar com um cabeçalho RIFF com FourCC 'WEBP'. O tamanho do arquivo no cabeçalho é o tamanho total dos blocos seguidos, além dos bytes 4 do 'WEBP' FourCC. O arquivo NÃO deve conter nada depois dele. Os leitores podem analisar esses arquivos, ignorando os dados finais. Como o tamanho de qualquer bloco é par, o tamanho fornecido pelo cabeçalho RIFF também é igual. O conteúdo de blocos individuais será descrito nas seções a seguir.

Formato de arquivo simples (com perda)

Esse layout DEVE ser usado se a imagem exigir codificação perdida e não exigir transparência ou outros recursos avançados fornecidos pelo formato estendido. Os arquivos com esse layout são menores e compatíveis com softwares mais antigos.

Formato de arquivo WebP simples (com perda):

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

Bloco 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                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dados do VP8: bytes de Chunk Size
Dados de bitstream do VP8.

O quarto caractere no 'VP8 ' FourCC é um espaço ASCII (%x20).

A especificação do formato de stream de dados VP8 pode ser encontrada no guia de decodificação e formato de dados do VP8. O cabeçalho do frame do VP8 contém a largura e a altura do frame do VP8. Isso é considerado a largura e altura da tela.

A especificação VP8 descreve como decodificar a imagem no formato Y'CbCr. Para converter para RGB, a recomendação 601 DEVE ser usada. Os aplicativos PODEM usar outro método de conversão, mas os resultados visuais podem ser diferentes entre os decodificadores.

Formato de arquivo simples (sem perdas)

Observação:os leitores mais antigos podem não oferecer suporte a arquivos usando o formato sem perda.

Esse layout DEVE ser usado se a imagem exigir codificação sem perda (com um canal de transparência opcional) e não exigir recursos avançados fornecidos pelo formato estendido.

Formato de arquivo WebP simples (sem perdas):

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

Bloco 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                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dados do VP8L: bytes do Tamanho do pedaço
Dados de bitstream do VP8L.

A especificação atual do bitstream de VP8L pode ser encontrada em formato de bitstream sem perda do WebP. O cabeçalho VP8L contém a largura e a altura da imagem VP8L. Isso é considerado a largura e altura da tela.

Formato de arquivo estendido

Observação: os leitores mais antigos talvez não ofereçam suporte a arquivos que usam o formato estendido.

Um arquivo de formato estendido consiste em:

  • Um trecho 'VP8X' com informações sobre recursos utilizados no arquivo.

  • Um bloco 'ICCP' opcional com perfil de cor.

  • Um bloco 'ANIM' opcional com dados de controle de animação.

  • Dados da imagem.

  • Um bloco 'EXIF' opcional com metadados Exif.

  • Um bloco 'XMP ' opcional com metadados XMP.

Para uma imagem estática, os dados de imagem consistem em um único frame, que é composto de:

Para uma imagem animada, os dados de imagem consistem em vários frames. Veja mais detalhes sobre frames na seção Animação.

Todos os blocos DEVEM ser colocados na mesma ordem listada acima. Se um bloco aparecer no lugar errado, o arquivo será inválido, mas os leitores PODEM analisá-lo, ignorando os blocos que chegam tarde demais.

Justificativa:a definição da ordem dos blocos permite uma análise de arquivos mais rápida. Por exemplo, se um bloco 'ALPH' não aparecer na posição obrigatória, um decodificador poderá parar de pesquisar por ele. A regra de ignorar partes atrasadas precisa fazer com que os programas que precisam fazer uma pesquisa completa tenham os mesmos resultados dos que param mais cedo.

Cabeçalho do arquivo WebP estendido:

 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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reservado (Rsv): 2 bits
PRECISA ser 0.
Perfil do ICC (I): 1 bit
Defina se o arquivo contém um perfil ICC.
Alfa (L): 1 bit
Defina se algum dos frames da imagem contém informações de transparência ("alpha").
Metadados Exif (E): 1 bit
Defina se o arquivo contém metadados Exif.
Metadados XMP (X): 1 bit
Defina se o arquivo contém metadados XMP.
Animação (A): 1 bit
Defina se esta é uma imagem animada. Os dados nos blocos 'ANIM' e 'ANMF' devem ser usados para controlar a animação.
Reservado (R): 1 bit
PRECISA ser 0.
Reservado: 24 bits
PRECISA ser 0.
Largura e menos 1 da largura da tela: 24 bits
Largura baseada em 1 da tela em pixels. A largura real da tela é 1 + Canvas Width Minus One.
Altura mínima do Canvas: 24 bits
Altura baseada em 1 da tela em pixels. A altura real da tela é 1 + Canvas Height Minus One.

O produto de Largura da tela e Altura da tela PRECISA ser no máximo 2^32 - 1.

Especificações futuras PODEM adicionar mais campos.

Animação

Uma animação é controlada por blocos ANIM e ANMF.

ANIM Chunk:

Para uma imagem animada, esse bloco contém os parâmetros globais da animação.

 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cor de fundo: 32 bits (uint32)
A cor padrão do plano de fundo da tela em ordem de bytes [Blue, Green, Red, Alpha]. É possível usar essa cor para preencher o espaço não utilizado na tela ao redor dos frames, bem como os pixels transparentes do primeiro frame. A cor de fundo também é usada quando o método de descarte é 1.

Observação:

  • A cor de fundo PODE conter um valor de transparência (Alfa), mesmo se a sinalização Alpha em VP8X stack não estiver definida.

  • Os aplicativos de visualização precisam tratar o valor da cor de fundo como uma dica e não são necessários para usá-lo.

  • A tela é apagada no início de cada loop. A cor de fundo PODE ser usada para isso.

Contagem de loops: 16 bits (uint16)
É o número de vezes que a animação será repetida. 0 significa infinitamente.

Esse bloco PRECISA aparecer se a sinalização Animation no bloco VP8X estiver definida. Se a sinalização Animation não estiver definida e esse bloco estiver presente, ele PRECISA ser ignorado.

Parte ANMF:

Para imagens animadas, esse bloco contém informações sobre um único frame. Se a sinalização de animação não estiver definida, esse pedaço NÃO DEVE estar 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 bits (uint24)
A coordenada X do canto superior esquerdo do frame é Frame X * 2.
Frame Y: 24 bits (uint24)
A coordenada Y do canto superior esquerdo do frame é Frame Y * 2.
Largura do frame menos eficaz 1: 24 bits (uint24)
A largura baseada no frame. A largura do frame é 1 + Frame Width Minus One.
Altura do frame menos importante: 24 bits (uint24)
A altura baseada em 1 do frame. A altura do frame é 1 + Frame Height Minus One.
Duração do frame: 24 bits (uint24)
Tempo de espera antes de exibir o próximo frame, em unidades de 1 milissegundo. A interpretação da duração do frame de 0 (e frequentemente <= 10) é definida pela implementação. Muitas ferramentas e navegadores atribuem uma duração mínima semelhante ao GIF.
Reservado: 6 bits
PRECISA ser 0.
Método de combinação (B): 1 bit

Indica como os pixels transparentes do frame atual devem ser combinados com os pixels correspondentes da tela anterior:

  • 0: usa a mistura Alfa. Depois de descartar o frame anterior, renderize o frame atual na tela usando a mistura Alfa (veja abaixo). Se o frame atual não tiver um canal Alfa, suponha que o valor alfa seja 255 e substitua o retângulo efetivamente.

  • 1: não misture. Depois de descartar o frame anterior, renderize o frame atual na tela substituindo o retângulo coberto pelo frame atual.

Método de descarte (D): 1 bit

Indica como o frame atual será tratado depois de ser exibido (antes de renderizar o próximo frame) na tela:

  • 0: não descarte. Deixe a tela como está.

  • 1: descarta a cor de fundo. Preencha o retângulo na tela coberta pelo frame atual com a cor de fundo especificada no bloco ANIM.

Observações:

  • O descarte de frames se aplica apenas ao retângulo de frames, ou seja, o retângulo definido por Frame X, Frame Y, largura do frame e altura do frame. Ela pode ou não cobrir a tela inteira.

  • Simulação de Alfa:

    Considerando que cada um dos canais R, G, B e A tem 8 bits, e os canais RGB não são pré-multiplicados por Alfa, a fórmula para combinar 'dst' em '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
    
  • A combinação Alfa deve ser feita em um espaço de cor linear, considerando o perfil de cor da imagem. Se o perfil de cores não estiver presente, sRGB será considerado. O sRGB também precisa ser linearizado devido a uma gama de ~2,2.

Dados do frame: tamanho do bloco - 16 bytes

Consiste em:

Observação: o payload 'ANMF' Dados de frame acima consiste em blocos preenchidos individuais, conforme descrito pelo formato de arquivo RIFF.

Alfa

 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...                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reservado (Rsv): 2 bits
PRECISA ser 0.
Pré-processamento (P): 2 bits

Esses bits informativos são usados para sinalizar o pré-processamento que foi realizado durante a compactação. O decodificador pode usar essas informações para por exemplo, diminuir os valores ou suavizar os gradientes antes da exibição.

  • 0: sem pré-processamento
  • 1: redução de nível
Método de filtragem (F): 2 bits

O método de filtragem usado:

  • 0: nenhuma.
  • 1: filtro horizontal.
  • 2: filtro vertical.
  • 3: filtro de gradiente.

A filtragem é realizada para cada pixel usando os cálculos a seguir. Suponha que os valores Alfa ao redor da posição atual X sejam rotulados como:

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

Buscamos calcular o valor Alfa na posição X. Primeiro, uma previsão é feita, dependendo do método de filtragem:

  • Método 0: preditor = 0
  • Método 1: preditor = A
  • Método 2: preditor = B
  • Método 3: preditor = clipe(A + B - C)

em que clip(v) é igual a:

  • 0 se v < 0
  • 255 se v > 255
  • v caso contrário

O valor final é derivado pela adição do valor descompactado X ao predador e usando a aritmética de módulo-256 para unir o intervalo [256-511] no [0-255]:

alpha = (predictor + X) % 256

Há casos especiais para as posições de pixel mais à esquerda e na parte de cima:

  • O valor superior esquerdo no local (0,0) usa 0 como valor do preditor. Caso contrário, faça o seguinte:
  • Para métodos de filtragem horizontal ou gradiente, os pixels mais à esquerda no local (0, y) são previstos usando o local acima (0, y-1).
  • Para métodos de filtragem vertical ou gradiente, os pixels mais superiores no local (x, 0) são previstos usando o local (x-1, 0) à esquerda.

Os decodificadores não precisam usar essas informações da forma especificada.

Método de compactação (C): 2 bits

O método de compactação usado:

  • 0: sem compactação.
  • 1: compactado com o formato sem perda do WebP.
Fluxo de bits Alfa: tamanho do bloco: 1 bytes

Bitstream Alfa codificado.

Essa parte opcional contém dados Alfa codificados para este frame. Um frame que contém um bloco 'VP8L' NÃO pode conter este bloco.

Justificativa: as informações de transparência já fazem parte do bloco 'VP8L' .

Os dados do canal Alfa são armazenados como dados brutos não compactados (quando o método de compactação é '0') ou compactados usando o formato sem perda (quando o método de compactação é '1').

  • Dados brutos: consiste em uma sequência de bytes de largura * altura, contendo todos os valores de transparência de 8 bits na ordem de verificação.

  • Compactação de formato sem perda: a sequência de bytes é um fluxo de imagem compactado, conforme descrito no formato de stream de perda de WebP sem perdas de dimensão implícita de largura x altura. Ou seja, esse stream de imagem NÃO contém nenhum cabeçalho que descreve a dimensão da imagem.

    Justificativa: a dimensão já é conhecida por outras origens. Por isso, armazená-la novamente seria redundante e propensa a erros.

    Depois que o fluxo de imagem é decodificado em valores de cor ARGB, seguindo o processo descrito na especificação do formato sem perda, as informações de transparência precisam ser extraídas do canal verde do quadruplet ARGB.

    Justificativa: o canal verde pode receber etapas de transformação adicionais na especificação, ao contrário dos outros canais, que podem melhorar a compactação.

Bitstream (VP8/VP8L)

Esse bloco contém dados de bitstream compactados para um único frame.

Um bloco de bitstream pode ser (i) um bloco VP8 usando "VP8 " (observe o espaço significativo de quarto caractere) como sua tag ou (ii) um bloco VP8L, usando "VP8L" como sua tag.

Os formatos de blocos VP8 e VP8L são descritos nas seções Simple File Format (Lossy) e Simple File Format (Lossless), respectivamente.

Perfil de cor

 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                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perfil de cor: bytes de Chunk Size
Perfil de ICC.

Esse bloco PRECISA aparecer antes dos dados da imagem.

Deve haver no máximo um bloco desse tipo. Se houver mais blocos como esse, os leitores poderão ignorar todos, exceto o primeiro. Consulte a especificação do ICS (em inglês) para saber mais.

Se esse bloco não estiver presente, sRGB DEVE ser considerado.

Metadados

Os metadados podem ser armazenados em blocos 'EXIF' ou 'XMP '

Deve haver no máximo um bloco de cada tipo ('EXIF' e 'XMP '). Se houver mais blocos como esse, os leitores PODEm ignorar todos, exceto o primeiro. Além disso, um arquivo pode conter os blocos 'EXIF' e 'XMP '

Os blocos são definidos da seguinte maneira:

Bloco 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                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Metadados Exif: bytes de tamanho do bloco
metadados de imagem no formato Exif.

Parte 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                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Metadados de XMP: bytes de tamanho do bloco
metadados de imagem no formato XMP.

O quarto caractere no 'XMP ' FourCC é um espaço ASCII (%x20).

Veja mais orientações sobre como gerenciar metadados no artigo Diretrizes para processamento de metadados do Grupo de metadados de trabalho.

Como montar a tela de frames

Neste artigo, apresentamos uma visão geral de como um leitor precisa montar uma tela no caso de uma imagem animada. A notação VP8X.field significa o campo no bloco&&33;VP8X' com a mesma descrição.

A exibição de uma tela de imagem animada PRECISA ser equivalente ao seguinte pseudocódigo:

assert VP8X.flags.hasAnimation
canvas ← new image of size VP8X.canvasWidth x VP8X.canvasHeight with
         background color ANIM.background_color.
loop_count ← ANIM.loopCount
dispose_method ← ANIM.disposeMethod
if loop_count == 0:
  loop_count = ∞
frame_params ← nil
assert next chunk in image_data is ANMF
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
    assert VP8X.canvasWidth >= frame_right
    assert VP8X.canvasHeight >= frame_bottom
    for subchunk in 'Frame Data':
      if subchunk.tag == "ALPH":
        assert alpha subchunks not found in 'Frame Data' earlier
        frame_params.alpha = alpha_data
      else if subchunk.tag == "VP8 " OR subchunk.tag == "VP8L":
        assert bitstream subchunks not found in 'Frame Data' earlier
        frame_params.bitstream = bitstream_data
    render frame with frame_params.alpha and frame_params.bitstream
      on canvas with top-left corner at (frame_params.frameX,
      frame_params.frameY), using dispose method dispose_method.
    canvas contains the decoded image.
    Show the contents of the canvas for
    frame_params.frameDuration * 1ms.

Exemplos de layout de arquivo

Uma imagem codificada com perda com Alfa pode ter a seguinte aparência:

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

Uma imagem codificada sem perdas pode ter a seguinte aparência:

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

Uma imagem sem perda com perfil ICC e metadados XMP pode ter a seguinte aparência:

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

Uma imagem animada com metadados Exif pode ter a seguinte aparência:

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)