Redimensionner un GIF

Changez les dimensions d'un GIF animé en tapant des pixels exacts ou un pourcentage, sans perdre l'animation.

1. 1

   Ajoutez votre GIF

   Glissez 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

   Réglez la taille

   Tapez une largeur, une hauteur, ou les deux — avec le verrou de rapport, remplir l'une remplit l'autre. Un pourcentage marche aussi, et dépasser 100 % agrandit au lieu d'être ignoré.

3. 3

   Choisissez la gestion d'une forme différente

   Si votre cadre cible a d'autres proportions, choisissez ajuster, étirer, rogner ou remplir. Ajuster est le choix sûr : rien n'est déformé ni coupé.

4. 4

   Téléchargez le GIF redimensionné

   Appuyez sur Télécharger. Le délai de chaque image, le nombre de boucles et la transparence ressortent inchangés : l'animation se lit exactement comme avant.

Un GIF arrive à la taille à laquelle il a été fait, et cette taille est rarement celle dont vous avez besoin. Une capture d'écran enregistrée à 1920 pixels de large est inutilisable en pièce jointe et illisible en emoji de 128 pixels. Un GIF de réaction récupéré sur un téléphone fait 480 de large quand la colonne de documentation en fait 700. Et contrairement à une photographie, on ne peut pas simplement laisser le navigateur le mettre à l'échelle : un GIF affiché plus petit que sa taille naturelle télécharge quand même tous ses pixels en pleine taille, si bien que le lecteur paie pour une résolution qu'il ne voit jamais.

Tapez des dimensions exactes ou un pourcentage, agrandissez autant que vous réduisez, et passez en mode Pixel pour garder les bords d'un sprite nets.

Lit le GIF, le WebP animé et l'APNG. Écrit un GIF89a standard en conservant les délais par image, le nombre de boucles et la transparence.

Ce que changer les dimensions apporte

• Des octets, en quantité. Diviser par deux la largeur et la hauteur retire environ trois quarts des données de pixels. C'est la réduction de poids la moins chère qui existe, car elle ne coûte rien au mouvement.
• Un emplacement qui va. Les cases d'emoji, les cadres d'avatar et les colonnes de documentation ont des largeurs fixes. Ce qui ne rentre pas est rogné ou mis à l'échelle par l'algorithme de quelqu'un d'autre.
• La lisibilité. Le texte dans une capture d'écran est soit lisible à la taille d'affichage, soit décoratif. Redimensionner délibérément, c'est le découvrir avant de publier.
• Des sprites qui restent nets. Le pixel art agrandi avec lissage est ruiné et irrécupérable. Agrandi au plus proche voisin, il est parfait à tout multiple entier.

Une image fixe a un seul raster. Un GIF animé en a une pile, chacun pouvant ne couvrir qu'une partie du canevas, chacun avec son délai, sa palette et son masque de transparence. Le redimensionner correctement suppose de composer d'abord chaque image sur le canevas complet, de mettre cela à l'échelle, puis de reconstruire une palette pour toute l'animation plutôt qu'une par image. Les outils qui sautent la composition produisent un résultat qui saute, parce qu'une image qui était légalement un carré de 30 pixels décalé se retrouve mise à l'échelle comme si c'était toute la photo.

Ce qui arrive à chaque image

• Composer. Chaque image est dessinée sur un canevas à la taille logique de l'animation, en honorant son décalage, sa méthode d'élimination et sa transparence, de sorte que ce qui est mis à l'échelle est l'image qu'un spectateur verrait vraiment.
• Mettre à l'échelle. Un dessin par image à la taille cible, sur votre matériel graphique lorsqu'il est disponible. Lissage activé pour le matériel photographique, désactivé pour le pixel art.
• Requantifier. Une palette est construite à partir d'un échantillon réparti sur toute l'animation, pas à partir de la première image, puis chaque pixel y est associé.
• Réoptimiser. Les zones inchangées entre images sont de nouveau marquées transparentes à la nouvelle taille, et c'est là que part l'essentiel du poids.

Ce qu'un redimensionneur ne doit pas changer

Trois choses doivent ressortir exactement comme elles sont entrées : le délai propre de chaque image, le nombre de boucles, et quels pixels sont transparents. Un outil qui retemporise en redimensionnant produit un GIF parfaitement valide qui se lit simplement à la mauvaise vitesse, et un outil qui aplatit la transparence rend une image entourée d'un cadre blanc. Les deux sont vérifiées ici à chaque exécution plutôt que supposées.

Tout redimensionneur lisse par défaut, et pour des photographies c'est juste : interpoler entre pixels voisins est ce qui évite qu'une photo mise à l'échelle ressemble à une mosaïque. Pour le pixel art, c'est destructeur d'une façon que rien n'inverse. Un contour noir d'un pixel sur un sprite, agrandi quatre fois avec lissage, devient un dégradé gris de quatre pixels ; le bord net a disparu et aucune accentuation ne le ramène. Le plus proche voisin répète simplement chaque pixel source, donc un agrandissement 4× transforme chaque pixel en un bloc net de 4×4. Mesuré sur le sprite de test de cet outil passé de 64 à 256 : le lissage a produit 94 couleurs distinctes sur la ligne du milieu, le plus proche voisin exactement 8 — le nombre que la source contient réellement.

Résultats mesurés

• Plus proche voisin contre lissage 8 couleurs distinctes sur une ligne contre 94, sur une source qui en contient 8. Le mode fait la différence entre préserver le dessin et en faire la moyenne.
• Précision du rééchantillonnage Le mode lisse s'écarte du lanczos3 de libvips de 3,31/255 en moyenne — deux implémentations indépendantes qui concordent.
• Remplissage transparent contre uni 49 167 o contre 13 961 o pour la même image. Le remplissage transparent coûte l'optimisation entre images, qui vaut 3,5× ici.
• Vitesse 100 images de 480×270 vers 960×540 en 1 149 ms ; le même clip vers 240×135 en 112 ms.

L'erreur la plus courante est de redimensionner vers un chiffre qui sonne bien plutôt que vers celui que la destination utilise. Avant de taper quoi que ce soit, découvrez à quelle taille la cible rend réellement — une colonne de documentation, une case d'emoji, la largeur en ligne d'une messagerie — et alignez-vous exactement. Redimensionner à 500 quand la colonne fait 700 fait remettre à l'échelle par le navigateur et annule le travail ; redimensionner à 1400 pour une colonne de 700 double le téléchargement pour une différence que seul un écran haute densité peut montrer, et encore, seulement si la source avait le détail.

Par matériau

• Captures d'écran avec du texte. Ne descendez pas sous la taille à laquelle le texte se lit : regardez l'aperçu, pas le nombre. Ici le lissage est juste ; le texte est déjà anticrénelé.
• Pixel art et sprites. Passez sur Pixel et utilisez des multiples entiers : 2×, 3×, 4×. Une échelle non entière de pixel art produit des blocs inégaux même au plus proche voisin, car certains pixels source tombent sur deux pixels de sortie et d'autres sur trois.
• Matériel issu de vidéo. Lissage, et réduire plutôt qu'agrandir. Agrandir des images issues de vidéo fait ressortir les artefacts de compression invisibles à la taille d'origine.
• Tout ce qui va dans un carré fixe. Rogner, pas Remplir. Un carré rempli a des bandes vides visibles ; un carré rogné remplit la case comme toutes les autres images.

• Emoji personnalisés. Discord et Slack acceptent 128×128 et refusent presque tout au-delà de 256 ko, si bien que cet outil et le compresseur s'utilisent généralement ensemble.
• Documentation et fichiers README. Alignez-vous sur la largeur rendue de la colonne pour que le navigateur ne fasse aucune mise à l'échelle de son côté.
• Signatures d'e-mail. De petites dimensions sont le seul moyen fiable de faire passer une animation sous ce qu'acceptent la plupart des serveurs.
• Avatars et photos de profil. Carrés, rognés, et assez petits pour charger avant que la page finisse de s'afficher.

Des tailles à retenir

Les emoji personnalisés de Discord et Slack font 128×128. X affiche les images en ligne jusqu'à 506 pixels de large. La colonne d'un README GitHub fait 768 en pleine largeur et environ 700 en pratique. La plupart des thèmes de documentation se situent entre 680 et 760. Tout ce qui dépasse la colonne d'accueil, ce sont des octets que le lecteur télécharge et ne voit jamais.

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

• GIF en entrée. Animé ou à image unique, entrelacé ou non, avec palette globale ou une palette locale différente à chaque image. Les images qui ne sont qu'un sous-rectangle décalé sont composées sur le canevas complet avant toute mise à l'échelle.
• 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.
• GIF en sortie, toujours. Un GIF89a standard avec table de couleurs globale, délais par image, méthodes d'élimination et extension de boucle Netscape.
• Tout le reste est refusé avec un itinéraire. Une vidéo est renvoyée vers Vidéo vers 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 a un décodeur, et par notre propre lecteur partout ailleurs, si bien qu'une animation s'ouvre de la même façon dans tous les navigateurs au lieu d'arriver sous forme de première image. Le WebP animé et l'APNG passent toujours par notre lecteur, ce qui garde le nombre d'images et le minutage identiques d'un moteur à l'autre.

Limites de taille et de lot

• Gratuit. Un fichier jusqu'à 50 Mo et jusqu'à 300 images, sortie jusqu'à 2048 pixels sur le grand côté. En pleine qualité : l'offre gratuite n'est pas un redimensionnement dégradé, c'en est un à un seul fichier.
• Pro. Jusqu'à 20 fichiers d'un coup, téléchargés en une seule archive ZIP, sans plafond de dimensions imposé. Le lot est ce que Pro achète ici, car redimensionner un jeu d'emoji ou un dossier de clips un par un est la vraie corvée.
• La limite commune aux deux offres. Chaque image est décompressée en couleurs complètes pendant son traitement, donc un budget mémoire borne le travail avant qu'il ne démarre, au lieu de laisser l'onglet cesser de répondre pendant que l'indicateur tourne encore.

Rien n'est envoyé. Le fichier est décodé image par image sur votre machine, chaque image est composée et mise à l'échelle, une palette est construite pour toute l'animation, les zones inchangées sont de nouveau marquées transparentes, et le résultat est écrit en GIF89a standard. Tout cela tourne dans un fil d'arrière-plan pour que la page reste réactive, et la mise à l'échelle elle-même tourne sur votre matériel graphique lorsqu'il est disponible.

Pourquoi le même fichier se redimensionne identiquement à chaque fois

• Un quantificateur déterministe. La coupe médiane, pas le quantificateur neuronal aléatoire qu'utilisent la plupart des bibliothèques GIF, donc la même entrée avec les mêmes réglages donne toujours une sortie identique octet pour octet.
• Des résultats identiques sur tous les chemins. Les chemins accéléré graphiquement et processeur doivent produire les mêmes octets, pas seulement des octets voisins — un chemin choisissant une autre entrée de palette se verrait comme un scintillement de couleur entre images.
• Une géométrie vérifiée par une autre implémentation. Le rééchantillonnage lisse est vérifié contre libvips, une bibliothèque d'image totalement distincte, et non contre notre propre sortie précédente.

La mise à l'échelle est accélérée matériellement lorsque votre appareil le permet, et les chemins accéléré et de repli sont vérifiés comme produisant des octets identiques. Le rééchantillonnage lisse est confronté à une bibliothèque d'image indépendante. Mesuré sur la machine de référence : 100 images de 480×270 vers 960×540 en 1 149 ms. Tout se fait sur votre appareil, pas sur nos serveurs.

• Compresseur GIF
• Créateur de GIF
• Vidéo vers GIF
• GIF vers MP4
• Éditeur de GIF
• Tous les outils GIF