Que change-t-il techniquement lors de la conversion d'un GIF en vidéo ?

Quand vous convertissez un GIF en MP4, le fichier devient dix fois plus léger alors que l'image reste presque identique. Comment est-ce possible et que se passe-t-il réellement pendant la conversion ? Dans cet article, nous expliquons les différences structurelles entre les deux formats et ce qui se produit à chaque étape.

Deux modèles d'animation différents

Dans un GIF, l'animation est une suite d'images indépendantes. Chaque image peut avoir :

• Sa propre palette de couleurs (256 entrées au maximum)
• Son propre délai d'affichage (en centièmes de seconde)
• Sa propre position et sa propre taille (un rectangle partiel plutôt qu'une image entière)
• Sa propre méthode d'élimination (ce qui advient d'elle avant l'image suivante)

Dans une vidéo, l'animation est une suite d'images alignées sur une grille temporelle fixe. La fréquence d'images est généralement constante (25, 30, 60 ips) et chaque image est affichée pendant la même durée.

Cette différence fondamentale de modèle est à l'origine de la première difficulté de la conversion.

Synchronisation : du délai variable à la fréquence constante

Les délais d'images d'un GIF peuvent ressembler à ceci :

Image 1 : 10 (0,10 s)
Image 2 : 10 (0,10 s)
Image 3 : 25 (0,25 s)  ← pause
Image 4 : 10 (0,10 s)
Image 5 :  5 (0,05 s)  ← transition rapide

La vidéo, elle, attend une fréquence d'images constante. Les options du convertisseur :

1. Choisir une fréquence assez élevée et répéter les images. Dans l'exemple ci-dessus, si l'on retient 20 ips (0,05 s par image), l'image de 0,25 seconde est répétée cinq fois. La synchronisation est parfaitement préservée mais le nombre d'images augmente — ce qui ne pose pas de problème de taille, les codecs vidéo compressant très efficacement les images répétées.

2. Choisir une fréquence moyenne et approximer. Plus simple, mais des écarts de synchronisation apparaissent.

La plupart des convertisseurs suivent la première voie. Cela dit, si les délais de votre GIF sont très irréguliers, une légère différence de rythme peut se ressentir.

Un détail : certains très anciens GIF portent un délai de 0 (le plus vite possible). Les navigateurs relèvent généralement cette valeur à un minimum, et les minimums diffèrent d'un navigateur à l'autre. En convertissant un tel GIF en vidéo, la vitesse obtenue peut donc différer de celle que vous voyiez dans votre navigateur.

La fusion des images partielles

Dans un GIF, une image peut n'être qu'un petit rectangle dessiné par-dessus la précédente et ne couvrant que la zone modifiée. Sur une animation à fond fixe, cela fait gagner beaucoup de place.

En vidéo, cette notion n'existe pas ; chaque image est en pleine taille.

Le convertisseur doit donc composer les images du GIF les unes après les autres pour produire l'image complète à chaque instant. Pour cela, il doit interpréter correctement la méthode d'élimination :

| Méthode | Signification | |---|---| | Non spécifiée | L'image reste telle quelle | | Conserver (Do not dispose) | L'image reste, la suivante se dessine par-dessus | | Revenir au fond | La zone de l'image est effacée avec la couleur de fond | | Revenir à l'état précédent | La zone de l'image revient à son état antérieur |

Une mauvaise interprétation se traduit dans la conversion par des traces « fantômes » ou des résidus accumulés. C'est un problème rare avec des convertisseurs bien écrits, mais qui peut survenir avec des GIF très anciens ou non conformes.

Couleur : de la palette à la couleur complète (mais sans retour en arrière)

Dans un GIF, chaque pixel est un indice de palette. Lors de la conversion, ces indices sont résolus en véritables valeurs RVB.

Le format vidéo prend en charge la couleur complète (16,7 millions) : il n'y a donc aucune limite technique.

Mais la source a déjà été ramenée à 256 couleurs. L'information perdue ne revient pas. La vidéo stocke ces 256 couleurs avec sa pleine capacité chromatique, et le résultat paraît visuellement identique au GIF.

Un effet secondaire intéressant : si un tramage a été appliqué au GIF (le motif pointillé utilisé pour masquer la limite de couleurs), ce motif est transporté dans la vidéo. Pour le codec vidéo, ce bruit est difficile à traiter — il le prend pour du détail réel et y dépense des bits. Sans débit suffisant, le motif de tramage devient flou ou provoque un effet de blocs.

Transparence : la fonctionnalité qui disparaît

Le GIF prend en charge une transparence binaire : un pixel est soit totalement transparent, soit totalement opaque. Il n'y a pas de valeur intermédiaire, c'est pourquoi les contours des GIF transparents paraissent crénelés.

Les codecs vidéo courants (profils standard du H.264 et du VP9) ne transportent pas de canal alpha. Chaque pixel est supposé opaque.

Lors de la conversion, les pixels transparents doivent être remplis d'une couleur — généralement du noir ou du blanc. Résultat : les zones qui laissaient voir l'arrière-plan dans le GIF deviennent des aplats de couleur dans la vidéo.

Si la transparence est nécessaire, la vidéo n'est pas la bonne cible. Les alternatives :

• WEBP animé : canal alpha 8 bits, bonne compression.
• APNG : canal alpha 8 bits, fichier plus lourd mais large prise en charge.

Les deux sont meilleurs que la transparence binaire du GIF — avec 256 niveaux de transparence, ils offrent des contours doux.

Le sous-échantillonnage de chrominance

C'est l'un des effets les plus techniques de la conversion, mais aussi l'un des plus visibles.

L'œil humain est bien plus sensible aux variations de luminosité (luma) qu'aux variations de couleur (chroma). Les codecs vidéo en tirent parti : ils stockent l'information de luminosité en pleine résolution et l'information de couleur à demi-résolution.

Ce schéma s'appelle 4:2:0 et c'est le réglage par défaut de l'encodage vidéo courant. L'information de couleur est divisée par deux horizontalement et verticalement — un quart des données de couleur est donc conservé.

Sur un contenu photographique, c'est quasi invisible. Mais sur les contenus fréquents dans les GIF, cela se remarque :

• Contours de couleur nets : du texte rouge sur fond blanc présente un léger flou sur les bords.
• Traits fins : les éléments d'interface colorés s'adoucissent.
• Petits caractères : la lisibilité peut baisser.

Certains codecs prennent en charge le profil 4:4:4 (information de couleur conservée en pleine résolution). Sur les captures d'écran et les animations contenant du texte, cela fait une différence nette, mais le fichier grossit et la compatibilité se restreint.

La contrainte des dimensions paires

Comme le sous-échantillonnage 4:2:0 stocke l'information de couleur par blocs de 2×2 pixels, il exige que la largeur et la hauteur soient des nombres pairs.

Les GIF n'ont pas cette contrainte ; des dimensions comme 401×267 sont fréquentes.

Le convertisseur résout cela de deux façons :

• Rognage : une colonne ou une ligne de pixels est supprimée (401 → 400).
• Remplissage : un pixel est ajouté (401 → 402), généralement en noir.

Ni l'un ni l'autre n'est visible à l'œil, mais le changement de dimensions apparaît dans les métadonnées.

Efficacité de compression : le vrai gain

Venons-en maintenant à la raison de l'écart spectaculaire de taille.

Les outils du GIF :

• Compression sans perte LZW (elle repère les motifs répétitifs)
• Image partielle (la zone rectangulaire modifiée)
• Pixel transparent (pour ignorer les pixels inchangés)

Les outils d'un codec vidéo :

• Estimation de mouvement (elle détermine où un bloc s'est déplacé)
• Prédiction intra-image (prédiction à partir des pixels voisins)
• Prédiction bidirectionnelle (en regardant les images précédentes et suivantes)
• Transformée fréquentielle et quantification (abandon des détails visuellement négligeables)
• Tailles de blocs variables
• Codage entropique

L'écart est catégorique. Le GIF dit « cette zone a changé, voici les nouveaux pixels » ; le codec vidéo dit « ce bloc de l'image précédente s'est décalé de 12 pixels vers la droite et s'est légèrement assombri ».

À cela s'ajoute le fonctionnement avec perte : le codec vidéo peut écarter des détails qui ne seront pas perçus. Le LZW du GIF est sans perte et n'a aucune souplesse de ce type.

Résultat : un écart de taille typique d'un facteur 5 à 10 pour un même contenu.

Ce qui se perd, ce qui se gagne

| Aspect | GIF | Après passage en vidéo | |---|---|---| | Taille du fichier | Grande | 5 à 10 fois plus petite | | Richesse de couleur | 256 (limite) | Couleur complète (mais source en 256) | | Transparence | Binaire | Aucune | | Prise en charge e-mail | Oui | Non | | Lecture automatique | Native | Attribut requis | | Contours de couleur nets | Complets | Léger adoucissement (4:2:0) | | Souplesse de synchronisation | Par image | Fréquence constante |

En résumé

Le GIF et la vidéo abordent l'animation avec des modèles différents : dans le GIF, chaque image a son propre délai, sa propre palette et sa propre zone partielle ; dans la vidéo, on trouve des images complètes sur une grille temporelle fixe. La conversion compose les images et normalise la synchronisation vers une fréquence constante. Du point de vue de la couleur, il n'y a pas de perte mais pas de gain non plus — la limite des 256 couleurs a déjà été appliquée. La transparence, elle, disparaît, car les codecs vidéo courants ne transportent pas de canal alpha. Le sous-échantillonnage de chrominance crée un léger adoucissement des contours de couleur nets, et la contrainte des dimensions paires peut imposer un rognage d'un pixel. En contrepartie, le gain est important : la capacité des codecs vidéo à estimer le mouvement et à travailler avec perte permet de stocker le même contenu dans un cinquième à un dixième de la taille.