Optimiser un GIF

Supprimez la redondance entre les images d'un GIF animé sans changer sa taille, sa vitesse ni ses couleurs.

1. 1

   Ajoutez votre GIF

   Déposez un GIF animé sur la zone prévue, ou cliquez pour parcourir. Le WebP animé et l'APNG fonctionnent aussi. Le fichier est lu sur votre appareil et n'est jamais envoyé.

2. 2

   Gardez les réglages par défaut pour une passe sans perte

   La différence entre images est active et seuls les doublons identiques octet par octet sont supprimés. Avec ces réglages l'image ne change pas : le fichier cesse simplement de stocker ce qu'il stockait déjà.

3. 3

   Ne touchez un curseur que s'il vous en faut plus

   La tolérance de différence pardonne les pixels presque identiques d'une image à l'autre. Les plages avec perte réunissent les pixels presque identiques à l'intérieur d'une image. Les deux échangent un peu de précision contre du poids, et affichent exactement ce que cela coûte.

4. 4

   Lisez le rapport, puis téléchargez

   Le panneau de résultat indique les images conservées, la part du canevas couverte par chaque image stockée et la durée en entrée et en sortie. Appuyez sur Télécharger quand les chiffres disent ce que vous vouliez.

Presque tous les GIF en circulation sont plus lourds que nécessaire pour une raison qui n'a rien à voir avec la qualité. Le format autorise depuis 1989 une image à ne couvrir que le rectangle qui a changé et à marquer le reste de ses pixels comme « ce qui est déjà à l'écran ici est encore correct », et la plupart des encodeurs n'utilisent ni l'un ni l'autre. Ainsi une capture de vingt images d'une page statique avec un curseur qui bouge stocke cette page statique vingt fois. Optimiser supprime la répétition et ne touche à rien d'autre.

Ne stockez que les pixels qui changent d'une image à l'autre, supprimez les images qui se répètent en ajoutant leur temps à celle qui reste, et partagez une table de couleurs sur toute l'animation.

Lit le GIF, le WebP animé et l'APNG. Écrit un GIF89a standard aux mêmes dimensions, de même durée et — quand la palette le permet — aux mêmes couleurs.

Ce que cela vaut, mesuré

• Différence entre images. Sur notre animation de référence, 196 091 octets stockés en entier deviennent 48 131 stockés en différences. Sur la version à cent images, 4 776 638 deviennent 1 172 755. Les deux font 4,07x et les deux sont exacts en couleur.
• Images en double. Une animation de douze images faites de quatre dessins distincts ressort à quatre images portant le temps des douze. Une animation de six images d'un seul dessin ressort à une image portant les 600 ms.
• Rognage d'une image transparente. Un autocollant dont le contenu opaque occupe un cinquième du canevas est stocké comme un cinquième du canevas : 191 octets à partir de 19 473, transparence intacte.
• Rien que vous n'ayez demandé. Pas de redimensionnement, pas de baisse de cadence, pas de réduction de palette sauf si vous bougez un curseur. Si le ré-encodage ne bat pas votre fichier, vous récupérez le vôtre et on vous le dit.

Un GIF n'est pas une pile d'images. C'est un canevas plus une liste d'instructions, et chaque instruction peut peindre un rectangle n'importe où sur ce canevas, à n'importe quelle taille, avec n'importe lequel de ses pixels marqué transparent pour laisser voir ce qui est dessous. Une image qui change une zone de 30 pixels peut être stockée comme une zone de 30 pixels. Si si peu de fichiers le font, c'est que l'écrire est bien plus difficile : l'encodeur doit tenir un modèle de ce qu'un décodeur afficherait et comparer avec cela plutôt qu'avec l'image source précédente.

Ce qui arrive à chaque image

• Composer. Chaque image est dessinée sur un canevas de la taille logique de l'animation, en respectant son décalage, sa méthode d'élimination et sa transparence, pour que ce qui est comparé soit l'image qu'un spectateur verrait.
• Analyser une seule fois. Une passe unique répond à tout ce dont l'encodage a besoin : quelles images se répètent, s'il y a de la transparence, combien de couleurs distinctes, et l'échantillon qui sert à bâtir la palette.
• Mapper vers une table partagée. Si les couleurs de la source tiennent dans une table, cette liste exacte devient la palette. Sinon une palette est dérivée sur toute l'animation et non depuis la première image, pour que les couleurs ne bougent pas pendant la lecture.
• Différencier, puis compresser les plages. Chaque image est comparée à un modèle du canevas décodé, réduite au rectangle qui a changé, et les pixels inchangés y sont marqués transparents. La passe avec perte ne s'exécute qu'ensuite, pour ne jamais abîmer la différence.

L'invariant que presque toutes les implémentations ratent

Quand une image en double est supprimée, son temps doit aller quelque part. Supprimez dix images d'une animation de vingt à 100 ms sans fusionner les délais et il vous reste dix images de 100 ms : une animation de deux secondes qui se joue en une, à double vitesse. La sortie est un GIF valide. Rien n'échoue. Ce n'est simplement plus l'animation d'entrée. Ici la durée d'entrée et celle de sortie sont comparées à chaque exécution et un écart est levé comme erreur, pas rendu comme fichier plus léger.

Supprimer des images selon leur contenu n'a rien à voir avec en jeter une sur deux, et cette différence est tout l'enjeu. Jeter une image sur N est aveugle : cela retire des images qui montraient du nouveau en même temps que celles qui n'en montraient pas, et le résultat saccade aussitôt. Supprimer les doublons n'efface que des images qu'un spectateur n'aurait pas distinguées de la précédente et fusionne leur temps. Si ce que vous voulez est une cadence plus basse, ce levier est sur le compresseur.

Deux modes et le seuil qui les sépare

• Identiques seulement. Des répétitions octet par octet et rien d'autre. C'est le mode par défaut car il ne peut rien changer à ce que l'on voit : les images retirées étaient déjà à l'écran, pixel pour pixel.
• Presque identiques. Un seuil de similarité de 80 % à 100 %. À 98 %, une image correspondant à au moins 98 % de la dernière conservée est traitée comme une répétition. Utile sur du matériel légèrement bruité.
• Désactivé. Toutes les images sont gardées. À choisir quand le nombre d'images compte : certains éditeurs et certaines chaînes de sprites les indexent par numéro.

Pourquoi la comparaison se fait avec la dernière image conservée

Comparez chaque image à celle qui la précède immédiatement et un fondu lent franchit le seuil à chaque pas, si bien que toute l'animation se réduit à sa première image alors que chaque comparaison prise seule semblait raisonnable. Comparer avec la dernière image CONSERVÉE borne l'erreur : quel que soit le seuil, c'est le maximum de ce qu'un spectateur peut voir et que l'enregistrement ne contenait pas, et cela ne s'accumule pas. Moins d'images sont retirées sur du matériel qui dérive, et c'est le bon compromis, car le défaut évité est silencieux.

Tous les chiffres ci-dessous viennent du jeu de tests de cet outil, sur des fichiers régénérés par un script plutôt que déposés comme des binaires mystérieux. Chaque sortie est relue par trois implémentations indépendantes : libvips pour l'animation rendue, gifsicle pour la structure des images, et un lecteur structurel écrit pour les tests qui parcourt les blocs du fichier sans jamais lancer la décompression.

Les leviers, par ce qu'ils valent

• Différence entre images 4,07x sur l'animation de référence à 20 comme à 100 images, avec une erreur moyenne de couleur mesurée de 0,000 sur 255.
• Suppression des doublons De 12 images à 4, et de 6 à 1, sur les deux fichiers dédiés — avec 1 200 ms en entrée et 1 200 en sortie, et 600 ms en entrée et 600 en sortie.
• Tolérance de différence à 40 De 1 172 755 octets à 487 196 sur la référence de cent images. Un 2,41x supplémentaire par-dessus la passe sans perte.
• Plages avec perte à 60 De 1 172 755 octets à 478 644 sur le même fichier. Comparable à l'autre curseur et visible autrement : à l'intérieur d'une image plutôt qu'entre images.
• Vitesse Cent images en 480x270, décodées, analysées, différenciées et écrites, en 252 à 380 ms sur l'appareil de référence.

Face à gifsicle, le moteur de la plupart des optimiseurs en ligne

Les rectangles d'image produits par cet outil sont identiques à ceux de gifsicle -O3 sur tous les fichiers mesurés — mêmes décalages, mêmes tailles, mêmes tables de couleurs — ce qui dit que les décisions structurelles concordent. Sur le poids total nous égalons ou dépassons gifsicle -O3 sur huit cas sur dix et perdons sur deux, de 0,03 % et 3,1 %, entièrement dans la charge compressée et non dans la structure. Deux choses que nous faisons et pas lui : supprimer les images presque identiques, et signaler quand le ré-encodage a alourdi le fichier.

Ce sont deux travaux différents et choisir le mauvais dépense de la qualité qu'il n'était pas nécessaire de dépenser. Optimiser supprime la redondance : le fichier s'allège et l'animation ne change pas, il n'y a donc aucune raison de s'en priver. Compresser supprime de l'information : moins de pixels, moins de couleurs, moins d'images par seconde, jusqu'à atteindre un poids que vous nommez. Commencez ici. Si le résultat est encore trop lourd, le compresseur prend le relais.

Une courte liste de décisions

• Commencez toujours par l'optimiseur. Cela ne coûte rien visuellement et suffit souvent. Aucun intérêt à jeter des couleurs avant d'arrêter de stocker deux fois les mêmes pixels.
• Utilisez le compresseur quand l'exigence est un chiffre. « Moins de 8 Mo pour Discord », « moins de 256 Ko pour un émoji ». Il cherche dans la résolution, la palette et la cadence jusqu'à l'atteindre.
• Utilisez le redimensionneur quand les dimensions sont fausses. Cet outil ne les change jamais. Si l'animation fait 1920 de large et la colonne 700, c'est un redimensionnement, et le faire d'abord rend tout le reste moins cher.
• Revenez ici ensuite. Optimiser la sortie d'un redimensionnement ou d'une compression trouve souvent davantage, car ces outils reconstruisent les images et celui-ci est celui qui en retire la répétition.

Compresseur de GIF · Redimensionner un GIF

Les réglages par défaut sont choisis pour que personne n'ait à y penser : différence entre images active, doublons retirés seulement s'ils sont identiques octet par octet, les deux curseurs avec perte à zéro, pas de tramage. Cette combinaison ne peut rien changer à ce que l'on voit, et c'est pour cela qu'elle est par défaut : un optimiseur qui modifierait discrètement l'image serait un compresseur au nom trompeur.

Selon le matériel

• Captures d'écran et démonstrations d'interface. Le meilleur cas possible. Le fond est statique, les différences sont minuscules, et les pauses produisent des images identiques qui ne coûtent rien à retirer. Gardez les réglages par défaut.
• Matériel issu de la vidéo. Rien n'est jamais identique octet par octet à cause du bruit de compression, donc passez la suppression des doublons en presque identiques à 98 % et montez la tolérance de différence.
• Autocollants et logos sur fond transparent. La différence entre images n'est pas disponible, mais les images sont tout de même rognées à leur contenu opaque, ce qui vaut souvent davantage ici.
• GIF photographiques ou très tramés. Il n'y a peut-être rien à retirer, et l'outil le dira au lieu de vous rendre un fichier plus lourd. Réduisez le nombre de couleurs, ou passez au compresseur.

La liste d'entrée est fermée et appliquée dans la boîte de dialogue de fichiers plutôt que dans le moteur, si bien qu'un fichier que cet outil ne peut pas ouvrir est refusé en quelques millisecondes avec un lien vers l'outil qui le peut — plutôt qu'accepté puis mis en échec derrière un indicateur de chargement.

• GIF en entrée. Animé ou à une seule image, entrelacé ou non, avec une palette globale ou une palette locale différente sur chaque image. Les images partielles sont composées sur le canevas complet avant toute comparaison.
• WebP animé et APNG en entrée. Les deux sont lus par nos propres démultiplexeurs dans tous les navigateurs, donc le nombre d'images et le rythme sont identiques partout. Les deux portent bien plus de 256 couleurs.
• GIF en sortie, toujours. Un GIF89a standard avec une table de couleurs globale, des délais par image, des images partielles, des méthodes d'élimination et l'extension de bouclage Netscape.
• Tout le reste est refusé avec un itinéraire. Une vidéo part vers Vidéo en GIF, une image fixe vers le Créateur de GIF.

Ce que l'outil lit

Le GIF est décodé nativement là où le navigateur dispose d'un décodeur et par notre propre lecteur partout ailleurs, si bien qu'une animation s'ouvre de la même façon partout au lieu d'arriver comme sa première image sans le moindre avertissement. Le WebP animé et l'APNG passent toujours par notre lecteur, ce qui garde le nombre d'images et le rythme identiques d'un moteur à l'autre. Ce qu'un fichier prétend être par son nom est ignoré : ce sont les seize premiers octets qui décident.

Limites de taille et de lot

• Gratuit. Un fichier jusqu'à 50 Mo et jusqu'à 300 images. Tous les leviers structurels sont inclus, car ils sont ce qu'est l'outil. La table de couleurs est plafonnée à 128 entrées.
• Pro. Jusqu'à 50 fichiers d'un coup, téléchargés en une seule archive ZIP, sans limite de taille ni d'images au-delà de ce que votre appareil peut tenir, et la table complète de 256 couleurs.
• Aucun plafond de dimensions, quelle que soit la formule. L'optimiseur ne change jamais les dimensions, donc un plafond dessus limiterait quelque chose qui n'arrive pas. Les deux formules rendent l'animation exactement à la taille reçue.
• La limite commune aux deux formules. Chaque image est étendue en couleurs complètes pendant le traitement, donc un budget mémoire borne le travail avant qu'il ne commence au lieu de laisser l'onglet cesser de répondre.

Rien n'est envoyé. Le fichier est décodé image par image sur votre machine, analysé une fois pour les répétitions, la transparence et le nombre de couleurs, mappé vers une palette partagée unique, différencié contre un modèle de ce qu'un décodeur afficherait, et écrit comme GIF89a standard. Tout se déroule dans un fil d'arrière-plan pour que la page continue de s'afficher, et le mappage de palette — la partie par pixel, la coûteuse — s'exécute sur votre matériel graphique quand il est disponible.

Pourquoi le même fichier s'optimise toujours pareil

• Un quantificateur déterministe. Coupe médiane, pas le quantificateur neuronal aléatoire qu'utilisent la plupart des bibliothèques — et, quand les couleurs de la source tiennent, aucun quantificateur du tout. La même entrée avec les mêmes réglages produit toujours les mêmes octets.
• Résultats identiques sur tous les chemins. Les chemins accélérés par le matériel et par le processeur doivent produire les mêmes octets, pas seulement des octets semblables. Un chemin qui choisirait une autre entrée de palette se verrait comme un scintillement de couleur entre les images.
• Vérifié par des implémentations sans code commun. L'animation rendue est relue par libvips, la structure des images par gifsicle et les blocs du fichier par un lecteur écrit pour les tests. Un fichier que notre propre code écrit et relit ne prouve rien.
• Optimiser deux fois ne change rien. Passer l'outil sur sa propre sortie rend le même fichier et le déclare déjà optimisé, ce qui est la propriété qui dit que la première passe a fini le travail.

Le mappage de palette est accéléré par le matériel quand votre appareil le permet, et les chemins accéléré et de repli sont vérifiés comme produisant des octets identiques. La structure des images est contrôlée avec gifsicle et l'animation rendue avec libvips, dont aucun ne partage de code avec cet outil. Mesuré sur l'appareil de référence : 100 images en 480x270 optimisées en 252 ms, 4,07x plus légères, avec une erreur moyenne de couleur de 0,000 sur 255. Tout se fait sur votre appareil, pas sur nos serveurs.

• Compresseur de GIF
• Redimensionner un GIF
• Créateur de GIF
• Vidéo en GIF
• GIF en MP4
• Éditeur de GIF