Spécification du conteneur WebP

Introduction

WebP est un format d'image qui utilise (i) l'encodage d'image clé VP8 pour compresser des données d'image avec pertes ou (ii) utiliser l'encodage WebP sans perte. Ces doivent être plus efficaces que les formats plus anciens, tels que JPEG, GIF et PNG. Il est optimisé pour le transfert rapide d'images sur le réseau (par exemple, pour les sites Web). Le format WebP a une parité des fonctionnalités (profil de couleur, métadonnées, animations, etc.) à d'autres formats. Ce document décrit la structure d'un fichier WebP.

Le conteneur WebP (c'est-à-dire le conteneur RIFF pour WebP) permet la compatibilité des fonctionnalités au-delà du cas d'utilisation de base de WebP (c'est-à-dire un fichier contenant encodée sous forme d'image clé VP8). Le conteneur WebP fournit des données la compatibilité avec les éléments suivants:

  • Compression sans perte : une image peut être compressée sans perte à l'aide du format WebP sans perte.

  • Métadonnées: des métadonnées d'une image peuvent être stockées dans un fichier image échangeable Format (Exif) ou Extensible Metadata Platform (XMP).

  • Transparence : une image peut être transparente, c'est-à-dire comporter un canal alpha.

  • Profil de couleur: comme décrit ci-dessus, une image peut intégrer un profil ICC. par l'International Color Consortium.

  • Animation: une image peut comporter plusieurs images séparées par des pauses. pour en faire une animation.

Dénomination

Il est RECOMMANDÉ d'utiliser les types suivants lorsque vous faites référence au conteneur WebP :

Nom du format de conteneurWebP
Extension de nom de fichier.webp
MIME-typeimage/webp
Uniform Type Identifierorg.webmproject.webp

Terminologie et principes de base

Les mots clés "OBLIGATOIRE", "NE DOIT PAS", "OBLIGATOIRE", "DEVRAIT", "NE DOIT PAS", "DEVRAIT", "NE FAUT PAS", "RECOMMANDÉ", "NON RECOMMANDÉ", "PEUT" et "FACULTATIF" dans cette doivent être interprétées conformément à la norme BCP 14 RFC 2119 RFC 8174. quand et seulement quand, ils apparaissent en majuscules, comme illustré ici.

Un fichier WebP contient une image fixe (c'est-à-dire une matrice de pixels encodée) ou une animation. Il peut également contenir des informations de transparence, un profil de couleur et des métadonnées. Nous appelons la matrice de pixels le canevas de l'image.

La numérotation des bits dans les diagrammes de fragments commence à 0 pour le bit le plus significatif. ("MSB 0"), comme décrit dans le document RFC 1166.

Vous trouverez ci-dessous les termes supplémentaires utilisés dans ce document:

Lecteur/Rédacteur
Le code qui lit des fichiers WebP est appelé lecteur, tandis que le code qui les écrit s'appelle rédacteur.
uint16
Entier non signé de 16 bits, little-endian.
uint24
Entier petit-endian non signé de 24 bits.
uint32
Entier petit-endian non signé de 32 bits.
FourCC
Un code à quatre caractères (FourCC) est un élément uint32 créé en concaténant quatre Caractères ASCII dans l'ordre small-endian. Cela signifie que 'aaaa' (0x61616161) et 'AAAA' (0x41414141) sont traités comme des FourCC différents.
En base 1
Un champ d'entier non signé stockant des valeurs décalées de -1, par exemple, stockerait la valeur 25 sous la forme 24.
ChunkHeader('ABCD')
Utilisé pour décrire les en-têtes FourCC et Chunk Size (Taille des fragments) de fragments individuels. où "ABCD" est le FourCC pour le fragment. La taille de cet élément est de 8 octets.

Format de fichier RIFF

Le format de fichier WebP est basé sur le format de document RIFF (Resource Interchange File Format).

L'élément de base d'un fichier RIFF est un fragment. Il se compose des éléments suivants:

 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                         :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Segment FourCC: 32 bits
Code ASCII à quatre caractères utilisé pour identifier les segments.
Taille de fragment : 32 bits (uint32)
La taille du fragment en octets, à l'exclusion de ce champ, le fragment ou une marge intérieure.
Charge utile des fragments: Taille des fragments octets
Charge utile des données. Si la taille de bloc est impaire, il s'agit d'un seul octet de marge intérieure, qui DOIT être 0 pour être conforme à RIFF ; est ajouté.

Remarque:Pour le RIFF, la convention est que les blocs FourCC tout en majuscules sont des valeurs standards fragments qui s'appliquent à n'importe quel format de fichier RIFF, tandis que les FourCC spécifiques à un fichier sont tous en minuscules. WebP ne suit pas cette convention.

En-tête du fichier 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
Les caractères ASCII R, I, F et F.
Taille du fichier: 32 bits (uint32)
Taille du fichier en octets, à partir d'un décalage de 8. La valeur maximale de ce champ est 2^32 moins 10 octets. Par conséquent, la taille de l'ensemble du fichier est au maximum de 4 GiB moins 2 octets.
"WEBP" : 32 bits
Les caractères ASCII "W", "E", "B" et "P".

Un fichier WebP DOIT commencer par un en-tête RIFF suivi du "WEBP" de FourCC. La taille du fichier dans l'en-tête correspond à la taille totale des fragments qui suivent, plus 4 octets pour le code FourCC "WEBP". Le fichier NE DOIT PAS contenir de données après les données spécifiée dans le champ File Size (Taille du fichier). Les lecteurs PEUVENT analyser ces fichiers, en ignorant les données en fin de ligne. Comme la taille d’un segment est égale, la taille donnée par l’en-tête RIFF est également. Le contenu de chaque segment est décrit dans les sections suivantes.

Format de fichier simple (avec perte)

Cette mise en page DOIT être utilisée si l'image nécessite un encodage avec perte et qu'elle ne ont besoin de transparence ou d'autres fonctionnalités avancées offertes par le format étendu. Les fichiers ayant cette mise en page sont plus petits et pris en charge par des logiciels plus anciens.

Format de fichier WebP simple (avec perte) :

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

 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                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Données VP8 : taille de bloc en octets
Données de flux VP8.

Notez que le quatrième caractère de "VP8" FourCC est un espace ASCII (0x20).

La spécification du format VP8 bitstream est décrite dans Format de données VP8 et Guide de décodage. Notez que l'en-tête de frame VP8 contient la largeur et la hauteur du frame VP8. Il s'agit de la largeur et de la hauteur du canevas.

La spécification VP8 explique comment décoder l'image au format Y'CbCr. Pour convertir en RVB, la recommandation BT.601 DOIT être utilisée. Les applications peuvent utiliser une autre méthode de conversion, mais les résultats visuels peuvent varier d'un décodeur à l'autre.

Format de fichier simple (sans perte)

Remarque : Les lecteurs plus anciens ne sont pas forcément compatibles avec les fichiers au format sans perte.

Cette mise en page DOIT être utilisée si l'image nécessite un encodage sans perte (avec un canal de transparence facultatif) et ne nécessite pas de fonctionnalités avancées fournies par le format étendu.

Format de fichier WebP (sans perte) simple :

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

Morceaux "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                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Données VP8L : taille de bloc en octets
Données de flux de bits VP8L.

La spécification actuelle du flux de bits VP8L est disponible à l'adresse Format WebP Bitstream sans perte : Notez que l'en-tête VP8L contient la largeur et la hauteur de l'image VP8L. Il s'agit de la largeur et la hauteur du canevas.

Format de fichier étendu

Remarque:Il est possible que les lecteurs plus âgés n'acceptent pas les fichiers utilisant le format étendu.

Un fichier au format étendu comprend les éléments suivants:

  • Un modèle "VP8X" Fragment contenant des informations sur les fonctionnalités utilisées dans le fichier.

  • Un bloc "ICCP" facultatif avec un profil de couleur.

  • Un bloc "ANIM" facultatif avec des données de contrôle d'animation.

  • Données d'image.

  • Un bloc "EXIF" facultatif avec des métadonnées EXIF.

  • Un XMP facultatif Fragmentation avec des métadonnées XMP.

  • Liste facultative de fragments inconnus.

Pour une image fixe, les données d'image sont constituées d'un seul cadre, lequel est créé au-delà de:

Pour une image animée, les données d'image se composent de plusieurs images. Plus Les détails sur les images se trouvent dans la section Animation.

Tous les fragments nécessaires à la reconstruction et à la correction des couleurs, c'est-à-dire "VP8X", 'ICCP', 'ANIM', 'ANMF', 'ALPH', 'VP8' et "VP8L", DOIVENT apparaître dans l'ordre décrites précédemment. Les lecteurs DOIVENT échouer lorsque les segments nécessaires à la reconstruction et à la correction des couleurs ne sont pas dans l'ordre.

Les métadonnées et les blocs inconnus peuvent apparaître dans le désordre.

Logique:Les fragments nécessaires à la reconstruction doivent apparaître en premier dans le fichier pour permettre à un lecteur de commencer à décoder une image avant de recevoir toutes les données. Une application peut avoir intérêt à varier l'ordre des métadonnées et des segments personnalisés en fonction de l'implémentation.

En-tête de fichier WebP étendu : 

 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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Réservé (Rsv): 2 bits
DOIT être 0. Les lecteurs DOIVENT ignorer ce champ.
Profil ICC (I) : 1 bit
Définissez ce paramètre si le fichier contient une valeur "ICCP" Un morceau
Alpha (L) : 1 bit
Définir si l'un des cadres de l'image contient des informations sur la transparence ("alpha").
Métadonnées Exif (E) : 1 bit
Indique si le fichier contient des métadonnées Exif.
Métadonnées XMP (X) : 1 bit
Définissez si le fichier contient des métadonnées XMP.
Animation (A) : 1 bit
Définie si l'image est animée. Les données des blocs "ANIM" et "ANMF" doivent être utilisées pour contrôler l'animation.
Réservé (R) : 1 bit
DOIT être 0. Les lecteurs DOIVENT ignorer ce champ.
Réservé: 24 bits
DOIT être 0. Les lecteurs DOIVENT ignorer ce champ.
Largeur de la toile moins un : 24 bits
Largeur basée sur 1 du canevas en pixels. La largeur réelle du canevas est 1 + Canvas Width Minus One.
Hauteur de la toile moins un : 24 bits
Hauteur basée sur 1 du canevas en pixels. La hauteur réelle du canevas est 1 + Canvas Height Minus One.

Le produit de la largeur du canevas et de la hauteur du canevas DOIT être inférieur ou égal à 2^32 - 1.

D'autres champs pourront être ajoutés dans les futures spécifications. Les champs inconnus DOIVENT être ignorés.

Animation

"ANIM" contrôle une animation et "ANMF" Des morceaux.

"ANIM" Fragment:

Pour une image animée, ce fragment contient les paramètres globaux du de l'animation.

 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Couleur d'arrière-plan: 32 bits (uint32)
Couleur d'arrière-plan par défaut du canevas en [bleu, vert, rouge, alpha] l'ordre des octets. Cette couleur PEUT être utilisée pour remplir l'espace inutilisé sur la toile autour des cadres, ainsi que les pixels transparents de la première image. La couleur d'arrière-plan est également utilisée lorsque la méthode de suppression est 1.

Remarque :

  • La couleur d'arrière-plan peut contenir une valeur alpha non opaque, même si l'option Alpha du bloc "VP8X" n'est pas définie.

  • Les applications de visionnage DOIVENT traiter la valeur de la couleur d'arrière-plan comme une indication et ne sont pas tenues de l'utiliser.

  • Le canevas est effacé au début de chaque boucle. La couleur d'arrière-plan PEUT être utilisée à cette fin.

Nombre de boucles : 16 bits (uint16)
Nombre de fois où l'animation doit être répétée. Si la valeur est 0, cela signifie à l'infini.

Ce fragment DOIT apparaître si l'indicateur Animation du bloc "VP8X" Le bloc est défini. Si l'indicateur Animation n'est pas défini et que ce bloc est présent, il DOIT être ignoré.

"ANMF" Fragment:

Pour les images animées, ce fragment contient des informations sur une seule image. Si l'indicateur d'animation n'est pas défini, ce fragment NE DEVRAIT PAS être présent.

 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)
La coordonnée X de l'angle supérieur gauche du cadre est Frame X * 2.
Y du frame : 24 bits (uint24)
La coordonnée Y de l'angle supérieur gauche du cadre est Frame Y * 2.
Largeur de trame moins un: 24 bits (uint24)
Largeur basée sur 1 du cadre. La largeur du cadre est de 1 + Frame Width Minus One.
Hauteur de frame moins un : 24 bits (uint24)
Hauteur basée sur 1 du cadre. La hauteur du cadre est de 1 + Frame Height Minus One.
Durée du frame : 24 bits (uint24)
Temps d'attente avant l'affichage du frame suivant, en unités de 1 milliseconde. Notez que l'interprétation de la durée d'image de 0 (et souvent <= 10) est défini par l'implémentation. De nombreux outils et navigateurs attribuent une durée minimale semblable à celle des GIF.
Réservé: 6 bits
DOIT être 0. Les lecteurs DOIVENT ignorer ce champ.
Méthode de combinaison (B): 1 bit

Indique comment les pixels transparents du cadre actuel doivent être mélangés avec les pixels correspondants du canevas précédent :

  • 0 : utilisez le mélange alpha. Après avoir supprimé l'image précédente, effectuez le rendu cadre actuel sur le canevas en utilisant la combinaison alpha (voir ci-dessous). Si le l'image actuelle ne possède pas de canal alpha, supposons que la valeur alpha soit 255, remplaçant ainsi le rectangle.

  • 1 : ne pas mélanger. Après avoir supprimé le frame précédent, affichez le frame actuel sur le canevas en écrasant le rectangle recouvert par le frame actuel.

Méthode de mise au rebut (D): 1 bit

Indique comment l'image actuelle doit être traitée une fois qu'elle a été affiché (avant d'afficher l'image suivante) sur le canevas:

  • 0 : ne pas supprimer. Laissez le canevas tel quel.

  • 1: appliquer la couleur d'arrière-plan. Remplissez le rectangle sur le canevas recouvert par le cadre actuel avec la couleur d'arrière-plan spécifiée dans le bloc "ANIM".

Remarques :

  • L'élimination des frames ne s'applique qu'au rectangle de frame, c'est-à-dire au rectangle défini par Frame X, Frame Y, frame width et frame height. Il peut ou non recouvrir l'intégralité de la toile.

  • Mélange alpha :

    Étant donné que chacun des canaux R, V, B et A est de 8 bits et que le canal RVB les canaux ne sont pas prémultipliés par le canal alpha, la formule permettant de combiner "dst" dans "src" est:

    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

  • Le mélange alpha DOIT être effectué dans un espace colorimétrique linéaire, en tenant compte du profil de couleur de l'image. Si le profil de couleur est absente, il s'agit du format RVB standard (sRVB). (Notez que le sRGB doit également être linéarisé en raison d'un gamma d'environ 2,2.)

Données de trame : Taille de bloc en octets : 16

Comporte:

Remarque: L'ANMF Frame Data (Données de trame) est constituée de données fragments padded, comme décrit par le format de fichier 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...                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Réservé (Rsv) : 2 bits
DOIT être 0. Les lecteurs DOIVENT ignorer ce champ.
Prétraitement (P): 2 bits

Ces bits informatifs servent à signaler le prétraitement effectué lors de la compression. Le décodeur peut utiliser ces informations pour par exemple, tramer les valeurs ou lisser les dégradés avant l'affichage.

  • 0 : pas de prétraitement.
  • 1: réduction du niveau.

Les décodeurs ne sont pas tenus d'utiliser ces informations d'une manière spécifiée.

Méthode de filtrage (F): 2 bits

Les méthodes de filtrage utilisées sont décrites comme suit :

  • 0: aucun.
  • 1: filtre horizontal.
  • 2 : filtre vertical.
  • 3: filtre de dégradé.

Pour chaque pixel, le filtrage est effectué à l'aide des calculs suivants. Supposons que les valeurs alpha entourant la position actuelle de X soient étiquetées comme suit:

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

Nous cherchons à calculer la valeur alpha à la position X. Tout d'abord, une prédiction selon la méthode de filtrage:

  • Méthode 0 : prédicteur = 0
  • Méthode 1: prédicteur = A
  • Méthode 2: prédicteur = B
  • Méthode 3: prédicteur = clip(A + B - C)

où clip(v) est égal à:

  • 0 si v < 0,
  • 255 si v > 255, ou
  • v sinon

La valeur finale est dérivée en ajoutant la valeur décompressée X au prédicteur et en utilisant l'arithmétique modulo-256 pour encapsuler la plage [256..511] dans la plage [0..255] :

alpha = (predictor + X) % 256

Des cas particuliers s'appliquent aux positions de pixel les plus à gauche et les plus en haut. Pour exemple, la valeur en haut à gauche à l'emplacement (0, 0) utilise 0 comme valeur de prédicteur. Sinon :

  • Pour les méthodes de filtrage horizontal ou en gradient, les pixels les plus à gauche à l'emplacement (0, y) sont prédits à l'aide de l'emplacement (0, y-1) juste au-dessus.
  • Pour les méthodes de filtrage vertical ou de gradient, les pixels les plus élevés à l'emplacement (x, 0) sont prédits à l'aide de l'emplacement (x-1, 0) à gauche.
Méthode de compression (C): 2 bits

Méthode de compression utilisée :

  • 0 : aucune compression.
  • 1 : compressé à l'aide du format WebP sans perte.
Flux de bits alpha: Taille de fragments – 1

Flux de bits alpha encodé.

Ce fragment facultatif contient des données alpha encodées pour cette trame. Un cadre contenant le code Le bloc NE DEVRAIT PAS contenir ce fragment.

Rationalité : les informations de transparence font déjà partie du segment "VP8L".

Les données du canal alpha sont stockées sous forme de données brutes non compressées (lorsque la méthode de compression est "0") ou compressées à l'aide du format sans perte (lorsque la méthode de compression est "1").

  • Données brutes: elles se composent d'une séquence d'octets de type longueur = largeur * hauteur, contenant toutes les valeurs de transparence 8 bits dans l'ordre d'analyse.

  • Compression du format sans perte: la séquence d'octets est un format compressé flux d'images (tel que décrit dans la section Format WebP Bitstream sans perte) de dimensions implicites largeur x hauteur. Autrement dit, ce flux d'images ne contient PAS d'en-têtes décrivant les dimensions de l'image.

    Justification: Les dimensions sont déjà connues d'autres sources. les stocker à nouveau serait donc redondant et sujet aux erreurs.

    Une fois que le flux d'images est décodé en valeurs de couleur alpha, rouge, vert et bleu (ARGB), conformément au processus décrit dans la spécification du format sans perte, les informations de transparence doivent être extraites du canal vert du quadruplet ARGB.

    Rationalité : Contrairement aux autres canaux, le canal vert est autorisé à effectuer des étapes de transformation supplémentaires dans la spécification, ce qui peut améliorer la compression.

Flux de bits (VP8/VP8L)

Ce fragment contient des données de flux de bits compressées pour une seule trame.

Un bloc de flux de bits peut être (i) un bloc "VP8", utilisant "VP8" (notez l'espace significatif du quatrième caractère) comme code FourCC, ou (ii) un bloc "VP8L", utilisant "VP8L" comme code FourCC.

Les formats des blocs "VP8" et "VP8L" sont décrits respectivement dans les sections Simple File Format (Lossy) (Format de fichier simple (avec perte)) et Simple File Format (Lossless) (Format de fichier simple (sans perte)).

Profil de couleur

 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                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Profil de couleur : taille de bloc en octets
Profil ICC.

Ce bloc DOIT apparaître avant les données d'image.

Il ne devrait y avoir qu'un seul tel bloc. S'il y en a d'autres, les lecteurs peuvent les ignorer, à l'exception de la première. Pour en savoir plus, consultez les spécifications de l'ICC.

Si ce fragment n'est pas présent, le format sRVB DOIT être utilisé.

Métadonnées

Les métadonnées peuvent être stockées dans des blocs EXIF ou XMP.

Il DOIT y avoir au plus un bloc de chaque type ("EXIF" et "XMP"). S'il y a sont plutôt des morceaux de ce type, les lecteurs PEUVENT ignorer tous sauf le premier.

Les segments sont définis comme suit :

'EXIF' Fragment:

 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                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Métadonnées Exif: Taille des fragments
Métadonnées d'image au format Exif.

"XMP" Fragment:

 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                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Métadonnées XMP: Taille des fragments
Métadonnées d'image au format XMP.

Notez que le quatrième caractère du code FourCC "XMP" est un espace ASCII (0x20).

Pour obtenir des conseils supplémentaires sur la gestion des métadonnées, consultez les Consignes de gestion des métadonnées du groupe de travail sur les métadonnées.

Blocs inconnus

Un segment RIFF (décrit dans la section Format de fichier RIFF) dont le code FourCC est différent de celui de tous les segments décrits dans ce document est considéré comme un segment inconnu.

Logique: Le fait d'autoriser les fragments inconnus permet de prévoir une extension ultérieure. du format et permet également de stocker des données spécifiques à l'application.

Un fichier PEUT contenir des fragments inconnus:

Les lecteurs DOIVENT ignorer ces fragments. Les rédacteurs DOIVENT les conserver dans leur ordre d'origine (sauf s'ils ont spécifiquement l'intention de modifier ces blocs).

Assemblage de la toile à partir des cadres

Voici un aperçu de la façon dont un lecteur DOIT assembler un canevas dans le cas où d'une image animée.

Le processus commence par la création d'un canevas à l'aide des dimensions fournies dans le "VP8X" Fragment, Canvas Width Minus One + 1 pixels de large par Canvas Height Minus One + 1 pixels de haut. Le champ Loop Count du segment "ANIM" contrôle le nombre de fois où le processus d'animation est répété. Il s'agit de Loop Count - 1 pour les valeurs Loop Count non nulles ou d'infini si Loop Count est nul.

Au début de chaque itération de boucle, le canevas est rempli à l'aide de la couleur d'arrière-plan du bloc "ANIM" ou d'une couleur définie par l'application.

"ANMF" Les fragments contiennent des frames individuels présentés dans l'ordre d'affichage. Avant l'affichage de chaque frame, le Disposal method du frame précédent est appliqué.

Le rendu du cadre décodé commence aux coordonnées cartésiennes (2 * Frame X, 2 * Frame Y), en utilisant le coin supérieur gauche du canevas comme origine. Frame Width Minus One + 1 pixels de large sur Frame Height Minus One + 1 pixels de haut sont affichés sur le canevas à l'aide de Blending method.

Le canevas est affiché pendant Frame Duration millisecondes. Cette opération se poursuit jusqu'à toutes les images fournies par "ANMF" Les fragments ont été affichés. Une nouvelle itération de boucle est a commencé, ou le canevas reste dans son état final si toutes les itérations ont été terminé.

Le pseudo-code suivant illustre le processus d'affichage. La notation VP8X.champ désigne le champ du segment "VP8X" ayant la même description.

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

Exemples de mises en page de fichiers

Une image encodée avec pertes en alpha peut se présenter comme suit:

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

Une image encodée sans perte peut se présenter comme suit :

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

Une image sans perte avec un profil ICC et des métadonnées XMP peut se présenter comme suit :

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

Une image animée avec des métadonnées EXIF peut se présenter comme suit :

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)