Convertisseur de Format d'Image

La conversion de format d'image transforme un fichier d'un format vers un autre, par exemple PNG en JPG, WebP en PNG ou JPG en WebP. Chaque format a ses compromis : JPG est efficace pour les photos, PNG conserve transparence et bords nets, WebP peut réduire le poids, BMP est simple mais volumineux et GIF sert souvent aux animations légères. Les fichiers sont téléversés vers le service de conversion de ToolAct, traités côté serveur par libvips, puis le résultat converti est renvoyé au navigateur ; le fichier temporaire est supprimé du serveur immédiatement après la conversion, n'est pas archivé et n'est pas utilisé pour l'entraînement. Le choix du format de sortie compte : la transparence peut disparaître en JPG, les formats avec perte altèrent certains détails, et les métadonnées ou profils colorimétriques ne sont pas toujours conservés à l'identique. Le bon format dépend de l'usage final, et pas seulement de la taille du fichier.

La conversion de format d'image est un pipeline « décodage + ré-encodage ». Les octets sources sont envoyés à un décodeur de plateforme (libpng, libjpeg-turbo, libwebp, libheif/dav1d pour AVIF, OpenJPEG pour JP2, libtiff pour TIFF) qui produit un tampon de pixels bruts dans un espace colorimétrique connu (presque toujours sRGB avec transfert linéaire ou non linéaire). Le tampon de pixels traverse ensuite l'encodeur du format cible, avec le paramètre de qualité choisi. Dans cet outil, l'ensemble du processus se déroule côté serveur : le navigateur téléverse chaque fichier vers le point de terminaison de conversion vips de ToolAct, libvips orchestre le décodage, le redimensionnement optionnel, la gestion de l'espace colorimétrique et le ré-encodage via le codec cible, et les octets convertis sont diffusés en retour au navigateur sous forme de téléchargement indexé par taskId. Le fichier temporaire de téléversement est supprimé du serveur dès que la conversion est terminée — il n'est pas archivé et n'est introduit dans aucun pipeline d'entraînement. JPEG (Joint Photographic Experts Group, ISO 10918-1 / ITU-T T.81) est le cheval de bataille de la compression photo avec perte. L'encodeur découpe l'image en blocs de 8x8 pixels (c'est la plus petite unité sur laquelle opère le codec), applique une transformée en cosinus discrète 8x8 (DCT, la DCT de type II de la norme) sur chaque bloc, divise les 64 coefficients de fréquence résultants par une matrice de quantification 8x8 (la Q-table ; la table à 50 % de qualité est celle par défaut, une qualité plus basse multiplie la table pour éliminer plus de détails haute frégence), balaie les coefficients en zig-zag dans un vecteur 1D et applique un codage de Huffman sur le résultat. Le bloc 8x8 est la raison pour laquelle JPEG présente des artefacts « blocs » visibles près des contours à basse qualité : la base DCT est calculée par bloc, de sorte que les blocs voisins sont quantifiés indépendamment. JPEG ne supporte pas le canal alpha et utilise YCbCr en interne (Y = luminance, Cb/Cr = chrominance), l'encodeur sous-échantillonne donc généralement la chrominance (4:2:0, 4:2:2 ou 4:4:4) pour économiser 50 % ou plus sur les octets de chrominance. Le JPEG progressif (scans multiples) améliore la vitesse de chargement perçue sur les connexions lentes. PNG (Portable Network Graphics, ISO 15948, recommandation W3C 2003) est sans perte. Chaque ligne est filtrée (None, Sub, Up, Average, Paeth ; le filtre est choisi par ligne pour maximiser la compressibilité) et les lignes filtrées sont compressées par DEFLATE (la même chaîne LZ77 + Huffman que celle utilisée par ZIP). PNG supporte le mode indexé (palette) pour les images à 256 couleurs ou moins, RGB et RGBA avec 1, 2, 4, 8 ou 16 bits par canal. Le PNG indexé est le format le plus efficace en espace pour les icônes, les dessins au trait et les éléments d'interface (un logo 1-bit peut ne peser que quelques Ko). Sans perte signifie que chaque pixel est conservé à l'identique, ce qui est essentiel pour les ressources d'interface, les images scientifiques et tout ce qui sera réédité. WebP (Google, 2010, RFC 9649 / ISO/IEC 23000-22) est un format moderne polyvalent. WebP avec perte utilise le codage intra-image VP8 (le même codec basé sur la DCT que la vidéo WebM), produisant des fichiers 25 à 35 % plus petits que JPEG à qualité perçue équivalente. WebP sans perte utilise le filtrage prédictif + codage entropique, produisant des fichiers 26 % plus petits que PNG. WebP supporte le canal alpha dans les deux modes et l'animation (WebP animé est le remplacement moderne du GIF). L'encodage est un peu plus lent que JPEG ; le décodage est comparable sur les CPU modernes avec accélération SIMD (les chemins neon/sse2 de libwebp). AVIF (AV1 Image File Format, ISO/IEC 23000-22) est le successeur basé sur AV1. AV1 est un codec exempt de redevances de l'Alliance for Open Media (Google, Mozilla, Apple, Microsoft, Netflix, etc.) utilisant des outils plus sophistiqués : prédiction intra avec 65 modes directionnels, filtres à 6 taps, super-blocs 64x64 et codage entropique adaptatif par contexte. Résultat : 20 % plus petit que WebP au SSIM équivalent, et nettement meilleur que JPEG à très bas débit. L'encodage est 5 à 10x plus lent que WebP en raison de la recherche de prédiction plus riche ; le décodage est accéléré par le matériel sur les GPU modernes (Intel Tiger Lake+, Apple M1+, Adreno récents). AVIF supporte la couleur 8/10/12 bits, l'alpha et les espaces colorimétriques larges (BT.2020, Display P3), ce qui en fait le format de choix pour le contenu HDR. D'autres formats à connaître : HEIC/HEIF (ISO 23008-12, format par défaut d'Apple depuis iOS 11) est basé sur H.265/HEVC et comparable à AVIF en capacités, mais le paysage des brevets HEVC est complexe. JPEG XL (ISO 18181) est le successeur expérimental de JPEG avec à la fois une recompression sans perte des JPEG existants et une meilleure compression avec perte qu'AVIF ; Chrome et Firefox le supportent, le support Safari est partiel. Pour une page de conversion, les formats pratiques sont JPEG, PNG, WebP, AVIF et GIF (ce dernier restant le seul pour les animations dans les navigateurs, malgré sa limitation à 256 couleurs). L'espace colorimétrique et l'alpha sont les deux principaux écueils. libvips côté serveur convertit en sRGB par défaut sauf si un profil ICC est conservé ; si la source est en Adobe RGB (courant dans les RAW d'appareils photo), la conversion est une transformation colorimétrique qui se produit pendant le décodage. Pour l'alpha, JPEG, BMP et GIF (sous forme non animée) n'ont pas de canal alpha, les pixels transparents sont donc composites sur une couleur de fond (généralement blanc, configurable sur cette page) ; convertir un PNG RGBA en JPEG sans choisir un fond produit un résultat noir ou transparent qui surprend les utilisateurs. Pour les flux d'impression haute qualité, la sortie CMYK est le bon format (PDF/X-1a ou TIFF avec profil ICC intégré), et un convertisseur web générique cible généralement sRGB — les vraies séparations CMYK nécessitent un pipeline de pré-presse dédié.

• Compression sans perte PNG : chaque ligne de balayage est filtrée (None / Sub / Up / Average / Paeth), les octets filtrés sont compressés par DEFLATE (LZ77 + Huffman, la même famille que ZIP). Le mode indexé (256 couleurs ou moins) est le choix le plus efficace en espace pour les icônes et ressources d'interface.
• Compression avec perte JPEG : blocs de 8x8 pixels → DCT de type II 8x8 → division par la matrice de quantification 8x8 (Q-table) → balayage en zig-zag → codage de Huffman. Le bloc 8x8 est la raison des artefacts « blocs » à basse qualité. YCbCr avec sous-échantillonnage de chrominance (4:2:0 / 4:2:2 / 4:4:4) économise 50 %+ sur les octets de chrominance.
• WebP (Google, 2010, RFC 9649) : avec perte utilise VP8 intra-image (25 à 35 % plus petit que JPEG au même SSIM) ; sans perte utilise le filtrage prédictif + codage entropique (26 % plus petit que PNG). Supporte l'alpha et l'animation. L'encodage est plus lent que JPEG ; le décodage est similaire avec l'accélération SIMD.
• AVIF (AV1 Image File Format, ISO 23000-22) : basé sur AV1, 20 % plus petit que WebP au même SSIM. 65 modes de prédiction intra directionnels, filtres à 6 taps, super-blocs 64x64. L'encodage est 5 à 10x plus lent que WebP ; le décodage est accéléré par le matériel sur Intel Tiger Lake+, Apple M1+, Adreno récents. Supporte 8/10/12 bits, alpha et les espaces colorimétriques larges (BT.2020, Display P3).
• Gestion du canal alpha : PNG / WebP / AVIF / GIF supportent l'alpha. JPEG / BMP non, les pixels transparents sont donc composites sur un fond configuré (généralement blanc). Convertir un PNG RGBA en JPEG sans choisir un fond produit un résultat noir ou transparent surprenant.
• Espace colorimétrique : les RAW d'appareil peuvent être en Adobe RGB, l'affichage écran est en sRGB, l'impression est en CMYK. Le libvips côté serveur convertit en sRGB par défaut ; un décalage d'espace pendant la conversion provoque des dérives de couleurs. Pour une sortie CMYK (PDF/X-1a, TIFF avec profil ICC), il faut un flux d'impression dédié, pas un convertisseur web généraliste.
• Autres formats : HEIC/HEIF (basé sur H.265, format par défaut d'Apple depuis iOS 11) est comparable à AVIF mais avec des brevets HEVC complexes ; JPEG XL (ISO 18181) est le successeur expérimental de JPEG avec une meilleure recompression avec et sans perte des JPEG existants ; GIF (1987, animation 256 couleurs) survit comme le seul format raster animé compatible navigateur.
• Correspondance du paramètre de qualité : WebP et AVIF utilisent une qualité indexée par SSIM (0-100 mappé à un SSIM cible) ; JPEG utilise le facteur d'échelle de la Q-table ; PNG est sans perte donc « qualité » ne contrôle que la stratégie de filtre. Le SSIM est une métrique perceptive, non pixel-exacte : un SSIM de 95 est visuellement identique à l'original, un SSIM de 80 est le point typique « bon pour le web », un SSIM de 60 commence à montrer des artefacts.