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 un transfert d'image rapide sur le réseau (pour 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: vous pouvez compresser une image sans perte à l'aide de la méthode 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 présenter de la transparence, c'est-à-dire 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 WebP. conteneur:

Nom du format du conteneurWebP
Extension de nom de fichier.webp
Type MIMEimage/webp
Identifiant de type uniformeorg.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. Elle peut également contenir des éléments de transparence des informations, un profil de couleur et des métadonnées. Nous appelons la matrice de pixels comme 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 petit-endian non signé de 16 bits.
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 "aaaa" (0x61616161) et "AAAA" (0x41414141) sont traitées comme des valeurs FourCCs différentes.
En base 1
Champ d'entier non signé stockant des valeurs décalées par -1, par exemple stockerait la valeur 25 en tant que 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 fichier RIFF (Resource Interchange File Format). le format du document.

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 l'identification des fragments.
Taille du 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 respecte 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", "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 de 2^32 moins 10 octets, et la taille de l'ensemble du fichier est donc 4 Gio moins 2 octets.
"WEBP" : 32 bits
Les caractères ASCII "W", "E", "B", "P".

Un fichier WebP DOIT commencer par un en-tête RIFF suivi du "WEBP" de FourCC. Taille du fichier dans l'en-tête est la taille totale des fragments qui suivent plus 4 octets pour le "WEBP" FourCC 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. Comme la taille d’un segment est égale, la taille donnée par l’en-tête RIFF est également. Le contenu de chaque fragment est décrit dans les éléments suivants : .

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 des fragments 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 la trame VP8 contient la trame VP8. la largeur et la hauteur. 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. À convertir au format RVB, la recommandation BT.601 DEVRAIT être utilisée. Candidatures MAI utilisent 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:Il est possible que les lecteurs plus anciens ne soient pas compatibles avec les fichiers utilisant le format sans perte.

Cette mise en page DOIT être utilisée si l'image nécessite un encodage sans perte (avec une canal de transparence facultatif) et ne nécessite pas de fonctionnalités avancées 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                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"VP8L" 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('VP8L')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                           VP8L data                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Données VP8L: Taille des fragments 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 « ICCP » facultatif Fragment avec profil de couleur.

  • Un ANIM (facultatif) Fragment avec données de commande d'animation.

  • Données d'image.

  • Un « EXIF » facultatif Fragmenter avec les 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 sont composées de plusieurs cadres. 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 des fragments sont nécessaires à la reconstruction et la correction des couleurs sont dans le désordre.

Des fragments métadonnées et inconnus PEUVENT apparaître sur commande.

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. Faire varier l'ordre des métadonnées et l'emplacement des fragments personnalisés adaptés à 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éfinir si le fichier contient un "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
Définit 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éfinissez s'il s'agit d'une image animée. Données en ANIM et "ANMF" Les fragments 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 du canevas moins un: 24 bits
Largeur basée sur 1 du canevas en pixels. La largeur réelle du canevas est de 1 + Canvas Width Minus One.
Hauteur du canevas moins un: 24 bits
Hauteur basée sur 1 du canevas en pixels. 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 ultérieurement. 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 mise au rebut est 1.

Remarque :

  • La couleur d'arrière-plan PEUT contenir une valeur alpha non opaque, même si le l'indicateur Alpha dans le code "VP8X" ; Fragment non défini.

  • Les lecteurs DOIVENT traiter la valeur de la couleur d'arrière-plan comme une indication et ne sont pas nécessaires pour 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 lectures en boucle de l'animation. 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 fragment est présent, il DOIT être sont ignorées.

"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.
Trame Y: 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 de la trame: 24 bits (uint24)
Délai d'attente avant l'affichage de l'image suivante, en unités d'une 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 associent une configuration minimale semblable à celle du GIF.
Réservé: 6 bits
DOIT être 0. Les lecteurs DOIVENT ignorer ce champ.
Méthode de combinaison (B): 1 bit

Indique le niveau de transparence des pixels transparents de l'image actuelle. par les pixels correspondants du canevas précédent:

  • 0: utilisez la combinaison 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 fusionner. Après avoir supprimé l'image précédente, effectuez le rendu cadre actuel sur le canevas en écrasant le rectangle couvert par le cadre 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 jeter. Laissez le canevas tel quel.

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

Remarques :

  • L'élimination des cadres ne s'applique qu'au rectangle du cadre, c'est-à-dire aux rectangle défini par les paramètres Frame X, Frame Y, frame width et Framework hauteur. 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 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

  • La combinaison alpha DOIT être effectuée dans un espace de couleurs linéaire, en tenant compte le profil de couleur de l'image. Si le profil de couleur est absente, le format RVB standard (sRVB) est utilisé. Notez que le format sRVB doit être linéarisée en raison d'un gamma d'environ 2,2).

Données de trame: Taille - 16 octets

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 sont utilisés pour signaler le prétraitement qui a 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: aucun 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 de l'ajout de 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 chaîne [0..255] :

alpha = (predictor + X) % 256

Il existe des cas particuliers pour les positions de pixel situées tout à gauche et tout 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 dégradé, les pixels situés le plus à gauche (0, y) sont prédits à partir de la position (0, y-1) située juste au-dessus.
  • Pour les méthodes de filtrage vertical ou en dégradé, les pixels les plus élevés (x, 0) sont prédits à l'aide de la position (x-1, 0) indiquée sur la gauche.
Méthode de compression (C): 2 bits

Méthode de compression utilisée:

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

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.

Logique: Les informations sur la transparence font déjà partie du format VP8L. Un morceau.

Les données du canal alpha sont stockées sous forme de données brutes non compressées (lorsque les méthode de compression est '0') ou compressée au 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. En d'autres termes, image-stream ne contient PAS d'en-tête 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 le flux d'images décodé en couleurs Alpha, Rouge, Vert, Bleu (ARVB), , en suivant le processus décrit dans le format sans perte les informations de transparence doivent être extraites canal green du quadruplet ARVB.

    Justification: Une transformation supplémentaire est autorisée pour le canal vert. étapes de la spécification, contrairement aux autres canaux, qui peuvent pour améliorer la compression.

Bitstream (VP8/VP8L)

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

Un fragment de flux de bits peut être (i) un bloc "VP8" Fragment, avec "VP8" (notez que un espace important de quatrièmes caractères) comme son FourCC, ou (ii) une "VP8L" Fragments avec "VP8L" FourCC.

Formats de "VP8" et "VP8L" Les fragments sont décrits dans les sections Format de fichier simple (avec perte) et Simple File Format (lesss) respectivement.

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 fragment DOIT apparaître avant les données d'image.

Il DOIT y avoir au maximum un fragment. S'il y a plus de fragments de ce type, les lecteurs PEUT ignorer la première. Pour en savoir plus, consultez la spécification 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 "EXIF" ou "XMP" Des morceaux.

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 fragments 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 de "XMP" FourCC est un espace ASCII (0x20).

Pour en savoir plus sur la gestion des métadonnées, consultez la Consignes pour la gestion des métadonnées du groupe de travail sur les métadonnées.

Fragments inconnus

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

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 de "ANIM" La façon dont les fragments sont contrôlés plusieurs fois que le processus d'animation est répété. Il s'agit de Loop Count - 1 pour des valeurs Loop Count non nulles ou "infinie" si Loop Count est égal à zéro.

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

"ANMF" Les fragments contiennent des images individuelles présentées dans l'ordre d'affichage. Avant le rendu à chaque image, la Disposal method du frame précédent est appliquée.

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 par Frame Height Minus One + 1 pixels hauts 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 de rendu. La notation VP8X.field désigne le champ contenu dans "VP8X". Fragment avec 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)