Outil de Compression d'Images

La compression d'image en ligne réduit la taille des fichiers afin d'accélérer le chargement des pages, de respecter les limites d'envoi et de consommer moins de bande passante lors du partage. Les fichiers sont téléchargés vers le service de conversion de ToolAct, traités côté serveur par les bibliothèques d'image (libvips, mozjpeg, libwebp) qui décodent et ré-encodent l'image, puis le résultat compressé est renvoyé au navigateur ; après la conversion, les fichiers temporaires sont immédiatement supprimés du serveur, ne sont pas archivés et ne sont pas utilisés pour l'entraînement. Selon le format, la compression peut agir sur la qualité, les métadonnées, les couleurs et les détails d'encodage ; une photo peut devenir beaucoup plus légère tout en restant correcte à l'affichage courant. L'outil convient aux images de blog, fiches produit, publications sociales, pièces jointes de support et brouillons qui n'ont pas besoin de conserver chaque pixel original. Pour l'impression, l'archivage ou l'examen de détails fins, le résultat doit être vérifié après compression. Évitez de téléverser des photos contenant des informations personnelles, des documents internes ou tout autre contenu sensible.

La compression d'image se divise nettement selon la frontière avec/sans perte. Les formats avec perte (JPEG, WebP avec perte) exploitent les limites perceptuelles humaines : l'œil est bien moins sensible à la chrominance haute fréquence qu'à la luminance, de sorte que les encodeurs éliminent les fins détails de couleur dans des blocs de 8x8 ou 16x16 sans que la plupart des observateurs ne le remarquent. JPEG utilise cette voie basée sur la DCT depuis 1992 ; les alternatives modernes sont mozjpeg (~5 à 10 % plus petit que libjpeg au même SSIM, encodeur plus lent), libwebp (le codec d'image VP8/VP8L de Google, 2010) et AVIF (Alliance for Open Media, AV1 intra, 2019). Les formats sans perte (PNG, GIF, WebP sans perte) réduisent les octets par codage entropique — dictionnaire à fenêtre glissante LZ77 plus codage de Huffman ou arithmétique — sans jamais altérer un seul pixel. Le pipeline utilisé par cette page est entièrement côté serveur. Le navigateur empaquette chaque image dans un téléversement multipart signé vers le point de terminaison de compression de ToolAct (/image/compress). Le serveur valide la requête puis transmet les octets à libvips — une bibliothèque de traitement d'image streaming, à demande, performante et économe en mémoire — qui décode la source, redimensionne au besoin le bord long pour borner les dimensions de sortie, et ré-encode via mozjpeg pour JPEG, libwebp pour WebP, ou libpng/oxipng pour PNG. Les octets encodés sont diffusés directement au navigateur sous forme de réponse de téléchargement, et le fichier temporaire de téléversement est supprimé du disque dès que la réponse est écrite. Il n'y a ni archivage, ni pipeline d'entraînement, ni examen humain du contenu. La quantification JPEG est le cœur du format : une qualité de 90 conserve presque tous les coefficients DCT, 75 commence à éliminer ceux de fréquence moyenne (visibles dans du texte rouge sur fond jaune), 50 est la zone JPEG évidente où des artefacts de blocage apparaissent sur les dégradés lisses, et 25 produit une postérisation visible sur les visages. La compression PNG repose sur zlib (DEFLATE) niveaux 0 à 9 ; le niveau 1 est rapide mais produit des fichiers plus volumineux, le niveau 9 compresse les derniers octets des bannières en couleur unie au prix du processeur. Les métadonnées EXIF, profils ICC, XMP et IPTC sont généralement supprimées car l'encodeur reconstruit l'en-tête du fichier de zéro — raison pour laquelle une photo de 200 Ko d'un appareil peut devenir un fichier de 60 Ko à résolution identique, et raison pour laquelle les métadonnées de provenance et de gestion colorimétrique doivent être préservées séparément si elles comptent.

• libvips (John Cupitt, LGPL) est le moteur de traitement d'image côté serveur : un pipeline streaming, à demande, qui maintient une consommation mémoire faible même sur des entrées de 100 Mpx et qui sous-tend Sharp, le délégué vips d'ImageMagick IM7 et les points de terminaison de conversion derrière cet outil.
• mozjpeg (Mozilla, fork de libjpeg-turbo avec de meilleurs modèles psychovisuels) produit des fichiers 5 à 10 % plus petits que libjpeg standard au même SSIM mais est environ 3 à 5x plus lent à encoder — le compromis derrière la plupart des valeurs par défaut web JPEG qualité 80-85 depuis 2017.
• PNG est LZ77 + Huffman : l'encodeur trouve des séquences d'octets répétées jusqu'à 32 Ko en arrière (fenêtre glissante), émet des paires (distance, longueur), puis code le résultat en Huffman. WebP sans perte (VP8L) utilise une idée similaire avec des patches Local Palette, battant généralement PNG de 20 à 26 % sur les mêmes pixels RGBA.
• libwebp est l'encodeur/décodeur WebP de référence de Google ; le côté serveur l'utilise pour écrire soit du VP8 avec perte (qualité 0-100, chrominance 4:2:0 par défaut), soit du VP8L sans perte (la qualité contrôle l'effort de compression, jamais la fidélité des pixels). Le décodage WebP est largement disponible (Chrome 32+ 2014, Firefox 65+ 2019, Safari 14+ 2020), donc un WebP converti est sûr pour presque tous les navigateurs modernes.
• Le sous-échantillonnage de chrominance 4:2:0 par défaut dans JPEG (deux échantillons de chrominance pour 4 de luminance) est ce qui rend le texte rouge sur fond jaune flou à qualité 60 — le détail de chrominance est éliminé avant celui de luminance. Passez en 4:4:4 (pas de sous-échantillonnage) pour les captures d'écran et d'interface où les contours du texte importent.
• Les métadonnées EXIF (Exchangeable Image File Format, JEITA CP-3451) et les profils colorimétriques ICC sont supprimés par défaut lors du ré-encodage, de sorte qu'un JPEG iPhone de 6,3 Mo tombe souvent à 1,8 Mo après passage par le serveur. C'est pourquoi les photographes amateurs voient la taille des fichiers diminuer après chaque aller-retour dans un outil web. Un piège pratique en lot : lorsqu'un dossier mélange de petites icônes (moins de 200x200 px, PNG avec alpha), des captures d'interface en couleur unie (PNG, très haute compressibilité) et des photos de téléphone (JPEG, contenu principalement bruité), un seul curseur de qualité est inadapté aux trois. Les icônes veulent du PNG sans perte ou WebP sans perte ; les captures veulent du 4:4:4 JPEG à qualité 85-90 ; les photos veulent du WebP avec perte à qualité 75-80. Tout compresser à qualité 60 économise des octets mais introduit du frangement rouge sur les icônes, des artefacts de contour sur les captures et du banding sur les photos. Le pipeline le plus malin traite chaque catégorie via un chemin d'encodeur différent, raison pour laquelle l'API accepte un format cible de remplacement par fichier même quand l'utilisateur choisit une valeur par défaut. Pour l'avenir, JPEG XL (ISO/IEC 18181, 2022) est le format que Google et Cloudflare promeuvent depuis 2020 comme successeur de JPEG : ~20 % plus petit à qualité égale, mode entièrement sans perte, pas de sous-échantillonnage de chrominance et décodage progressif adapté aux réseaux lents. Le support navigateur est partiel (Chrome a désactivé JPEG XL dans Chrome 110), le chemin de migration pratique actuel est donc WebP à qualité 80, AVIF pour les ressources principales nécessitant l'économie supplémentaire, et un fallback JPEG pour les anciens Safari ou les clients e-mail plus anciens. La page expose la qualité, la dimension maximale et le format cible comme les trois leviers importants ; tout le reste est un détail d'implémentation.
• Cycle de vie de la conversion côté serveur : chaque fichier téléversé n'est conservé que le temps d'exécuter le décodage + ré-encodage libvips et de diffuser le résultat en retour. Le fichier temporaire est supprimé à la fermeture de la réponse, que la conversion ait réussi ou échoué. Un JPEG de 24 Mpx qui aurait bloqué le fil principal du moteur de rendu pendant 200 à 500 ms est entièrement traité hors de l'appareil de l'utilisateur.
• Migration : AVIF est la cible de nouvelle génération (Alliance for Open Media, AV1 intra, supporte 10/12 bits, alpha, animation). L'encodage AVIF côté serveur via libavif/aom reste 10 à 30x plus lent que WebP, la plupart des pages s'en tiennent donc à WebP à qualité 80 et réservent AVIF aux photos principales qui bénéficient de l'économie de 15 à 20 % supplémentaire en octets.