Pourquoi un GIF est-il si lourd ? 256 couleurs, LZW et structure d'images

Le GIF est un format conçu en 1987 qui n'a pratiquement pas changé depuis. Il reste largement utilisé aujourd'hui, mais il est dramatiquement inefficace face aux alternatives modernes. Dans cet article, nous examinons la structure interne du format pour expliquer pourquoi il produit des fichiers aussi lourds et où il reste malgré tout pertinent.

Le modèle de couleur par palette

La caractéristique la plus déterminante du GIF est sa façon de stocker la couleur.

Dans les formats d'image modernes, chaque pixel porte sa propre valeur de couleur : 8 bits de rouge, 8 bits de vert, 8 bits de bleu — soit environ 16,7 millions de couleurs possibles.

Le GIF fonctionne autrement. Il conserve une table de couleurs (palette) et chaque pixel enregistre un indice dans cette table. La palette peut contenir au maximum 256 entrées.

Palette :
  0 → #000000 (noir)
  1 → #FF0000 (rouge)
  2 → #00FF00 (vert)
  ...
  255 → #FFFFFF (blanc)

Données de pixels : 0, 0, 1, 1, 2, 0, 255, ...

Son avantage : chaque pixel occupe 8 bits au lieu de 24. Dans les conditions de mémoire de 1987, c'était un gain considérable.

Son inconvénient : l'image ne peut contenir que 256 couleurs différentes au maximum.

Le prix visuel des 256 couleurs

Une image vidéo contient typiquement des dizaines de milliers de couleurs différentes. Les ramener à 256 nécessite une quantification des couleurs : l'algorithme analyse les couleurs de l'image, choisit les 256 les plus représentatives et associe chaque pixel à l'entrée de palette la plus proche.

Les conséquences visibles :

Le banding (bandes). Un dégradé doux — ciel, transition lumineuse, ombre — se transforme en bandes de couleur uniforme. La continuité disparaît, un aspect en marches d'escalier apparaît.

La dégradation des tons de peau. Les visages humains contiennent de nombreux tons proches et la palette peine à les distinguer. Le résultat est un aspect tacheté, maladif.

La dérive des couleurs. Les couleurs sans équivalent exact dans la palette sont arrondies à leur voisine la plus proche ; le bleu institutionnel de votre marque peut virer vers un bleu légèrement différent.

Un résultat qui varie selon le type de contenu :

| Contenu | Résultat en 256 couleurs | |---|---| | Capture d'écran, interface | Généralement bon (peu de couleurs au départ) | | Dessin animé, illustration | Bon | | Texte et graphiques | Très bon | | Paysage naturel | Banding marqué | | Visage humain, peau | Tacheté | | Scène nocturne, dégradé | Mauvais |

Le tramage : une astuce visuelle

Pour adoucir le banding, on utilise le tramage (dithering). L'idée : entremêler deux couleurs de la palette sur des pixels voisins pour donner, vu de loin, l'impression de percevoir la teinte intermédiaire.

C'est le même principe que les points noirs qui créent des gris dans les photographies de journaux.

Le tramage améliore nettement la qualité visuelle — les bandes disparaissent, les dégradés s'adoucissent. Mais il a un prix, et ce prix se répercute directement sur la taille du fichier.

La contradiction entre compression LZW et tramage

Le GIF utilise une compression sans perte appelée LZW (Lempel-Ziv-Welch). Le LZW repère les motifs répétitifs dans les données et les remplace par des codes courts. Par exemple, une séquence comme « 0,0,0,0,0,0 » est codée très brièvement.

Cela fonctionne très bien sur les images contenant des aplats de couleur : logos, graphiques, captures d'écran d'interface.

Maintenant, considérez l'effet du tramage : il rend délibérément bruités les aplats. Au lieu de « 0,0,0,0,0,0 », on obtient un motif du genre « 0,1,0,1,1,0 ».

Le LZW ne trouve plus de répétition dans ce bruit. L'efficacité de compression chute, le fichier grossit.

Autrement dit, le tramage améliore la qualité visuelle mais augmente aussi la taille du fichier. Lors de la production d'un GIF, vous devez trouver un équilibre entre les deux.

L'optimisation entre images : un mécanisme limité

Le GIF stocke l'animation sous forme d'images qui se succèdent. Chaque image peut avoir sa propre durée (valeur de délai) et sa propre palette.

Le format propose un certain degré d'optimisation :

Image partielle. Une image peut ne contenir qu'une zone rectangulaire modifiée plutôt que l'image entière. Sur une animation à fond fixe, le gain est considérable.

Pixel transparent. Les pixels inchangés peuvent être marqués transparents pour laisser apparaître l'image précédente.

Méthode d'élimination (disposal method). Elle indique ce que devient l'image courante avant la suivante : la conserver, revenir au fond, revenir à l'état précédent.

Ces mécanismes fonctionnent, mais ils restent primitifs face aux codecs vidéo modernes. La raison : le GIF ne connaît pas la notion de mouvement.

Un codec vidéo peut détecter qu'un objet s'est déplacé de 12 pixels vers la droite et dire « prends ce bloc de l'image précédente, décale-le de 12 pixels à droite » — quelques octets. Le GIF, lui, ne peut que dire « cette zone rectangulaire a changé, voici ses nouveaux pixels » — des milliers d'octets.

Dès qu'il y a un mouvement de caméra ou un changement de plan, l'optimisation par image partielle devient totalement inopérante : tous les pixels changent à chaque image.

Comparaison chiffrée

Pour un même contenu de 5 secondes, 480×270 pixels, 15 ips, grossièrement :

| Format | Taille typique | Couleur | |---|---|---| | GIF | 3 à 8 Mo | 256 | | WEBP animé | 800 Ko à 2 Mo | Complète | | APNG | 2 à 5 Mo | Complète + alpha | | MP4 (H.264) | 200 à 500 Ko | Complète | | WEBM (VP9) | 150 à 400 Ko | Complète |

Le MP4 transporte le même contenu dans environ un dixième de la taille du GIF, avec une qualité de couleur bien supérieure. Cet écart n'est pas une petite optimisation, c'est une supériorité catégorique.

Les trois facteurs qui déterminent la taille du fichier

La taille d'un GIF croît selon le produit de trois variables :

Durée × fréquence d'images = nombre total d'images. 10 secondes × 20 ips = 200 images. 5 secondes × 12 ips = 60 images. Un tiers.

Résolution = pixels par image. Diviser la largeur par deux réduit le nombre total de pixels au quart.

Quand vous multipliez tout cela :

• 10 s, 20 ips, 800×450 : 200 images × 360 000 pixels = 72 millions de pixels
• 5 s, 12 ips, 400×225 : 60 images × 90 000 pixels = 5,4 millions de pixels

Un écart d'environ 13 fois. C'est pourquoi, pour réduire la taille d'un GIF, il faut agir non sur un seul réglage mais sur les trois à la fois.

Quatrième facteur : la quantité de mouvement. Une scène fixe bénéficie de l'optimisation par image partielle et devient très légère. Une scène avec mouvement de caméra sera, aux mêmes réglages, plusieurs fois plus lourde.

Pourquoi les alternatives modernes ne s'imposent pas

Le WEBP animé et l'APNG sont supérieurs au GIF à tous points de vue : couleur complète, transparence alpha, compression bien meilleure. Tous les navigateurs modernes les prennent en charge.

Ce qui freine leur diffusion n'est pas technique mais tient à l'habitude de l'écosystème :

• Les messageries traitent le GIF comme un type à part et proposent des bibliothèques de recherche.
• Les logiciels de forum et les systèmes de wiki connaissent les balises GIF.
• Les clients de messagerie affichent les animations GIF (ils ne lisent pas de vidéo).
• Les gens disent « envoie un GIF » ; personne ne dit « envoie un WEBP animé ».

Il y a là une ironie : de nombreuses plateformes convertissent en arrière-plan le GIF que vous téléversez en MP4 et vous le présentent comme un GIF. Autrement dit, quand vous dites « je partage un GIF », vous partagez en réalité une vidéo.

La bonne approche sur le web

Si vous voulez afficher une animation sur votre propre site web, il n'y a aucune raison d'utiliser un GIF :

<video autoplay muted loop playsinline>
  <source src="animation.webm" type="video/webm">
  <source src="animation.mp4" type="video/mp4">
</video>

Cela donne exactement le même comportement qu'un GIF — pas de son, lecture automatique, boucle infinie — mais dans un dixième de la taille et avec une qualité de couleur complète.

L'attribut playsinline empêche la vidéo de passer en plein écran sur les navigateurs mobiles ; il est indispensable pour obtenir un comportement de type GIF.

En matière de vitesse de page, l'écart est spectaculaire : une vidéo de 400 Ko à la place d'un GIF de 5 Mo raccourcit nettement le temps de chargement.

Là où le GIF reste pertinent

• Les environnements qui ne prennent pas en charge la vidéo : certains logiciels de forum, anciens systèmes de wiki.
• L'e-mail : la plupart des clients ne lisent pas de vidéo mais affichent les GIF (certains n'en montrent que la première image).
• Les bibliothèques de GIF des messageries.
• Les animations simples à peu de couleurs : indicateurs de chargement, petites animations d'icônes — la limite de 256 couleurs n'y pose pas de problème et le GIF reste d'une taille raisonnable.

En résumé

Le GIF fonctionne avec un modèle par palette de 256 couleurs, ce qui provoque du banding et un aspect tacheté sur les contenus photographiques ; le tramage adoucit visuellement le problème mais alourdit le fichier en réduisant l'efficacité de la compression LZW. Le format n'exploite la redondance entre images que de façon primitive — il n'a pas la notion de mouvement et ne peut que stocker les zones rectangulaires modifiées. Résultat : pour un même contenu, il occupe environ dix fois plus de place que les codecs vidéo modernes. Comme la taille du fichier croît selon le produit de la durée, de la fréquence d'images et de la résolution, tout effort de réduction doit porter sur les trois à la fois. Et pour un usage web, il ne reste rien de techniquement défendable au GIF : une vidéo autoplay muted loop fait le même travail bien mieux.