« Compresser cette image » recouvre quatre opérations distinctes sous un seul bouton. Savoir laquelle vous coûte de la qualité rend les réglages beaucoup moins mystérieux.
Étape un : le décodage
Le fichier compressé est retransformé en une grille de pixels. Les navigateurs le font en code natif, avec accélération matérielle là où la plateforme la propose, et prennent en charge le JPEG, le PNG, le WebP et l’AVIF — plus le HEIC sur les plateformes Apple, puisque le système d’exploitation embarque déjà ce décodeur.
Le décodage est sans perte vis-à-vis du fichier ; vous obtenez exactement les pixels que le fichier décrit. La perte a déjà eu lieu, au moment où ce qui a produit le fichier l’a encodé.
Étape deux : l’orientation
Les appareils photo de téléphone enregistrent l’orientation brute du capteur, plus une balise EXIF distincte qui indique comment la faire pivoter. Un logiciel qui ignore cette balise produit des photos couchées. L’appliquer signifie faire pivoter la grille de pixels elle-même avant que quoi que ce soit d’autre n’y touche — après quoi la balise devient inutile, ce qui explique en partie pourquoi un réencodage fait disparaître les métadonnées.
Étape trois : le rééchantillonnage
Si la taille cible ne peut pas être atteinte en pleine résolution, l’image est réduite. C’est là qu’une bonne part de la qualité perçue se gagne ou se perd sans bruit. Un filtre « boîte » bon marché fait la moyenne des pixels voisins et adoucit tout ; un filtre de Lanczos pondère un voisinage plus large et garde les arêtes nettes.
Le rééchantillonnage est réellement destructeur — les pixels écartés ne reviennent pas — mais c’est souvent la façon la moins destructrice d’atteindre une petite cible, parce qu’il retire du détail que l’encodeur passerait sinon tout son budget à ne pas réussir à décrire.
Étape quatre : l’encodage
La partie avec perte. Le JPEG convertit vers une représentation luminance plus couleur, écarte une partie de la résolution chromatique (l’œil ne le remarque presque pas), découpe l’image en blocs de 8×8, transforme chacun en composantes fréquentielles, puis quantifie — en arrondissant le détail de haute fréquence jusqu’à le faire disparaître. Le paramètre de qualité est la grossièreté de cet arrondi. Tout ce qui vient ensuite est du codage entropique sans perte, ce qui explique qu’une table de Huffman optimisée ou un balayage progressif fasse gagner des octets gratuitement.
Ce que vient faire WebAssembly
L’encodeur intégré au navigateur est une boîte noire ; vous pouvez demander un chiffre de qualité, et rien d’autre. Pas de tables entropiques optimisées, pas de choix entre JPEG de base et progressif, aucun contrôle sur le filtre de rééchantillonnage, et aucun moyen de savoir combien d’octets produira un réglage sans l’essayer.
Un codec compilé en WebAssembly rend tout cela, au prix des octets dépensés à le télécharger. ToolZool exécute toute la chaîne de cette façon — décodage, orientation, rééchantillonnage et encodage sont du Rust compilé en WebAssembly, dans un worker d’arrière-plan — plutôt que de confier le décodage au navigateur. Trois raisons, toutes pratiques :
- La recherche exige beaucoup d’encodages. Atteindre une taille exacte suppose d’encoder la même image cinq ou six fois. C’est en maîtrisant l’encodeur qu’on rend cela rapide et reproductible.
- Un décodeur doit pouvoir dire non. Un fichier qui déclare 60 000 × 60 000 pixels doit être refusé avant toute allocation, et un fichier tronqué doit échouer plutôt que renvoyer une demi-image. Le décodeur du navigateur prend là ses propres décisions ; le nôtre énonce les limites et les applique.
- La même entrée doit donner la même sortie. Les décodeurs des navigateurs diffèrent dans leur gestion des couleurs et dans leur traitement des fichiers mal formés. Une chaîne qui maîtrise les deux bouts produit les mêmes octets sur tous les appareils, et c’est ce qui rend un résultat vérifiable.
Le coût est assumé : ce moteur est un téléchargement. Il n’est récupéré qu’une fois que vous avez choisi un fichier, si bien que lire une page comme celle-ci ne le paie jamais.
Pourquoi la recherche compte plus que le codec
À taille de fichier cible donnée, l’écart entre un bon encodeur et un excellent se compte en quelques pour cent. L’écart entre deviner un curseur de qualité et chercher le bon est bien plus grand, parce qu’une supposition qui atterrit à 60 % de votre budget a jeté un tiers de la qualité à laquelle vous aviez droit. C’est toute l’idée derrière la compression à une taille exacte, et tenir une limite de 50 KB montre ce que la recherche vous rapporte à l’extrémité la plus difficile de la plage.
