Especificación del contenedor WebP

Introducción

WebP es un formato de imagen que usa (i) la codificación de fotogramas VP8 para comprimir datos de imagen con pérdida o (ii) usar codificación WebP sin pérdida Estos esquemas de codificación debería hacerlo más eficiente que los formatos más antiguos, como JPEG, GIF y PNG. Está optimizado para una transferencia rápida de imágenes a través de la red (para por ejemplo, para sitios web). El formato WebP tiene paridad de funciones (perfil de color, metadatos, animación, etc.) con otros formatos también. En este documento, se describen la estructura de un archivo WebP.

El contenedor WebP (es decir, el contenedor RIFF para WebP) permite la compatibilidad con funciones. además del caso de uso básico de WebP (es decir, un archivo que contiene un solo codificada como un fotograma de VP8). El contenedor de WebP brinda compatibilidad con lo siguiente:

• Compresión sin pérdida: Una imagen se puede comprimir sin pérdidas, con el Formato WebP sin pérdida.

• Metadatos: Una imagen puede tener metadatos almacenados en un archivo de imagen intercambiable. Formato (Exif) o Plataforma de metadatos extensible (XMP).

• Transparencia: Una imagen puede tener transparencia, es decir, un canal alfa.

• Perfil de color: Una imagen puede tener un perfil ICC incorporado, tal como se describe por el International Color Consortium.

• Animación: Una imagen puede tener varios fotogramas con pausas entre ellos y convertirlo en una animación.

Nombre

SE RECOMIENDA usar los siguientes tipos para hacer referencia al archivo WebP contenedor:

Nombre del formato del contenedor	WebP
Extensión de nombre de archivo	.webp
Tipo de MIME	image/webp
Identificador de tipo uniforme	org.webmproject.webp

Terminología y Aspectos básicos

Las palabras clave “DEBE”, “NO DEBE”, “OBLIGATORIO”, “DEBERÁ”, “NO DEBERÁ”, “DEBERÍA”, "NO DEBERÍA", "RECOMENDADO", "NO RECOMENDADO", "MAYO" y "OPCIONAL" en esta documento se deben interpretar como se describe en BCP 14 RFC 2119 RFC 8174 solo cuándo y cuándo aparecen en mayúsculas, como se muestra aquí.

Un archivo WebP contiene una imagen estática (es decir, una matriz de píxeles codificada). o una animación. De manera opcional, también puede contener transparencia información, un perfil de color y metadatos. Nos referimos a la matriz de píxeles como el lienzo de la imagen.

La numeración de bits en diagramas de fragmentos comienza en 0 para el bit más significativo (“MSB 0”), como se describe en RFC 1166.

A continuación, se mencionan términos adicionales que se utilizan en este documento:

Lector/escritor

El código que lee archivos WebP se conoce como lector, mientras que el código que las escribe se conoce como escritor.

uint16

Un número entero sin firma de 16 bits.

uint24

Un número entero sin firma de 24 bits.

uint32

Un número entero sin firma de 32 bits.

FourCC

Un código de cuatro caracteres (FourCC) es un uint32 creado mediante la concatenación de cuatro Caracteres ASCII en orden Little endian. Esto significa "aaaa" (0x61616161) y “AAAA” (0x41414141) se tratan como FourCCs diferentes.

Basado en 1

Un campo de número entero sin firma que almacena valores desplazados por -1, por ejemplo, como debe almacenar el valor 25 como 24.

ChunkHeader('ABCD')

Se usa para describir los encabezados FourCC y Chunk Size de los fragmentos individuales. en el que “ABCD” es el FourCC del bloque. El tamaño de este elemento es de 8 bytes.

Formato de archivo RIFF

El formato de archivo WebP se basa en el formato de archivo de intercambio de recursos (RIFF) formato del documento.

El elemento básico de un archivo RIFF es un fragmento. Consta de lo siguiente:

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

Fragmentación FourCC: 32 bits

Código ASCII de cuatro caracteres que se usa para identificar el fragmento.

Tamaño del fragmento: 32 bits (uint32)

El tamaño del fragmento en bytes, sin incluir este campo, el fragmento identificador o padding.

Carga útil del fragmento: Tamaño del fragmento de bytes

La carga útil de datos. Si el Tamaño del fragmento es impar, un solo byte de relleno, que DEBE sea 0 para cumplir con RIFF.

Nota: RIFF tiene la convención de que los bloques FourCCs en mayúsculas son estándares fragmentos que se aplican a cualquier formato de archivo RIFF, mientras que los FourCCs específicos de un archivo formato están todas en minúsculas. WebP no sigue esta convención.

Encabezado del archivo 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

Los caracteres ASCII “R”, “I”, “F”, “F”.

Tamaño del archivo: 32 bits (uint32)

Es el tamaño del archivo en bytes, comenzando con el desplazamiento 8. El valor máximo de este campo es de 2^32 menos 10 bytes y, por lo tanto, el tamaño del archivo completo es de la mayoría son 4 GiB menos 2 bytes.

"WEBP": 32 bits

Los caracteres ASCII “W”, “E”, “B”, “P”.

Un archivo WebP DEBE comenzar con un encabezado RIFF con el “WEBP” de FourCC. El tamaño del archivo en el encabezado es el tamaño total de los fragmentos que siguen más 4 bytes para el “WEBP” FourCC. El archivo NO DEBE contener ningún dato después de que especificadas por File Size ES POSIBLE que los lectores analicen estos archivos sin tener en cuenta el de datos no estructurados. Como el tamaño de cualquier fragmento es par, el tamaño indicado por el encabezado RIFF es también. El contenido de los fragmentos individuales se describe a continuación secciones.

Formato de archivo simple (con pérdida)

Este diseño DEBE utilizar si la imagen requiere codificación con pérdida y no requieran transparencia u otras funciones avanzadas proporcionadas por el formato extendido. Los archivos con este diseño son más pequeños y son compatibles con software más antiguo.

Formato de archivo WebP simple (con pérdida):

 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" Fragmento:

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

Datos de VP8: tamaño del fragmento de bytes

Datos de flujo de bits de VP8.

Ten en cuenta que el cuarto carácter de la columna "VP8" FourCC es un espacio ASCII (0x20).

La especificación del formato de flujo de bits de VP8 se describe en Formato de datos de VP8 y Guía de decodificación. Ten en cuenta que el encabezado de la trama VP8 contiene la trama VP8. ancho y alto. Se supone que son el ancho y el alto del lienzo.

La especificación de VP8 describe cómo decodificar la imagen en formato Y'CbCr. Para convertir a RGB, se DEBE usar la recomendación BT.601. Aplicaciones MAYO usan otro método de conversión, pero los resultados visuales pueden diferir entre los decodificadores.

Formato de archivo simple (sin pérdidas)

Nota: Es posible que los lectores más antiguos no admitan archivos con el formato sin pérdidas.

Este diseño DEBE utilizar si la imagen requiere codificación sin pérdidas (con una canal de transparencia opcional) y no requiere que se proporcionen funciones avanzadas por el formato extendido.

Formato de archivo WebP simple (sin pérdidas):

 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" Fragmento:

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

Datos de VP8L: tamaño del fragmento de bytes

Datos de flujo de bits de VP8L.

La especificación actual del flujo de bits de VP8L se puede encontrar en Formato de flujo de bits sin pérdida de WebP. Ten en cuenta que el encabezado de VP8L contiene el ancho y el alto de la imagen de VP8L. Se supone que ese es el ancho y la altura del lienzo.

Formato de archivo extendido

Nota: Es posible que los lectores más antiguos no admitan archivos con el formato extendido.

Un archivo de formato extendido consta de lo siguiente:

• Un "VP8X" Fragmento con información sobre las características utilizadas en el archivo.

• Un "ICCP" opcional. Fragmento con un perfil de color.

• Un "ANIM" opcional Fragmento con datos de control de animación.

• Datos de imágenes

• Un “EXIF” opcional Fragmento con metadatos EXIF.

• Un archivo "XMP" opcional Fragmento con metadatos XMP.

• Una lista opcional de fragmentos desconocidos.

En el caso de una imagen fija, los datos de la imagen constan de un solo marco, que se realiza hasta la siguiente cantidad:

• Un subfragmento alfa opcional.

• Un subfragmento de flujo de bits.

En el caso de una imagen animada, los datos de imagen constan de varios marcos. Más puedes encontrar detalles sobre los marcos en la sección Animación.

Todos los fragmentos necesarios para la reconstrucción y la corrección de colores, es decir, 'VP8X', 'ICCP', 'ANIM', 'ANMF', 'ALPH', 'VP8' y “VP8L”, DEBE aparecer en el orden descrita anteriormente. Los lectores DEBEN fallar cuando los fragmentos necesarios para la reconstrucción y la corrección de colores están desordenados.

PUEDEN aparecer los metadatos y los fragmentos desconocidos de en el orden personalizado.

Razón: Los fragmentos necesarios para la reconstrucción deberían aparecer primero en en el archivo para permitir que el lector comience a decodificar una imagen antes de recibir toda los datos. Una aplicación se puede beneficiar de variar el orden de los metadatos y en fragmentos personalizados para adaptarlos a la implementación.

Encabezado del archivo WebP extendido:

 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

DEBE ser 0. Los lectores DEBEN ignorar este campo.

Perfil ICC (I): 1 bit

Se configura si el archivo contiene un "ICCP". En trozos.

Alfa (L): 1 bit

Establece si alguno de los marcos de la imagen contiene información de transparencia ("alfa").

Metadatos EXIF (E): 1 bit

Se establece si el archivo contiene metadatos EXIF.

Metadatos XMP (X): 1 bit

Se establece si el archivo contiene metadatos XMP.

Animación (A): 1 bit

Establece si se trata de una imagen animada. Datos en 'ANIM' y “ANMF” Los fragmentos deben ser que se usa para controlar la animación.

Reservado (R): 1 bit

DEBE ser 0. Los lectores DEBEN ignorar este campo.

Reservado: 24 bits

DEBE ser 0. Los lectores DEBEN ignorar este campo.

Ancho del lienzo menos uno: 24 bits.

Es el ancho del lienzo en basado en 1 en píxeles. El ancho real del lienzo es de 1 + Canvas Width Minus One.

Altura del lienzo menos uno: 24 bits

Basado en 1: Es la altura del lienzo en píxeles. La altura real del lienzo es de 1 + Canvas Height Minus One.

El producto de Ancho del lienzo y Altura del lienzo DEBE ser 2^32 - 1 como máximo.

Es posible que en el futuro se agreguen más campos. Se DEBEN ignorar los campos desconocidos.

Animación

Una animación es controlada por "ANIM" y “ANMF” Trozos.

"ANIM" Fragmento:

Para una imagen animada, este bloque contiene los parámetros globales del animación.

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

Color de fondo: 32 bits (uint32)

El color de fondo predeterminado del lienzo en color [azul, verde, rojo, alfa]. de bytes. Este color PUEDE usarse para llenar el espacio que no se usa en el lienzo alrededor de los marcos, así como los píxeles transparentes del primer marco. El color de fondo también se usa cuando el método de eliminación es 1.

Nota:

• El color de fondo PUEDE contener un valor alfa no opaco, incluso si el la marca Alfa en el atributo "VP8X" No se estableció el fragmento.

• Las aplicaciones de visualización DEBEN tratar el valor del color de fondo como una sugerencia y no es necesario usarlo.

• El lienzo se borra al comienzo de cada bucle. El color de fondo PUEDE ser que se usa para lograrlo.

Recuento de bucles: 16 bits (uint16)

Es la cantidad de veces que se debe repetir la animación en bucle. Si es 0, significa infinitamente.

Este bloque DEBE aparecer si la marca Animation en el archivo Se estableció el fragmento. Si la marca Animation no está establecida y este fragmento está presente, DEBE ignorados.

“ANMF” Fragmento:

En el caso de las imágenes animadas, este bloque contiene información sobre un único fotograma. Si la marca de Animation no está establecida, este bloque NO DEBE 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                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Marco X: 24 bits (uint24)

La coordenada X de la esquina superior izquierda del marco es Frame X * 2.

Marco Y: 24 bits (uint24)

La coordenada Y de la esquina superior izquierda del marco es Frame Y * 2.

Ancho del marco menos uno: 24 bits (uint24)

Es el ancho del marco basado en 1. El ancho del marco es 1 + Frame Width Minus One.

Altura del marco menos uno: 24 bits (uint24)

Es la altura basada en 1 del marco. La altura del marco es 1 + Frame Height Minus One.

Duración del fotograma: 24 bits (uint24)

El tiempo que se debe esperar antes de mostrar el siguiente fotograma, en unidades de 1 milisegundo. Ten en cuenta que la interpretación de Frame Duration de 0 (y, a menudo, <= 10) es definidos por la implementación. Muchas herramientas y navegadores asignan un mínimo de duración similar a la del GIF.

Reservado: 6 bits

DEBE ser 0. Los lectores DEBEN ignorar este campo.

Método de combinación (B): 1 bit

Indica qué tan transparentes deben combinarse los píxeles del marco actual. con los píxeles correspondientes del lienzo anterior:

• 0: usa la combinación alfa. Después de deshacerte del marco anterior, renderiza el marco actual en el lienzo utilizando la combinación alfa (ver a continuación). Si el botón fotograma actual no tiene un canal alfa, supón que el valor alfa es 255, y reemplaza efectivamente el rectángulo.

• 1: No combinar. Después de deshacerte del marco anterior, renderiza el marco actual en el lienzo sobrescribiendo el rectángulo que cubre el marco actual.

Método de eliminación (D): 1 bit

Indica cómo se debe tratar el fotograma actual después de haberlo hecho. que se muestra (antes de procesar el siguiente fotograma) en el lienzo:

• 0: No desechar. Deja el lienzo como está.

• 1: Descarta en el color de fondo. Rellenar el rectángulo en el lienzo cubierto por el marco actual con el color de fondo especificado en el “ANIM” Fragmento

Notas:

• La eliminación de marcos solo se aplica al rectángulo de marcos, es decir, al rectángulo definido por Marco X, Marco Y, ancho del marco y marco altura. Puede o no cubrir todo el lienzo.

• Combinación alfa:

  Dado que cada uno de los canales R, G, B y A es de 8 bits, y la resolución canales no están multiplicados previamente por alfa, la fórmula para combinar 'dst' en "src" es:

  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 combinación alfa SE DEBE realizar en un espacio de color lineal teniendo en cuenta. el perfil de color de la imagen. Si el perfil de color está no está presente, se supone que el formato RGB estándar (sRGB). (ten en cuenta que sRGB también debe linealizarse debido a un gamma de ~2.2).

Datos de trama: Tamaño del fragmento - 16 bytes

Consiste en lo siguiente:

• Un subfragmento alfa opcional para el marco.

• Un subfragmento de transmisión de bits para el fotograma.

• Una lista opcional de fragmentos desconocidos.

Nota: La “ANMF” carga útil, Frame Data, consta de datos bloques padding, como se describe en el formato de archivo 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

DEBE ser 0. Los lectores DEBEN ignorar este campo.

Procesamiento previo (P): 2 bits

Estos bits informativos se usan para indicar el procesamiento previo que tiene que se realizó durante la compresión. El decodificador puede usar esta información para por ejemplo, interpolar los valores o suavizar los gradientes antes de mostrarlos.

• 0: Sin procesamiento previo.
• 1: Reducción de nivel.

No es necesario que los decodificadores usen esta información de ninguna manera especificada.

Método de filtrado (F): 2 bits

Los métodos de filtrado utilizados se describen de la siguiente manera:

• 0: Ninguna.
• 1: Filtro horizontal.
• 2: Filtro vertical.
• 3: Filtro de gradiente.

Para cada píxel, el filtrado se realiza mediante los siguientes cálculos. Supongamos que los valores alfa que rodean la posición actual de X están etiquetados de la siguiente manera:

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

Buscamos calcular el valor alfa en la posición X. Primero, una predicción es según el método de filtrado:

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

En el ejemplo anterior, clip(v) es igual a:

• 0 si v < 0,
• 255 si v > 255 o
• v en caso contrario

El valor final se deriva agregando el valor descomprimido X al predictor y usar la aritmética de módulo-256 para unir el rango [256..511] al [0..255]:

alpha = (predictor + X) % 256

Existen casos especiales para las posiciones de píxeles superiores a la izquierda y superior. Para Por ejemplo, el valor superior izquierdo en la ubicación (0, 0) usa 0 como valor del predictor. En caso contrario:

• Para los métodos de filtrado horizontal o de gradiente, los píxeles que se encuentran más a la izquierda al ubicación (0, y) se predicen mediante la ubicación (0, y-1) que está justo arriba.
• Para los métodos de filtrado vertical o de gradiente, los píxeles superiores al ubicaciones (x, 0) se predicen mediante la ubicación (x-1, 0) de la izquierda.

Método de compresión (C): 2 bits

El método de compresión utilizado es el siguiente:

• 0: Sin compresión.
• 1: Comprimido con el formato WebP sin pérdida.

Flujo de bits alfa: Tamaño del segmento - 1 bytes

Flujo de bits alfa codificado.

Este fragmento opcional contiene datos alfa codificados para este marco. Un marco que contenga un “VP8L” El fragmento NO DEBE contener este bloque.

Razón: La información de transparencia ya forma parte de "VP8L". En trozos

Los datos de los canales alfa se almacenan como datos sin procesar descomprimidos (cuando el método de compresión es "0") o se comprime con el formato sin pérdida (cuando el método de compresión es '1').

• Datos sin procesar: Consisten en una secuencia de bytes de longitud = ancho * alto. con todos los valores de transparencia de 8 bits en el orden de análisis.

• Compresión de formato sin pérdida: la secuencia de bytes es una estructura flujo de imágenes (como se describe en "Formato de flujo de bits sin pérdida de WebP") de dimensiones implícitas de ancho x alto. Es decir, esta image-stream NO contiene encabezados que describen las dimensiones de la imagen.

  Razón: Las dimensiones ya se conocen de otras fuentes, por lo que volver a almacenarlos sería redundante y propenso a errores.

  Una vez que la transmisión de imágenes se decodifica en color alfa, rojo, verde, azul (ARGB) de salida siguiendo el proceso descrito en el formato sin pérdidas específica, la información de transparencia debe extraerse del el canal green del cuadruple ARGB.

  Razón: El canal verde tiene permitido una transformación adicional. pasos en la especificación, a diferencia de los otros canales, que pueden mejorar la compresión.

Flujo de bits (VP8/VP8L)

Este fragmento contiene datos de flujo de bits comprimidos para una sola trama.

Un fragmento de flujo de bits puede ser (i) un “VP8” Fragmento con “VP8” (ten en cuenta el espacio significativo de cuarto carácter) como su FourCC o (ii) un "VP8L" En trozos con “VP8L” como FourCC.

Los formatos de "VP8" y "VP8L" Los fragmentos son como se describe en las secciones Formato de archivo simple (con pérdida) y Simple File Format (Lossless), respectivamente.

Perfil de color

 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 color: Tamaño del fragmento bytes

Perfil ICC

Este bloque DEBE aparecer antes de los datos de la imagen.

DEBERÍA haber, como máximo, uno de esos bloques. Si hay más fragmentos de este tipo, los lectores PUEDE ignorar todo excepto el primero. Consulta la especificación de ICC para obtener más detalles.

Si este bloque no está presente, se DEBE suponer que se trata de sRGB.

Metadatos

Los metadatos se pueden almacenar en “EXIF” o "XMP" Trozos.

DEBE haber como máximo un fragmento de cada tipo ("EXIF" y "XMP"). Si son más fragmentos de ese tipo, los lectores PUEDEN ignorar todo excepto el primero.

Los fragmentos se definen de la siguiente manera:

“EXIF” Fragmento:

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

Metadatos EXIF: Tamaño del fragmento de bytes

Metadatos de imagen en formato EXIF

'XMP' Fragmento:

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

Metadatos XMP: Tamaño del fragmento de bytes

Metadatos de imagen en formato XMP

Ten en cuenta que el cuarto carácter de la etiqueta "XMP" FourCC es un espacio ASCII (0x20).

Puedes encontrar orientación adicional sobre el manejo de metadatos en el Lineamientos para el manejo de metadatos del Grupo de Trabajo de Metadatos.

Fragmentos desconocidos

Un fragmento RIFF (descrito en la sección Formato de archivo RIFF) cuyo FourCC es diferente de cualquiera de los fragmentos descritos en este documento, es se considera un fragmento desconocido.

Razón: Permitir los fragmentos desconocidos proporciona un aprovisionamiento para una extensión futura del formato y permite almacenar cualquier dato específico de la aplicación.

Es posible que un archivo contenga fragmentos desconocidos:

• al final del archivo, como se describe en Archivo WebP extendido. encabezado o
• al final de “ANMF” En trozos, como se describe en la sección Animation.

Los lectores DEBEN ignorar estos fragmentos. Los redactores DEBEN conservarlos en sus en el orden original (a menos que se intenten modificar específicamente estos fragmentos).

Ensamblaje del lienzo de Frames

Aquí proporcionamos una descripción general de cómo un lector DEBE ensamblar un lienzo en el caso de una imagen animada.

El proceso comienza con la creación de un lienzo usando las dimensiones indicadas en la "VP8X" Porción de Canvas Width Minus One + 1 píxeles de ancho por Canvas Height Minus One + 1 píxeles de alto El campo Loop Count de la "ANIM" El fragmento controla cómo muchas veces se repite el proceso de animación. Esto es Loop Count - 1 para valores Loop Count distintos de cero o infinito si Loop Count es cero.

Al comienzo de cada iteración de bucle, el lienzo se rellena con los color de fondo de la sección "ANIM" Fragmento o un color definido por la aplicación.

“ANMF” Los fragmentos contienen marcos individuales divididos en orden de visualización. Antes del procesamiento cada fotograma, se aplica el Disposal method del fotograma anterior.

La renderización del fotograma decodificado comienza en las coordenadas cartesianas (2 * Frame X, 2 * Frame Y) y usa la esquina superior izquierda del lienzo como origen. Frame Width Minus One + 1 píxeles de ancho por Frame Height Minus One + 1 píxeles de alto se renderizan en el lienzo con Blending method.

El lienzo se muestra durante Frame Duration milésimas de segundo. Esto continúa hasta que todos los fotogramas proporcionados por “ANMF” Se mostraron los fragmentos. Una nueva iteración de bucle es luego comienza, o el lienzo queda en su estado final si todas las iteraciones el proyecto se completó.

En el siguiente pseudocódigo, se ilustra el proceso de renderización. La notación VP8X.field significa el campo "VP8X". Fragmento con la misma descripción.

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

Ejemplo de diseños de archivo

Una imagen codificada con pérdidas con alfa puede verse de la siguiente manera:

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

Una imagen codificada sin pérdida puede verse de la siguiente manera:

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

Una imagen sin pérdidas con un perfil ICC y metadatos XMP pueden verse de la siguiente manera:

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

Una imagen animada con metadatos EXIF puede verse de la siguiente manera:

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)