Changer la vitesse d'un GIF

Accélérez ou ralentissez un GIF animé avec un facteur, une durée exacte ou une cadence d'images, sans changer un seul pixel de l'image.

1. 1

   Ajoutez votre GIF

   Faites glisser un GIF animé sur la zone de dépôt, 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

   Choisissez comment l'exprimer

   Par facteur est la réponse habituelle : 2x pour deux fois plus vite, 0,5x pour moitié moins. Choisissez Durée si vous savez combien de secondes la boucle doit remplir, ou Cadence si chaque image doit être montrée aussi longtemps.

3. 3

   Vérifiez la vitesse réellement atteinte

   Le panneau affiche la vitesse demandée à côté de celle atteinte. Elles ne diffèrent que lorsqu'une image demanderait un délai inférieur à 20 millisecondes, qu'aucun lecteur ne respecte — et quand cela arrive, on vous le dit au lieu de vous donner discrètement quelque chose de plus lent.

4. 4

   Téléchargez le GIF recalé

   Appuyez sur Télécharger. Pour un GIF en entrée, seules les marques de temps ont changé : les tables de couleurs, les données d'image compressées et la transparence sont les octets qui sont entrés.

Presque tous les GIF arrivent au mauvais rythme. Un enregistrement d'écran capté à dix images par seconde ressemble à un diaporama là où il fallait de la fluidité. Un clip de réaction découpé dans une vidéo défile si vite que la chute arrive avant que quiconque l'ait lue. Une animation exportée depuis un outil de conception tient chaque image un dixième de seconde parce que c'était la valeur par défaut, pas parce que quelqu'un l'a choisie. La vitesse est la correction la moins chère de toute cette catégorie, car contrairement au recadrage, au redimensionnement ou à la compression, elle ne coûte absolument rien : les images ne changent pas, seul change le moment où chacune apparaît.

Choisissez un facteur, une durée exacte ou une cadence d'images, et vérifiez la vitesse réellement atteinte avant de télécharger.

Lit le GIF, le WebP animé et l'APNG. Un GIF en entrée est recalé en modifiant ses champs de délai, si bien que les tables de couleurs, les données d'image compressées et la transparence ressortent comme les octets qui sont entrés.

Ce que le recalage apporte vraiment

• La lisibilité. Une démonstration que personne ne peut suivre n'est pas une démonstration. Ralentir une capture de moitié fait souvent la différence entre un clip qui explique quelque chose et un clip qui prouve seulement que cela a eu lieu.
• L'attention. Un GIF de réaction est une chute avec un rythme. Deux fois plus vite est la correction standard pour des images découpées dans de la vidéo réelle, presque toujours trop lentes une fois le contexte retiré.
• Un emplacement fixe. Une boucle qui doit tenir sous une diapositive, à côté d'un titre ou dans un montage a une durée à respecter. Le mode Durée la remplit exactement, et non approximativement.
• Aucun coût de qualité. Toutes les autres retouches de cette section échangent quelque chose. Le recalage n'échange rien : l'image qui sort est octet pour octet celle qui est entrée.

Un GIF est un conteneur de blocs préfixés par leur longueur. Chaque image est précédée d'une petite extension de contrôle graphique qui porte son délai sur deux octets, et suivie de l'image compressée elle-même. Changer la vitesse revient à changer ces deux octets par image, et absolument rien d'autre. Ce n'est pas ainsi que fonctionnent les outils de vitesse en ligne : ils décodent l'animation, la quantifient sur une palette neuve, recalculent les différences entre images et écrivent un nouveau fichier, parce que c'est ce qu'une chaîne de traitement d'image générique fait de tout ce qu'on lui confie. Le résultat est une image passée par une seconde étape avec perte pour un changement qui n'avait jamais besoin d'y toucher.

Ce que cet outil fait à la place

• Il lit la structure de blocs. Le fichier est parcouru comme des blocs, sans être décodé. Cela relève où se trouve chaque champ de délai, où se trouve le compteur de boucle, et où commencent et finissent les données compressées de chaque image.
• Il planifie le minutage. Le nouveau délai de chaque image est calculé tant que le facteur demandé est encore connu, arrondi sur la grille de centièmes propre au format, et borné au plancher de 20 ms qu'imposent les lecteurs.
• Il raccorde, il n'écrit pas. La sortie est assemblée à partir de plages copiées de l'original, avec les champs de délai remplacés entre elles. Les données d'image compressées ne sont jamais lues, encore moins réécrites.
• Il le prouve. La plage de données de chaque image de sortie est comparée à celle de l'entrée avant que le fichier ne soit rendu, si bien que « les pixels sont intacts » est une vérification que l'outil effectue et non une affirmation qu'il énonce.

Ce qu'un changeur de vitesse ne doit jamais changer

Deux choses, dont une seule est évidente. Le nombre d'images est la première : un changement de vitesse recale les images existantes et ne doit ni en supprimer ni en dupliquer en silence, car une animation plus courte lue au même rythme paraît identique à une animation plus rapide jusqu'à ce qu'on compte. La seconde est la forme du minutage. Les délais d'un vrai GIF sont couramment irréguliers — une pose tenue, un balayage rapide, une autre pose tenue — et un outil qui les remplace tous par un même nombre produit quelque chose qui dure le bon temps sans être la même animation. Les deux sont vérifiées ici à chaque exécution, image par image et non au total, car un total peut être juste alors que la répartition est fausse.

Un délai de GIF est un nombre entier non signé de centièmes de seconde. Ce seul détail explique presque toutes les plaintes visant les outils de vitesse de GIF. L'ensemble atteignable est grossier — 10, 20, 30 millisecondes et ainsi de suite — donc un facteur demandé tombe rarement sur une valeur représentable, et l'endroit où se produit l'arrondi décide si la demande survit. Pire, le bas de la plage est inutilisable : un délai de 0 ou 1 centième signifie « aussi vite que possible » pour tous les lecteurs jamais écrits, et tous le remplacent par environ 100 millisecondes. Un fichier qui demande 10 millisecondes joue donc dix fois plus lentement qu'il ne l'a demandé, ce qui est l'échec le plus déroutant du format.

Comportement mesuré

• Le vrai plafond 20 ms par image, soit 50 images par seconde. Une source à 100 ms atteint exactement 5x en gardant toutes ses images — une demande de 10x est honnêtement rapportée comme 5x plutôt que livrée en silence.
• Arrondir là où il faut Une image de 51 ms à 2x devient 30 ms si l'écrivain arrondit en dernier, et 30 ms ici aussi — mais le facteur atteint, 1,70x, est affiché au lieu d'être présenté comme 2x.
• Exactitude en mode Durée Une animation de 1 600 ms à qui l'on demande de remplir 3 000 ms sort à 3 000 ms exactement, parce que le reste de l'arrondi est reporté d'une image à la suivante au lieu d'être jeté.
• Coût du chemin sans perte Un GIF de 20 images est recalé en quelques millisecondes et une seule image est décodée, quelle que soit la longueur de l'animation. Reconstruire le même fichier prend des centaines de fois plus de temps et change l'image.

Partez de la cadence propre à la source plutôt que d'un multiplicateur. Une capture qui tient chaque image 100 millisecondes tourne à 10 images par seconde, et 2x la porte à 20 — assez fluide pour la plupart des contenus d'écran. Le même 2x appliqué à un clip déjà à 25 images par seconde en demande 50, qui est le plafond du format, et 3x demande quelque chose qu'aucun lecteur ne respectera. Le panneau affiche le nombre d'images et la durée totale de la source avant que vous ne vous engagiez, et la vitesse réellement atteinte avant que vous ne téléchargiez.

Selon la matière

• Enregistrements d'écran. Généralement captés trop lentement. De 1,5x à 2x est la plage qui rend une démonstration délibérée plutôt que poussive. Au-delà, le mouvement du pointeur devient difficile à suivre.
• Clips de réaction découpés dans une vidéo. Généralement trop lents une fois le contexte disparu. 2x est la correction par défaut ; 3x est courant et il est rare d'avoir besoin de plus.
• Tutoriels et explications. 0,5x, et jugez le résultat plutôt que le nombre. Une étape lisible à vitesse normale ne l'est pas forcément quand chaque image dure deux fois plus longtemps — mais un balayage rapide, si.
• Animations avec des pauses voulues. Restez en mode Facteur ou Durée. Le mode Cadence aplatira les pauses, et les pauses sont généralement l'essentiel.

• Documentation et fichiers README. Un flux de travail enregistré à sa vitesse de capture est presque toujours trop lent pour retenir un lecteur. L'accélérer est la retouche la moins chère disponible et ne coûte aucune qualité.
• Diapositives et montages vidéo. Une boucle qui doit remplir un intervalle connu. Le mode Durée le remplit exactement, seule façon d'éviter un redémarrage visible à mi-parcours.
• GIF de réaction et mèmes. Le minutage est la blague. Un quart de seconde de trop et elle tombe à plat.
• Émojis et autocollants. Les petites animations se lisent dans une petite case, et une boucle rapide se lit comme du mouvement là où une boucle lente se lit comme une image cassée.

Les vitesses à connaître

10 images par seconde correspondent à un délai de 100 ms et sont la valeur par défaut la plus courante des outils de capture. 15 i/s font environ 70 ms et sont le compromis habituel pour du contenu d'écran. 20 i/s font 50 ms et paraissent vraiment fluides. 25 i/s font 40 ms. 50 i/s, un délai de 20 ms, est le plafond du format et le point au-delà duquel aucun lecteur n'ira plus vite. Tout ce que vous avez vu décrit comme un GIF à 60 i/s est un GIF à 50 i/s qui se fait optimiste.

La liste d'entrée est fermée et appliquée au niveau du sélecteur de fichiers plutôt que du moteur, si bien qu'un fichier que cet outil ne peut pas ouvrir est refusé en quelques millisecondes avec un chemin vers l'outil qui le peut — au lieu d'être accepté puis d'échouer plus tard derrière un indicateur d'attente.

• GIF en entrée, GIF en sortie. Le chemin sans perte. Animé ou à une seule image, entrelacé ou non, GIF87a ou GIF89a, avec une palette globale ou une palette locale différente à chaque image : le minutage est modifié et tout le reste est copié.
• WebP animé et APNG en entrée. Les deux sont lus par nos propres démultiplexeurs sur tous les navigateurs, donc images et minutage sont identiques partout. La sortie est un GIF, ce qui fait de ce chemin une conversion et impose de reconstruire l'image.
• Fichiers sans blocs de minutage. Un GIF sans extension de contrôle graphique n'a aucun délai à changer, donc un bloc est inséré et un en-tête GIF87a est porté à 89a — ce qui rend le changement légal et pas seulement présent.
• Tout le reste est refusé avec un chemin. Une vidéo est envoyée vers Vidéo en GIF, une image fixe vers le Créateur de GIF.

Ce que l'outil lit

Pour le chemin sans perte, rien n'est décodé : le fichier est parcouru comme une suite de blocs préfixés par leur longueur, ce qui est une lecture d'en-têtes et non une décompression. Là où une reconstruction est réellement nécessaire — une source WebP ou APNG, ou une demande qui supprime des images — le GIF est décodé nativement là où le navigateur possède un décodeur et par notre propre lecteur partout ailleurs, si bien qu'une animation s'ouvre de la même façon sur tous les moteurs au lieu d'arriver sous la forme de sa première image.

Limites de taille et de lot

• Gratuit. Un fichier jusqu'à 50 Mo, jusqu'à 300 images, jusqu'à 2048 pixels sur le grand côté. Pleine qualité et le même chemin sans perte — l'offre gratuite n'est pas un changement de vitesse dégradé, c'est un changement de vitesse pour un seul fichier.
• Pro. Jusqu'à 20 fichiers à la fois, téléchargés dans une seule archive ZIP, sans plafond imposé d'images ni de dimensions. Le lot est ce que Pro achète ici, parce que recaler un dossier de captures une par une est la vraie corvée.
• La limite commune aux deux offres. Le format lui-même. 20 millisecondes est le délai le plus court que respecte le moindre lecteur, donc aucune offre ne peut faire jouer une animation plus vite que 50 images par seconde sans en montrer moins.

Rien n'est envoyé. Pour un GIF, le fichier est lu une fois, sa structure de blocs est cartographiée, les nouveaux délais sont calculés et la sortie est assemblée à partir de plages copiées de l'original — pas de décodage, pas de palette, pas de compression. Là où une reconstruction est réellement nécessaire, les images sont décodées, une palette est bâtie sur toute l'animation et un GIF89a standard est écrit. Dans les deux cas le travail tourne dans un fil d'arrière-plan pour que la page continue de répondre, et l'étape de mise en correspondance utilise votre matériel graphique là où il est disponible.

Pourquoi le résultat est prévisible

• Une seule règle de minutage, partagée. L'arrondi et le plancher de 20 ms vivent dans une fonction unique qu'utilisent aussi les outils d'inversion et de découpe, de sorte que trois outils ne peuvent pas dériver vers trois idées différentes de ce qu'est un délai.
• Le fichier est relu avant d'être rendu. Le nombre de lectures et les délais par image affichés à l'écran sont lus dans les octets terminés, pas dans la demande — le seul nombre qu'un réglage de boucle peut se tromper est celui qu'il croit avoir écrit.
• Contrôlé face à une autre implémentation. Le minutage de sortie est vérifié avec libvips, une bibliothèque d'images totalement distincte, qui lit la liste des délais par image directement dans les octets produits par cet outil.
• Une reconstruction déterministe. Là où le réencodage est inévitable, il utilise la coupe médiane plutôt que le quantificateur aléatoire employé par la plupart des bibliothèques GIF, si bien que la même entrée avec les mêmes réglages produit toujours la même sortie.

Pour un GIF, tout le changement est une retouche de marques de temps : une image décodée, tous les pixels copiés, et la sortie vérifiée plage par plage face à l'entrée avant d'être rendue. Là où une reconstruction est réellement nécessaire, la mise en correspondance de palette est accélérée par le matériel sur les appareils qui le permettent, et les chemins accéléré et de repli produisent des octets identiques. 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