Convertir WebP en SVG

SVG est un format de dessin : des formes géométriques décrites en XML, indéfiniment redimensionnables, modifiables avec un éditeur de formes. WebP est un format de pixels : une grille de points de couleur, figée à la taille où elle a été encodée. La conversion de l’un à l’autre est une reconstruction, pas une transformation : un programme regarde les pixels et essaie d’en extraire des formes qui se ressemblent.

C’est une opération qui a un domaine de réussite étroit. Un logo avec quelques aplats de couleur nets sort en SVG propre, à peine plus gros que la source. Une photographie sort en SVG quatre fois plus gros que le WebP et qui ressemble à une version dégradée par bandes. Un texte capturé sort en SVG qui a l’à-peu-près des lettres mais pas la précision. La conversion n’est utile que pour des contenus qui se prêtent à la vectorisation, et c’est explicite dans le code source que la qualité est très variable.

Le module utilise imagetracerjs, une bibliothèque JavaScript sous licence Unlicense, choisie parce que potrace et autotrace sont GPL et que VTracer n’a pas de licence de distribution claire. imagetracerjs regarde l’image par bandes, identifie les contours entre régions de couleur similaire, et trace des chemins Bézier qui approchent ces contours.

Le résultat est une approximation. Un cercle parfait devient un polygone à seize sommets. Une courbe douce devient une suite de petits segments. Les dégradés sont divisés en bandes de couleur, et la vectorisation les transforme en escalier. C’est l’essence de l’opération : remplacer un raster par un assemblage de formes plates, et accepter que la sortie est une approximation de l’entrée.

Un logo d’entreprise est typiquement composé de quelques aplats de couleur, éventuellement avec un dégradé simple, et c’est exactement ce qu’imagetracerjs sait faire. Un fichier PNG de 6 Ko qui représente un logo sur fond transparent devient un SVG de 16 Ko qui représente les mêmes formes en chemins vectoriels, et le résultat est net à n’importe quelle taille.

C’est le cas où cette conversion sert. Pour un asset UI, une icône d’application, un pictogramme à embarquer dans un design responsive, le SVG est strictement meilleur que le WebP parce qu’il se redimensionne sans perte. La qualité visuelle est identique à la source si la source se prêtait à la vectorisation, et la taille du fichier est compétitive.

Une photographie a des millions de variations de couleur, des transitions douces, du grain, du bruit, et c’est exactement le contraire de ce qu’imagetracerjs sait traiter. Le résultat est un SVG qui contient des centaines de chemins minuscules pour approcher les variations, et le fichier est quatre fois plus gros que le WebP pour une qualité visible dégradée par bandes de couleur.

Pour une photographie, ne faites pas cette conversion. Gardez le WebP, ou convertissez en JPG pour un cas de partage. Le SVG est le mauvais format pour ce type de contenu, et c’est explicite dans le code source que la conversion mesure la sortie contre la source et signale quand la vectorisation a dégradé l’image — c’est le repère honnête pour décider si la conversion a du sens ou non.

Une capture d’interface a des zones de texte, des icônes, des aplats de couleur, et c’est un mélange. La vectorisation fait du bon travail sur les aplats, du travail acceptable sur les icônes, et du mauvais travail sur le texte — les lettres sont approximées en formes qui ont la bonne silhouette mais pas la précision d’une fonte.

Pour un schéma simple — un diagramme, un organigramme, un croquis, une affiche avec peu de texte — la conversion sort un SVG qui a l’à-peu-près de la source et qui se redimensionne proprement. Pour une capture d’écran avec du texte, c’est un cas où il faut ouvrir le SVG produit dans un éditeur de vecteurs et retoucher le texte à la main, parce que les chemins ne sont pas du texte et ne sont pas modifiables comme du texte.

Le sélecteur propose un nombre de couleurs entre 2 et 64, et c’est le paramètre qui détermine la qualité visible du résultat. Moins de couleurs donne des bandes plus visibles, mais un fichier plus petit et des formes plus simples. Plus de couleurs se rapproche de la source, mais le fichier grossit et les chemins se complexifient.

Pour un logo à deux couleurs, 4 est presque toujours suffisant. Pour une illustration avec des dégradés, 16 ou 32 est un bon point de départ. Pour un schéma avec beaucoup de petites distinctions, 64 est la limite haute et il est rare d’aller au-delà. Le défaut est 8 couleurs, ce qui est un compromis raisonnable entre fidélité et taille, et c’est explicite dans le code source que ce défaut a été mesuré.

Le SVG produit a un `viewBox="0 0 width height"` calculé depuis les dimensions de l’image source, sans quoi le SVG est techniquement vectoriel et pratiquement de taille fixe. C’est explicite dans le code source, et c’est la propriété qui rend le fichier redimensionnable : sans `viewBox`, l’attribut `width` et `height` fixent la taille et tout le reste s’aligne sur eux.

Le namespace XML est ajouté après le passage par imagetracerjs, parce que la bibliothèque l’omet et qu’Illustrator et Inkscape refusent alors le fichier. C’est une correction silencieuse, et c’est explicite dans le code source. Pour ouvrir le SVG dans un navigateur ou un éditeur, le fichier est conforme ; pour l’utiliser dans un pipeline qui valide le XML, il passe la validation standard.

EXIF, GPS, XMP, IPTC et le profil ICC ne survivent pas. Le SVG produit est un fichier de chemins et de formes, et il n’a pas de canal pour les métadonnées. Pour une image qui n’avait rien à perdre — un logo, un pictogramme, un schéma — c’est sans importance.

Pour une photographie qui portait des métadonnées, c’est une perte réelle, et la conversion n’est de toute façon pas le bon outil pour ce contenu. La page de suppression des métadonnées sur le WebP source est l’endroit où les métadonnées sont effacées exprès, et c’est l’outil adapté pour un cas où les métadonnées doivent disparaître.

Un WebP peut contenir une animation, et un SVG peut en contenir une aussi, mais les deux formats représentent l’animation différemment. La conversion ne produit pas d’animation : un WebP animé devient un SVG qui représente la première image de l’animation, et le mouvement est perdu.

Pour un asset UI animé, c’est explicite que la conversion vers SVG via cette chaîne n’est pas le bon chemin. La conversion vers APNG ou vers un format vidéo préserve l’animation, et c’est l’une des autres conversions de ce site. Pour un logo ou un pictogramme qui n’est pas animé à la source, c’est sans importance.

La vectorisation demande du calcul, et le navigateur le fait dans l’onglet. Aucun octet n’est téléversé, aucun service n’est appelé, et la conversion n’a pas de quota à dépenser. Pour un dossier d’images dont la moitié ne se vectorise pas proprement, l’absence de coût à l’essai est ce qui rend le workflow praticable : on convertit, on regarde, on garde ce qui marche, on refait le reste autrement.

Le plafond gratuit de 100 Mo par fichier est bien au-delà de ce que la plupart des images à vectoriser pèsent jamais. Pour un dossier de logos et d’icônes, c’est un workflow qui marche, et c’est explicite dans le code source que c’est le cas d’usage ciblé par cette conversion.