Pourquoi un GIF de trois secondes pèse plus lourd que la vidéo d'origine

Un format de 1989 qui n'a jamais appris le mouvement

La spécification GIF89a décrit une animation comme une suite d'images séparées par un délai. C'est tout le modèle. Aucune notion de scène qui persiste, aucun vecteur disant au décodeur que ce bloc de pixels est celui de l'image précédente déplacé de onze pixels vers la gauche. Les codecs vidéo modernes consacrent presque toute leur intelligence à cette idée précise, et c'est de là que vient presque toute leur compression : dans un plan de visage qui parle, le mur derrière la tête est transmis une fois puis simplement référencé pendant trois cents images. Un GIF n'a aucun moyen de référencer quoi que ce soit.

Il existe une exception rudimentaire, et elle mérite d'être connue car elle explique pourquoi certains GIF se comportent bien mieux que l'arithmétique ne le prédit. Une image peut être écrite comme un rectangle plus petit placé à un décalage, et les pixels inchangés depuis l'image précédente peuvent être marqués transparents plutôt que stockés. FFmpeg — le moteur qu'utilise cet outil — active les deux par défaut. Sur une capture d'écran où un curseur traverse une fenêtre immobile, c'est énorme : l'essentiel de chaque image s'effondre à rien. Sur des images de caméra, où le bruit du capteur fait que presque chaque pixel diffère légèrement du précédent, cela n'économise presque rien. Cette seule distinction explique pourquoi les mêmes réglages produisent un GIF de 300 ko depuis une capture d'écran et un GIF de 5 Mo depuis un extrait filmé à la main.

L'arithmétique, et où se cache le seul chiffre flou

Octets ≈ largeur × hauteur × images × b ÷ 8. Tout ce qui est à droite est exact sauf b, le nombre de bits que coûte chaque pixel une fois LZW passé. Avant compression, chaque pixel est un indice dans une table d'au plus 256 couleurs : il part donc de 8 bits. Sur du contenu photographique tramé, LZW ramène généralement cela entre 2 et 5, d'où l'honnêteté de prendre b = 3 pour une première estimation en acceptant une justesse à un facteur deux près. Cela paraît approximatif jusqu'à ce qu'on remarque que c'est le même facteur deux qu'on obtiendrait en devinant un débit vidéo, et que cela suffit à savoir si l'on est à un réglage de sa limite ou à quatre.

Une chose que l'outil ne fait pas : mesurer les couleurs de ton extrait. Une chaîne GIF de qualité fait deux passes, l'une pour construire une palette à partir des pixels réellement présents, l'autre pour y projeter les images. Cet outil ne fait qu'une passe : les 256 emplacements sont remplis depuis une table générique plutôt que depuis tes images. La conséquence visible, ce sont des bandes dans les ciels, les dégradés et les teints, et une légère grossièreté dans les zones sombres. La conséquence invisible porte sur la taille, et elle joue dans les deux sens : une palette générique tramoie davantage, et le tramage ajoute un bruit haute fréquence que LZW déteste, ce qui pousse b vers le haut. Si ton extrait a peu de couleurs au départ — une animation de logo, un graphique, une fenêtre de terminal — rien de tout cela ne mord, et le fichier sortira très en dessous de l'estimation.

Le champ largeur n'est pas un champ taille

Tu saisis une largeur ; l'outil calcule la hauteur d'après la forme de l'extrait. Pour un extrait paysage 16:9, 480 donne 480 × 270, soit 129 600 pixels par image. Pour une vidéo de téléphone tenue à la verticale, ce même 480 donne 480 × 853, soit 409 440 pixels par image : plus de trois fois plus, pour le même chiffre tapé dans le même champ. C'est la raison la plus fréquente d'un GIF anormalement énorme, et elle est invisible dans l'interface, qui ne montre qu'une des deux dimensions.

La correction tient en une ligne. Pour qu'un extrait vertical pèse ce que pèse un extrait paysage de 480 de large, demande 270 de large : 270 × 480 fait exactement 129 600 pixels. Plus généralement, fixe un budget de pixels par image plutôt qu'une largeur. Entre 120 000 et 150 000 pixels par image, on reste confortable dans une fenêtre de discussion quelle que soit la forme — c'est 480 × 270 en paysage, 270 × 480 en portrait, ou 360 × 360 en carré — et il ne reste plus à discuter que la cadence et la durée.

La cadence demandée n'est probablement pas celle obtenue

Voici de l'archéologie de format pure, et elle piège tout le monde. La spécification GIF89a stocke la pause avant l'image suivante en centièmes de seconde — le champ, selon ses propres termes, « indique le nombre de centièmes (1/100) de seconde à attendre ». Pas d'unité plus fine, pas de fraction. Une cadence n'est donc reproductible que si 100 se divise exactement par elle. Dans la plage offerte par cet outil, cela veut dire 2, 4, 5, 10, 20 et 25 images par seconde, et rien d'autre.

La valeur par défaut de 12 n'en fait pas partie. Un douzième de seconde vaut 8,33 centièmes, et le fichier ne peut contenir que 8 ou 9 — soit 12,5 ou 11,1 images par seconde à la lecture, si bien que ton extrait de huit secondes dure 7,68 ou 8,64 secondes. Personne qui regarde un GIF de chat ne le remarquera. Quelqu'un qui regarde un décompte, un métronome, un chronomètre de tour ou une capture d'écran où tu démontres un bug de temporisation, absolument. Trente est pire : un trentième de seconde vaut 3,33 centièmes, le fichier retient 3, et la lecture ressort à 33,3 images par seconde — onze pour cent trop vite. Si le temps compte, prends 10, 20 ou 25 et le fichier jouera à la cadence demandée.

Quand la bonne réponse n'est pas un GIF

La taille d'une vidéo obéit à une autre formule, bien plus aimable : octets = débit × secondes ÷ 8. Huit secondes à 800 kbit/s font 800 ko, et 800 kbit/s achètent un extrait parfaitement regardable en pleine résolution à trente images par seconde. C'est presque six fois moins que le GIF construit sur les mêmes huit secondes au cinquième de la résolution et au tiers de la cadence — et la vidéo a du son, si tu en veux. Toutes les messageries, tous les forums modernes, tous les gestionnaires de tickets et tous les réseaux sociaux lisent MP4 et WebM en ligne et les bouclent à la demande. La boucle en lecture automatique que l'on appelle « un GIF » sur le web aujourd'hui est, neuf fois sur dix, un MP4 muet.

Garde donc le GIF pour les cas où rien d'autre n'est accepté, et il en existe de vrais : un wiki ou un gestionnaire de tickets qui n'accepte que des images en pièce jointe, un client de messagerie qui n'intègre pas la vidéo, un vieux forum dont l'éditeur a un bouton image et rien de plus, un README rendu quelque part qui supprime les balises vidéo. À ces endroits, le GIF n'est pas un choix nostalgique, c'est la seule image animée qui survivra au voyage. Partout ailleurs, convertir en GIF revient à payer cinq à dix fois plus d'octets pour perdre le son, la plupart des couleurs et la moitié des images.

Deux petites choses sur cet outil précis

Il commence toujours à la seconde zéro. Le champ de durée est un plafond sur la sortie, pas une fenêtre déplaçable : les huit secondes obtenues sont les huit premières du fichier. Si le moment voulu est à 0:42, découpe d'abord l'extrait avec l'outil de découpe et donne-lui le morceau coupé. Ce n'est pas une limite que l'on contourne avec une durée plus grande : régler le maximum à 30 donne les trente premières secondes et un GIF que personne ne pourra publier nulle part.

Et la taille affichée est mesurée en unités de 1 048 576 octets tout en les appelant Mo. C'est un mébioctet portant l'étiquette d'un mégaoctet, un relâchement très ancien et très répandu. Cela ne compte qu'à un endroit : une limite exprimée en 10 000 000 octets vaut 9,54 des « Mo » de l'outil, si bien qu'un fichier que l'outil annonce fièrement à 10,0 Mo dépasse cette limite de près d'un demi-mégaoctet. Quand tu vises un plafond strict, vise cinq pour cent en dessous et cesse de penser aux unités.

Questions fréquentes

Peut-on mettre plus de 256 couleurs dans un GIF ?

Sur l'ensemble du fichier, oui ; à l'intérieur d'une image, non. La spécification permet à chaque bloc d'image de porter sa propre table de couleurs locale : une animation de vingt images pourrait en principe utiliser vingt palettes et toucher plusieurs milliers de couleurs distinctes au total. Mais chaque image reste limitée à 256, et une table locale coûte jusqu'à 768 octets à chaque changement. En pratique cela apporte très peu sur de la vidéo, car l'œil compare les images voisines et une palette qui change entre elles produit un scintillement visible. Le vrai gain accessible à un encodeur GIF n'est pas plus de couleurs mais de meilleures couleurs — une palette mesurée sur tes images plutôt qu'une table générique.

Mon GIF est encore trop lourd et j'ai déjà réduit la largeur. Et maintenant ?

Réduis ensuite la durée, puis la cadence, dans cet ordre. Durée et cadence sont toutes deux linéaires par rapport au nombre d'images, donc elles rapportent autant l'une que l'autre — mais un extrait plus court est presque toujours un meilleur extrait, alors qu'une cadence plus basse est une dégradation visible en dessous de 8 images par seconde environ, où le mouvement se met à ressembler à un diaporama. Deux secondes à 10 images par seconde font vingt images, et vingt images de 320 × 180 à 3 bits font 432 ko. Si même cela dépasse, la conclusion honnête est que le contenu ne se comprime pas : vérifie s'il s'agit d'images de caméra avec un fond mobile, et si oui, recadre serré sur ce qui compte ou accepte qu'il faille une vidéo.

Le GIF garde-t-il le son ?

Non, et il ne le pourra jamais : le format n'a pas de piste audio ni d'endroit où en mettre une. Cela vaut la peine d'être dit clairement car c'est un échec silencieux — rien ne te prévient, la conversion réussit, et tu le découvres en publiant un extrait dont tout l'intérêt était une réplique. Si c'est le son que tu voulais partager, la réponse est une vidéo, ou l'audio seul : ce site a un outil qui extrait la bande-son d'un fichier vidéo en MP3, AAC ou WAV sans toucher à l'image.

Pourquoi mon GIF est-il granuleux dans les zones sombres alors que la vidéo était propre ?

Parce que 256 couleurs doivent couvrir toute l'étendue du noir au blanc, et que dans une scène sombre l'essentiel de l'image se tasse dans une poignée d'entre elles. L'encodeur comble le manque en tramant — en dispersant des pixels de deux couleurs disponibles pour en simuler une troisième — et dans les aplats sombres cette dispersion se lit comme du grain. Cela coûte aussi en taille, car le tramage est un bruit haute fréquence et le bruit haute fréquence est précisément ce que LZW ne sait pas comprimer. Deux choses aident : éclaircir ou recadrer l'extrait avant conversion pour qu'une moindre part vive dans la zone écrasée, et privilégier un contenu aux couleurs franches et plates. Rien ne corrige cela entièrement à l'intérieur du format, ce qui est une raison de plus pour que la réponse soit souvent une vidéo.

La vidéo quitte-t-elle mon ordinateur pendant l'opération ?

Non. La conversion tourne dans la page, dans une compilation de FFmpeg en WebAssembly, et le moteur lui-même est servi depuis ce site et non depuis un réseau tiers — si bien que même son téléchargement unique ne livre ton adresse à personne. Une conséquence visible est à prévoir : la première conversion d'une session télécharge environ 32 Mo de moteur et prend un moment, et toutes les suivantes démarrent immédiatement. Et un test tranche la question sans avoir à nous croire : charge la page, coupe le réseau, convertis un extrait. Si cela fonctionne encore, rien n'a été envoyé.