Convertir TIFF en JXL

JPEG XL combine ce que le PNG fait bien (sans perte parfait, alpha) et ce que le JPEG fait bien (perte efficace pour les photographies) dans un seul format, avec une efficacité de codage qui dépasse les deux. Pour un TIFF qui doit aller sur un site web ou dans un système moderne, c’est souvent la meilleure cible : sans perte quand le scan doit être fidèle bit pour bit, avec perte quand la taille compte plus que la fidélité parfaite.

Tous les grands navigateurs actuels lisent le JXL, ce qui en fait un format viable pour la publication web. Pour un archivage numérique, un JXL sans perte est souvent plus petit qu’un PNG équivalent, et conserve la profondeur et la fidélité de la source.

Le JXL supporte les deux, et le réglage décide. Sans perte, chaque pixel qui sort est exactement le pixel qui est entré, à la même fidélité que le PNG. Avec perte, le défaut 82 équilibre taille et qualité, avec un mode d’effort plus élevé qui ralentit l’encodage mais gagne quelques pour cent de plus en taille.

Pour un scan de document, un schéma ou un dessin technique, sans perte est en général le bon choix : la différence de taille avec « avec perte à 82 » est faible et la fidélité est garantie. Pour une photographie scannée ou un document avec dégradés, avec perte à 82 est le défaut sensé, et pousser vers 90 aide si les dégradés montrent des paliers.

Le TIFF peut contenir plusieurs images dans un seul fichier. La conversion lit la première page et s’arrête, sans erreur et sans message qui dirait que d’autres suivaient. Un document de dix pages scanné donne un JXL d’une page et neuf qui n’existent nulle part.

Pour un document, la bonne cible est TIFF en PDF, qui garde toutes les pages dans un seul fichier. Pour un lot de scans individuels, scindez le TIFF avant la conversion, en utilisant ImageMagick, IrfanView ou le logiciel du scanner.

Beaucoup de TIFF scientifiques sont en 16 bits par canal, précieux pour des mesures en niveaux bas mais inutile pour l’affichage. La conversion réduit à 8 bits par canal en gardant l’octet de poids fort, ce qui donne au JXL ce qu’il attend et rend le fichier nettement plus petit.

Pour une photographie affichée à l’écran, la différence est invisible. Pour une image dont l’information vit dans les bits bas (mesure de fluorescence, raster d’élévation), la perte est silencieuse et aucun réglage ne la prévient. Gardez le TIFF comme copie de travail et traitez le JXL comme la version à publier.

Le canal alpha passe : un TIFF avec un fond détouré arrive en JXL avec son alpha intact, ce qui permet de le déposer sur n’importe quel fond sans rectangle blanc. C’est l’un des formats où la transparence est un citoyen de première classe.

Elle est stockée comme un canal à part entière. Sur un dessin simple, c’est une part visible de la taille totale. Sur une photographie avec peu de zones transparentes, l’alpha ajoute un peu mais pas de manière disproportionnée. Pour les scans de document, l’alpha n’est en général pas présent.

Les TIFF produits pour l’imprimerie sont souvent en CMJN. Le JXL n’a pas de mode CMJN, et la conversion passe l’image en RVB avec une formule fixe plutôt qu’à travers le profil ICC embarqué. Quelques couleurs se déplacent légèrement, parce que les deux modèles ne couvrent pas exactement le même espace.

L’effet visible se limite en général aux cyans saturés et aux bleus profonds. Pour afficher, envoyer ou publier à l’écran, ce n’est rien. Si le fichier est destiné à être ré-imprimé, gardez le TIFF d’origine pour l’imprimeur.

Le PNG utilise Deflate, qui est bon sur les répétitions et mauvais sur les dégradés. Le JXL utilise un système de prédiction plus sophistiqué qui s’adapte au contenu : pour un document à aplats, il trouve des répétitions comme le PNG ; pour un dégradé, il suit la courbe avec une précision que Deflate ne peut pas atteindre.

Mesuré sur un scan de test à 1 024 pixels en niveaux de gris : sans perte, le JXL sort en général 20 à 40 pour cent plus petit que le PNG équivalent, parfois plus. Avec perte à 82, le JXL sort nettement plus petit qu’un PNG (sans perte) à qualité perçue comparable. C’est la migration qu’un pipeline moderne peut faire.

Le JXL a un réglage d’effort qui va de 1 (rapide, moins bon) à 9 (lent, optimal). Le défaut est 7, qui est l’équilibre sensé entre temps et qualité pour un scan qui sera publié tel quel. Pour un batch de cent images où chaque seconde compte, réduire à 5 ou 6 est perceptible en vitesse sans grande perte de qualité, et descendre à 3 est acceptable pour un thumbnail jetable.

L’effort ne change que le temps d’encodage, pas la qualité visuelle au même niveau de qualité. Un effort 9 à qualité 82 n’est pas meilleur qu’un effort 7 à qualité 82, il est seulement plus petit en octets grâce à une recherche plus longue qui trouve de meilleures prédictions de bloc. Pour la plupart des usages web, l’effort 4 par défaut suffit largement et le gain marginal d’effort 8 n’est pas visible à l’œil sur une photographie.

Le réglage `maxWidth` borne la largeur de sortie. Le défaut est 0, ce qui veut dire pas de limite et le TIFF est rendu à sa largeur native. Pour un scan à 600 dpi d’une page A4, c’est environ 5 000 pixels, ce qui est inutilement grand pour un site web et ce qui ralentit l’encodage pour rien.

Pour le web, une largeur de 1 200 à 2 000 pixels est en général suffisante. Pour un thumbnail, 400 à 800 pixels suffit. Le réglage `maxWidth` est appliqué après le décodage et avant l’encodage, donc un scan énorme est réduit en une fois et le JXL est écrit à la taille réduite.

Le TIFF est décodé par utif2, le JXL est encodé par `@jsquash/jxl`, les deux en WebAssembly dans cet onglet. Aucun fichier n’est téléversé, aucun compte n’est nécessaire, aucun quota quotidien ne s’applique.

Pour un scan de document confidentiel, un dossier client, ou un scan médical, c’est la propriété qui compte. Une conversion qui ne quitte jamais le navigateur supprime la question de savoir si le service de conversion a vu le fichier, ce qui est différent d’y répondre avec une politique de confidentialité.