Vidéo en GIF : le poids en octets par pixel et par image, mesuré

Notre outil de conversion vidéo en GIF estime la taille du fichier à partir d’une constante de 0.45 octet par pixel et par image, et prévient que ce chiffre peut se tromper d’un facteur deux dans un sens comme dans l’autre. Nous avons mesuré l’ampleur de l’erreur, et sur quels contenus.

L’unité

Les octets par pixel et par image correspondent à la taille d’un GIF divisée par sa largeur, sa hauteur et son nombre d’images. Cette unité isole ce que le GIF fait mal (stocker chaque image comme une image 8 bits complète compressée en LZW, sans aucune référence à l’image précédente) des choix qui ne font que la multiplier. Diviser la largeur par deux divise le fichier par quatre, quelle que soit la valeur de ce chiffre ; le chiffre lui-même dépend de l’image.

La mesure

Deux extraits de quatre secondes, tous deux décodés en 50 images en 480 × 270 à 12.5 images par seconde : une photo avec un lent panoramique et un zoom, pour que chaque image diffère de la précédente, et un enregistrement d’écran Chromium montrant le défilement de deux pages de ce site. Chaque série d’images a été encodée dans Chromium sans interface avec modern-gif 2.1.0, l’encodeur qu’utilise l’outil, avec cinq tailles de palette, avec et sans tramage Floyd–Steinberg. Les mêmes 50 images ont aussi été encodées avec FFmpeg 6.0 en H.264 à CRF 23 et CRF 18, et en VP9 à CRF 33. Mesures effectuées le 1er octobre 2026.

Palette	Photo en mouvement	Octets par pixel et par image	Enregistrement d’écran	Octets par pixel et par image
255 couleurs, avec tramage	4 171 930 o	0.644	716 151 o	0.111
255 couleurs, sans tramage	4 188 639 o	0.646	685 764 o	0.106
128 couleurs, avec tramage	3 674 083 o	0.567	685 507 o	0.106
64 couleurs, avec tramage	3 115 969 o	0.481	637 659 o	0.098
32 couleurs, avec tramage	2 569 888 o	0.397	549 810 o	0.085
16 couleurs, avec tramage	2 010 333 o	0.310	506 418 o	0.078

La première ligne correspond à ce que produit l’outil, puisqu’il encode en 255 couleurs avec le tramage activé. L’encodeur de palette propre à FFmpeg a produit 3 670 375 octets et 726 687 octets pour les deux mêmes sources en 256 couleurs, soit à moins de 12% de modern-gif sur la photo et à 1.5% sur l’enregistrement : les chiffres décrivent donc le format plutôt qu’une bibliothèque en particulier.

Les mêmes images en vidéo

Encodage	Photo en mouvement	Enregistrement d’écran
GIF, 255 couleurs, avec tramage	4 171 930 o	716 151 o
H.264, CRF 18	178 684 o	179 566 o
H.264, CRF 23	78 138 o	131 975 o
VP9, CRF 33	39 613 o	105 788 o

« Un GIF pèse environ dix fois le MP4 » : c’est le chiffre qu’on donne d’ordinaire. Sur la photo, il pesait 53 fois plus à CRF 23, 23 fois plus même à CRF 18, et 105 fois plus que le VP9. Sur l’enregistrement d’écran, 5.4 fois plus. La photo est le cas où les codecs vidéo sont à leur meilleur, car la prédiction de mouvement réduit une image en panoramique à quelques instructions par bloc ; le GIF n’a rien de tel et paie chaque pixel à chaque image.

Ce que la palette fait gagner

Passer de 255 à 16 couleurs a divisé par deux le poids de la photo et retiré 29% à celui de l’enregistrement. C’est un gain réel, et c’est le plus laid qui soit : des aplats en escalier sur chaque dégradé et des peaux postérisées. Réduire la largeur de 480 à 340 fait gagner les mêmes 50% et se voit beaucoup moins, c’est pourquoi notre outil met en avant la largeur et la fréquence d’images avant tout autre réglage.

Le tramage ne coûte presque rien en octets (moins de 1% sur la photo, 4% sur l’enregistrement), mais multiplie par deux à quatre le temps d’encodage. À 16 couleurs, les fichiers avec et sans tramage avaient exactement la même taille, à l’octet près, sur les deux extraits.

L’estimation face à la mesure

À 0.45 octet par pixel et par image, l’outil aurait estimé 2.92 Mo pour les deux extraits. La photo a dépassé ce chiffre de 43% et l’enregistrement d’écran est resté 75% en dessous. Une seule constante ne peut pas décrire un format dont le rapport dépend entièrement du contenu : c’est pourquoi l’estimation est présentée comme approximative et le chiffre réel affiché à côté une fois l’export terminé. Mesurée sur une seule image, la photo coûtait 0.668 octet par pixel et l’interface 0.224 : si vous devez savoir à l’avance, faire passer une image dans l’encodeur prédit mieux que n’importe quelle constante.

En bref

Pour des images photographiques, comptez environ 0.6 octet par pixel et par image et un fichier cinquante fois plus lourd que le MP4 ; pour des images d’interface en aplats, environ 0.1 et cinq fois plus. La largeur est le vrai levier ; la palette, le dernier recours ; et au-delà de quelques secondes, un GIF n’est qu’une vidéo qui porte la mauvaise extension.