Méthodologie formats d'image

Le cluster Imageconvertit entre PNG, JPG et WebP en utilisant l’API Canvas native du navigateur. Il n’y a pas d’étape d’upload, pas de traitement côté serveur, et aucun service d’imagerie tiers dans le chemin — ce qui a des implications à la fois pour la confidentialité et la qualité.

Le pipeline de conversion

1. L’utilisateur choisit un fichier par glisser-déposer ou sélecteur de fichier.
2. Le fichier est lu comme ImageBitmap via createImageBitmap(file).
3. Un canvas hors écran est créé aux dimensions natives du bitmap.
4. Le bitmap est dessiné sur le canvas.
5. Le canvas est exporté via canvas.toBlob(callback, mimeType, quality) — la qualité s’applique uniquement aux cibles avec perte.
6. Le Blob résultant est proposé en téléchargement.

Chaque étape s’exécute dans le navigateur. Le fichier n’est envoyé nulle part — il n’y a pas de fetch, pas de FormData, pas d’upload XHR. La même chose s’applique à l’outil Image vers Base64, qui utilise l’API FileReader au lieu du canvas mais suit le même principe réservé au navigateur.

Gestion de la qualité

Sans perte → avec perte (PNG/WebP → JPG)

En passant d’un format sans perte à JPG, nous exposons un curseur de qualité (par défaut 0,85) qui contrôle l’agressivité de quantification de l’encodeur JPG. À 0,85, le fichier est généralement 80-95 % plus petit que le PNG source sans différence visuelle perceptible pour les photographies. En dessous de 0,7, des artefacts deviennent visibles ; nous limitons la borne inférieure à 0,5 pour éviter de produire accidentellement une sortie visiblement dégradée.

Avec perte → sans perte (JPG → PNG)

Passer d’un JPG à un PNG ne restaure pas la qualité que le JPG a déjà supprimée. La sortie est bit-parfaite de ce que le JPG a décodé, mais les pertes d’arrondi du JPG sont intégrées. C’est rarement utile en pratique ; le meilleur chemin est de trouver une source de meilleure qualité.

Avec perte → avec perte (JPG → WebP, etc.)

Chaque sauvegarde avec perte introduit de nouvelles erreurs de quantification en plus de celles existantes de la source. Pour les fichiers qui ont déjà subi plusieurs sauvegardes, cela peut provoquer une dégradation composite visible. Toujours réencoder depuis la source de la plus haute qualité disponible.

Ce que nous ne gérons pas

• HEIC / HEIF. Le format par défaut d’Apple depuis iOS 11. La prise en charge du navigateur est essentiellement nulle en dehors de l’écosystème Apple, donc nous aurions besoin de regrouper un décodeur de 1+ Mo. Pas intéressant.
• Formats RAW (DNG, CR2, NEF, ARW). Même problème — décodeurs lourds pour un public faible. Utilisez Lightroom / darktable / RawTherapee.
• SVG ↔ raster. Possible via canvas, mais vecteur → raster perd l’évolutivité et l’inverse perd la fidélité. Conversation différente.
• Conversion par lot. Notre interface gère un fichier à la fois. Pour les traitements par lot, utilisez l’endpoint REST ou un outil de bureau.

Le pipeline d’encodeur, en code

La conversion est suffisamment courte pour être écrite. Avec un Fileprovenant d’une saisie de fichier, le pipeline complet tient en environ six lignes :

const bitmap = await createImageBitmap(file);
const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
const ctx = canvas.getContext("2d");
ctx.drawImage(bitmap, 0, 0);
const blob = await canvas.convertToBlob({ type: "image/webp", quality: 0.85 });
// blob est la sortie convertie, prête à télécharger

Chaque étape est native du navigateur : createImageBitmap décode le format source (défini dans le HTML Living Standard), OffscreenCanvas fournit une surface de dessin sans rendu, et convertToBlobinvoque l’encodeur WebP / JPEG / PNG intégré du navigateur avec le paramètre de qualité défini par la spécification (0-1 pour les formats avec perte, ignoré pour PNG). Le même encodeur est celui que Chrome utilise pour sauvegarder les canvas via toDataURL; nous routons simplement le résultat vers un téléchargement au lieu d’une chaîne. Il n’y a pas de WASM, pas de bibliothèque tierce et pas d’appel réseau — le pipeline entier tourne en environ 40-200 ms pour une entrée 4K sur un ordinateur portable de classe 2023.

Sources & références

Le comportement d’encodage est défini dans le HTML Living Standard pour la sérialisation du canvas. JPEG baseline DCT provient d’ITU-T T.81 ; PNG de l’IETF RFC 2083 ; WebP de RFC 9649. La sémantique de qualité — le paramètre quality entre 0 et 1 pour les encodeurs avec perte — est normative dans la spécification HTML.

Hypothèses & limites

• Un fichier à la fois.L’interface prend un seul fichier par session. Le réencodage en lot nécessite un script contre l’API REST ou un outil de bureau.
• Encodeurs natifs du navigateur.La qualité de sortie dépend du navigateur de l’utilisateur. L’encodeur WebP de Chromium est libwebp ; Firefox utilise le sien. Des différences d’artefacts subtiles entre moteurs existent à quality < 0,7.
• Pas de décodage HEIC/HEIF/RAW. Les saisies dans ces formats ne peuvent pas être ouvertes via createImageBitmap dans la plupart des navigateurs sans un shim WASM que nous ne livrons pas.
• Pas d’encodage AVIF.La lecture est prise en charge dans les navigateurs modernes ; l’écriture nécessite WASM (libaom), ce qui pousserait le bundle au-delà d’une taille acceptable.
• Sans perte ↔ avec perte est à sens unique.Le réencodage d’un JPG en PNG ne restaure pas les informations ; le PNG réencodé est bit-parfait du JPG décodé, avec ses pertes de quantification intégrées.
• Profil ICC préservé uniquement pour les réécritures dans le même format.La conversion inter-format (PNG → JPG) peut supprimer le profil ICC intégré selon l’implémentation du navigateur.
• Limité par la mémoire. Les très grandes saisies (40+ mégapixels) peuvent provoquer un manque de mémoire sur Safari mobile.

Plancher de compatibilité navigateur

L’encodage WebP via canvas.toBlobnécessite Chromium 23+, Firefox 65+, Safari 14+, Edge 79+. En 2026, cela représente >97 % du trafic mondial. L’encodage AVIF n’est pas pris en charge dans l’API canvas du navigateur ; il nous faudrait un encodeur WASM pour livrer cette cible, ce qui est au programme.