Changeur de Vitesse de GIF
SEULS LES OCTETS DE DÉLAI CHANGENT, PAS UN PIXEL
Déposez un GIF animé ici
ou cliquez pour le choisir — il est lu dans votre navigateur, jamais envoyé
Chaque image d’un GIF porte son propre délai, stocké dans sa Graphic Control Extension :
0x21 0xF9 0x04 <packed> <delay lo> <delay hi> <transparent> 0x00
Ces deux octets de délai forment un nombre de 16 bits en centièmes de seconde. Un nombre entier. Ce seul détail décide de tout le reste : les seules cadences qu’un GIF peut exprimer sont 100/n.
100, 50, 33,33, 25, 20, 16,67, 14,29, 12,5, 11,11, 10, 9,09, 8,33, 7,69, 7,14, 6,67 … et rien entre les deux. 30 n’est pas dans cette liste. Ni 60, ni 24, ni 15.
Un encodeur à qui l’on demande 30 i/s calcule 100/30 = 3,33 centièmes, ne peut pas le stocker, et arrondit à 3. Votre GIF joue désormais à 33,33 i/s. Voici le tableau complet, et c’est la dernière colonne qui compte :
| Vous demandez | Délai stocké | Il joue en réalité à | Erreur | Dix secondes deviennent |
|---|---|---|---|---|
| 60 i/s | 2 cs | 50,00 i/s | −16,67 % | 12,00 s |
| 50 i/s | 2 cs | 50,00 i/s | exact | 10,00 s |
| 30 i/s | 3 cs | 33,33 i/s | +11,11 % | 9,00 s |
| 25 i/s | 4 cs | 25,00 i/s | exact | 10,00 s |
| 24 i/s | 4 cs | 25,00 i/s | +4,17 % | 9,60 s |
| 20 i/s | 5 cs | 20,00 i/s | exact | 10,00 s |
| 15 i/s | 7 cs | 14,29 i/s | −4,76 % | 10,50 s |
| 12 i/s | 8 cs | 12,50 i/s | +4,17 % | 9,60 s |
| 10 i/s | 10 cs | 10,00 i/s | exact | 10,00 s |
Dix secondes de vidéo capturées à 30 i/s font 300 images. Trois centièmes chacune font 900 centièmes — neuf secondes. Le GIF se termine une seconde entière avant le plan dont il vient, et si vous le calez sur de la musique ou le montez contre une vidéo, c’est de là que vient le décalage. Seules 50, 25, 20, 10 et 5 reviennent exactes.
Ils n’arrondissent pas toutes les images de la même façon. Nous avons pris un GIF produit par ffmpeg nominalement à 12 i/s et lu ses délais directement dans les octets :
8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8
Vingt-quatre images, 200 centièmes, exactement 2,00 secondes — soit exactement 12,0000 i/s en moyenne. La moyenne est parfaite. Mais les images consécutives sont espacées de 80 ms puis 90 ms, une variation de 12,5 % entre voisines qui ne disparaît jamais, parce que l’encodeur paie une cadence impossible en alternant deux cadences possibles.
La conséquence mérite d’être dite franchement : « la cadence d’un GIF » est le plus souvent une moyenne qu’aucune image n’a réellement. Un outil qui vous montre un seul chiffre vous montre quelque chose qui n’est pas dans le fichier. Cette page affiche tous les délais, une barre par image, pour que vous voyiez si le vôtre est uniforme ou alterné.
Voici ce qui distingue cet outil de tous les autres changeurs de vitesse de GIF. Changer la vitesse d’un GIF, c’est écrire ces deux octets de délai par image. Rien d’autre. La palette, les données de pixels compressées en LZW, la position des images, la transparence — rien de tout cela n’intervient.
La plupart des outils décodent le GIF en images et le ré-encodent, ce qui requantifie la palette et coûte une génération visible de couleur à chaque passage. Celui-ci n’écrit que les deux octets de délai de chaque image et rend le reste intact.
Le nombre d’octets qui diffèrent réellement est plus petit encore, et la page les compte pour vous au lieu de le promettre. Nous avons retemporisé un GIF de 24 images pesant 54 596 octets et 24 octets ont changé — un par image, 0,044 % du fichier. Un et non deux, parce que l’octet de poids fort du délai vaut zéro tant que le délai est inférieur à 256 centièmes de seconde : passer de 8 à 20 ne déplace qu’un seul octet. Demandez un délai de 3,00 secondes et le second octet bouge aussi, et le compte passe à 48. Le chiffre de votre fichier est sur la page, à côté de sa taille totale.
On pourrait croire qu’il suffit de charger un GIF et de le regarder pour lire sa temporisation. C’est impossible. Dessiner un GIF animé sur un canvas renvoie une image fixe — nous avons testé six fichiers avec des délais de 1 à 10 centièmes, en échantillonnant toutes les 4 ms pendant quatre secondes chacun, et obtenu zéro avancement d’image sur les six. Le décodeur d’images du navigateur anime le GIF à l’écran mais ne transmet pas l’image courante à votre code.
Un outil qui veut vous dire la vérité sur un GIF doit donc lire le fichier lui-même, ce que fait celui-ci, dans votre navigateur, sans rien envoyer.
Il y a une chose que nous nous gardons délibérément d’affirmer. Les navigateurs imposent aussi leur propre délai minimum, et les très petites valeurs sont traitées comme quelque chose de plus grand — mais nous n’avons pas pu le mesurer ici, pour la raison ci-dessus, donc aucun chiffre à ce sujet ne figure sur cette page. S’il vous faut une temporisation exacte, la réponse n’est pas un GIF : convertissez-le en MP4, où la base de temps est celle que vous voulez.
Non. Le fichier est lu par votre navigateur, analysé dans la page, et la copie retemporisée est construite en mémoire puis rendue en téléchargement. Il n’atteint jamais de serveur, et c’est aussi pourquoi l’outil continue de fonctionner avec l’onglet hors ligne une fois la page chargée.
C’est impossible. Seuls les deux octets de délai de chaque image sont écrits ; la palette et les données de pixels compressées sont recopiées telles quelles. La page indique combien d’octets diffèrent entre le fichier que vous avez donné et celui qu’elle rend — pour notre GIF de test de 24 images il était de 24 sur 54 596, alors qu’un ré-encodage en changerait presque tout.
Parce que le format stocke le délai en nombre entier de centièmes de seconde, et que 100/30 vaut 3,33. Ce délai n’existe pas. Trois centièmes donnent 33,33 i/s et quatre en donnent 25. S’il vous faut 30, il vous faut un format à base de temps plus fine — MP4 ou WebM.
Presque certainement pas. Les encodeurs alternent deux délais pour qu’une moyenne impossible tombe juste — 8, 9, 8, 8, 9 donne exactement 12 i/s de moyenne. Il est aussi normal qu’un GIF fait à la main tienne une image exprès. La bande de barres de cette page montre tous les délais pour que vous sachiez dans quel cas vous êtes.
Que le fichier n’en précise aucun, et que chaque visionneuse décide seule. C’est le seul cas où la lecture est réellement imprévisible, et il vaut mieux fixer une vraie valeur que de laisser ainsi. Choisissez « délai exact par image » et donnez-lui-en une.
Oui — le multiplicateur de vitesse va de 0,25× à 4×, et il divise le délai existant de chaque image au lieu de le remplacer, si bien qu’un GIF volontairement alterné garde son rythme relatif. Fixer une cadence cible, en revanche, rend toutes les images uniformes.
Non. Le fichier retemporisé fait exactement la même taille que l’original, octet pour octet, parce que deux octets sont écrasés et non insérés. S’il vous faut un GIF plus petit, le levier est le nombre d’images ou la palette, pas la temporisation.
Oui. Le travail est proportionnel au nombre d’images, pas au nombre de pixels, puisque les données de pixels ne sont jamais décodées. Un GIF de plusieurs centaines d’images se retemporise aussi vite qu’un GIF de dix.