Spécification du conteneur WebP

Introduction

WebP est un format d'image qui utilise (i) le codage de frame clé VP8 pour compresser les données d'image de manière à entraîner des pertes ou (ii) le codage sans perte WebP. Ces schémas d'encodage devraient être plus efficaces que les anciens formats, 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 présente également une parité de fonctionnalités (profil de couleur, métadonnées, animation, etc.) avec 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 de prendre en charge des fonctionnalités au-delà du cas d'utilisation de base de WebP (c'est-à-dire un fichier contenant une seule image encodée en tant que frame clé VP8). Le conteneur WebP offre une prise en charge supplémentaire pour 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: les métadonnées d'une image peuvent être stockées au format Exif (Exchangeable Image File Format) ou XMP (Extensible Metadata Platform).

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

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

• Animation: une image peut comporter plusieurs images avec des pauses entre elles, ce qui en fait une animation.

Dénomination

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

Nom du format du conteneur	WebP
Extension de nom de fichier	.webp
Type MIME	image/webp
Identifiant de type uniforme	org.webmproject.webp

Terminologie et principes de base

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" de ce document doivent être interprétés comme décrit dans les documents BCP 14 RFC 2119 RFC 8174 lorsqu'ils apparaissent en majuscules, et uniquement lorsqu'ils apparaissent en majuscules, comme indiqué ici.

Un fichier WebP contient soit une image fixe (c'est-à-dire une matrice de pixels encodée), soit 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 blocs commence à 0 pour le bit le plus significatif ("MSB 0"), comme décrit dans la RFC 1166.

Vous trouverez ci-dessous d'autres termes utilisés dans ce document:

Lecteur/Écrivain

Le code qui lit les fichiers WebP est appelé lecteur, tandis que le code qui les écrit est appelé écrivain.

uint16

Entier non signé de 16 bits, little-endian.

uint24

Entier non signé de 24 bits, little-endian.

uint32

Entier non signé de 32 bits, en ordre octets de basse à haute.

FourCC

Un code à quatre caractères (FourCC) est un uint32 créé en concatenant quatre caractères ASCII dans l'ordre little-endian. Cela signifie que 'aaaa' (0x61616161) et 'AAAA' (0x41414141) sont traités comme des FourCCs différents.

Basé sur 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 l'en-tête FourCC et Taille de bloc de blocs individuels, où "ABCD" est le code FourCC du bloc. 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 bloc. 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                         :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FourCC de bloc: 32 bits

Code ASCII à quatre caractères utilisé pour l'identification des segments.

Taille de fragment: 32 bits (uint32)

Taille du segment en octets, sans inclure ce champ, l'identifiant du segment ni le remplissage.

Charge utile du fragment: taille du fragment en octets

Charge utile des données. Si la valeur Chunk Size est impaire, un seul octet de remplissage (qui DOIT être 0 pour être conforme à RIFF) est ajouté.

Remarque: Selon la convention RIFF, les codes FourCC de bloc en majuscules sont des blocs standards qui s'appliquent à tous les formats de fichier RIFF, tandis que les codes FourCC spécifiques à un format de fichier sont tous en minuscules. WebP ne suit pas cette convention.

En-tête de 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 de fichier: 32 bits (uint32)

Taille du fichier en octets, à partir d'un décalage de 8. La valeur maximale de ce champ est de 2^32 moins 10 octets. La taille du fichier entier est donc maximale de 4 Gio 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ées par Taille de fichier. Les lecteurs PEUVENT analyser ces fichiers, en ignorant les données de fin. Comme la taille de n'importe quel segment est paire, la taille indiquée par l'en-tête RIFF est également paire. 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 ne nécessite pas de transparence ni d'autres fonctionnalités avancées fournies par le format étendu. Les fichiers avec cette mise en page sont plus petits et compatibles avec les anciens logiciels.

Format de fichier WebP (avec 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)                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        'VP8 ' Chunk                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Données VP8: taille de bloc d'octets

Données du flux de bits VP8.

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

La spécification du format de flux de bits VP8 est décrite dans le Guide de format et de décodage des données VP8. 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 décrit 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 les 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                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fragment '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 des fragments octets

Données du flux de bits VP8L.

Vous trouverez la spécification actuelle du flux de bits VP8L sur la page WebP Lossless Bitstream Format. Notez que l'en-tête VP8L contient la largeur et la hauteur de l'image VP8L. Il s'agit de la largeur et de 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 fragment "VP8X" 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 bloc "XMP" facultatif avec des métadonnées XMP.

• Liste facultative de blocs inconnus.

Pour une image fixe, les données d'image se composent d'un seul frame, qui comprend les éléments suivants:

• Sous-bloc alpha facultatif.

• Sous-bloc de flux de bits

Pour une image animée, les données d'image se composent de plusieurs images. Pour en savoir plus sur les frames, consultez la section Animation.

Tous les blocs nécessaires à la reconstruction et à la correction des couleurs, à savoir "VP8X", "ICCP", "ANIM", "ANMF", "ALPH", "VP8" et "VP8L", DOIVENT apparaître dans l'ordre décrit 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.

Rationalité:Les segments 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 un fragment "ICCP".

Alpha (L): 1 bit

Indique si l'un des cadres de l'image contient des informations de 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éfinit si le fichier contient des métadonnées XMP.

Animation (A): 1 bit

Définissez s'il s'agit d'une image 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 du canevas en pixels,

basée sur 1. La largeur réelle du canevas est de 1 + Canvas Width Minus One.

Hauteur de la toile moins un: 24 bits

Hauteur du canevas en pixels, basée sur 1. La hauteur réelle du canevas est de 1 + Canvas Height Minus One.

Le produit des paramètres Largeur du canevas et 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

Une animation est contrôlée par des segments ANIM et ANMF.

Morceaux "ANIM" :

Pour une image animée, ce bloc contient les paramètres globaux 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 dans l'ordre d'octets [Bleu, Vert, Rouge, Alpha]. Cette couleur PEUT être utilisée pour remplir l'espace inutilisé sur le canevas autour des cadres, ainsi que les pixels transparents du premier cadre. La couleur d'arrière-plan est également utilisée lorsque la méthode de suppression est 1.

Remarques :

• 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 lecture DOIVENT considérer la valeur de la couleur d'arrière-plan comme une indication et ne sont pas obligatoires pour l'utiliser.

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

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 "infini".

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

Chunk "ANMF" :

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 bloc NE DOIT 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 frame moins un: 24 bits (uint24)

Largeur du cadre basée sur 1. 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 frame est 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 de frame de 0 (et souvent inférieure à 10) est définie par la mise en œuvre. De nombreux outils et navigateurs affectent une durée minimale semblable à celle des GIF.

Réservé: 6 bits

DOIT être 0. Les lecteurs DOIVENT ignorer ce champ.

Méthode de fusion (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é le frame précédent, affichez le frame actuel sur le canevas à l'aide d'un mélange alpha (voir ci-dessous). Si le frame actuel ne comporte pas de canal alpha, supposez que la valeur alpha est 255, ce qui remplace effectivement 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 le cadre actuel doit être traité après avoir été affiché (avant le rendu du cadre suivant) 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.

• Combinaison alpha:

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

  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 n'est pas présent, le RVB standard (sRVB) est supposé. (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

Elle se compose des éléments suivants:

• Sub-bloc alpha facultatif pour le frame.

• Un sous-bloc de flux de bits pour le frame.

• Liste facultative de blocs inconnus.

Remarque: La charge utile "ANMF", Frame Data, se compose de blocs individuels remplis, 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 sont utilisés pour signaler le prétraitement effectué lors de la compression. Le décodeur peut utiliser ces informations pour, par exemple, lisser les valeurs ou lisser les dégradés avant l'affichage.

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

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

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 X actuelle soient libellées comme suit:

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

Nous cherchons à calculer la valeur alpha à la position X. Tout d'abord, une prédiction est effectuée en fonction de 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. Par exemple, la valeur en haut à gauche à l'emplacement (0, 0) utilise 0 comme valeur du 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 en dégradé, les pixels les plus hauts à 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 frame contenant un segment "VP8L" NE DOIT PAS contenir ce segment.

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: il s'agit d'une séquence d'octets de longueur = largeur * hauteur, contenant toutes les valeurs de transparence 8 bits dans l'ordre de balayage.

• Compression de format sans perte: la séquence d'octets est un flux d'image compressé (comme décrit dans la section "Format de flux de bits sans perte WebP") 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.

  Rationalité: Les dimensions sont déjà connues à partir d'autres sources. Il serait donc redondant et sujet à des erreurs de les stocker à nouveau.

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

  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 bloc contient des données de flux de bits compressées pour un seul frame.

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: bloc d'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 devrait y avoir au maximum un bloc de chaque type ('EXIF' et 'XMP'). S'il y a plus de blocs de ce type, les lecteurs peuvent tous les ignorer, sauf le premier.

Les segments sont définis comme suit:

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

Métadonnées Exif: taille de bloc en octets

Métadonnées d'image au format Exif.

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

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 fragment RIFF (décrit dans la section Format de fichier RIFF) dont le fragment FourCC est différent de l'un des fragments décrits dans ce document est considéré comme un fragment inconnu.

Rationalité: L'autorisation des blocs inconnus permet de prévoir une future extension du format et permet également de stocker toutes les données spécifiques à l'application.

Un fichier peut contenir des segments inconnus:

• à la fin du fichier, comme décrit dans la section En-tête de fichier WebP étendu, ou
• à la fin des segments "ANMF", comme décrit dans la section Animation.

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

Assemblage de canevas à partir de cadres

Nous présentons ici comment un lecteur DOIT assembler un canevas dans le cas d'une image animée.

Le processus commence par la création d'un canevas à l'aide des dimensions indiquées dans le segment "VP8X", soit Canvas Width Minus One + 1 pixels de large sur 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é. Cette valeur est Loop Count - 1 pour les valeurs Loop Count non nulles ou infinie si Loop Count est égal à zéro.

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

Les fragments "ANMF" contiennent des cadres individuels présentés dans l'ordre d'affichage. Avant le rendu de chaque image, la Disposal method de l'image précédente est appliquée.

Le rendu du frame décodé commence aux coordonnées cartésiennes (2 * Frame X, 2 * Frame Y), en utilisant l'angle 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 s'affiche pendant Frame Duration millisecondes. Cette opération se poursuit jusqu'à ce que tous les frames donnés par les segments "ANMF" aient été affichés. Une nouvelle itération de boucle commence alors, ou le canevas est laissé dans son état final si toutes les itérations sont terminées.

Le pseudo-code suivant illustre le processus d'affichage. La notation VP8X.field 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)