Convertir WebP en TIFF

TIFF — Tag Image File Format — existe depuis 1986 et a été conçu par Aldus pour l’imprimerie. Trente ans plus tard, c’est encore le format d’échange pour l’archivage à long terme, la presse, la prépresse, l’imprimerie offset, et une longue traîne d’outils professionnels qui n’ont jamais migré. C’est aussi un format d’image avec une complexité rare : des pages multiples, des espaces colorimétriques définis, des profils ICC embarqués, et une structure interne basée sur des balises IFD.

Un WebP vers TIFF est une conversion qui ne se justifie que si la destination l’exige explicitement : un service d’archivage, une maison d’édition, un logiciel de prépresse, un flux de production qui a été construit autour du TIFF. Pour un usage ordinaire, le PNG est plus pratique et le JPG est plus compact, et c’est explicite dans le code source que cette conversion produit un TIFF non compressé avec une seule page.

Le TIFF écrit par cette conversion est non compressé. Le code source l’explique explicitement : LZW, Deflate et JPEG-in-TIFF ont chacun des problèmes d’interopérabilité entre lecteurs, et le TIFF non compressé est la seule variante que tous les logiciels ouvrent sans condition. C’est un choix explicite de portabilité maximale, et c’est la raison pour laquelle le fichier est si gros.

Un TIFF non compressé d’une image 2 000 sur 1 500 fait environ neuf mégaoctets. Un WebP équivalent fait quelques centaines de kilo-octets. La différence est un facteur vingt à trente, et c’est le prix de l’universalité : pas de compression, pas de compromis d’interopérabilité, pas de risque qu’un lecteur particulier refuse le fichier. Pour une archive à long terme, c’est le bon choix ; pour un envoi par messagerie, c’est presque toujours le mauvais.

Un fichier TIFF peut contenir plusieurs pages — c’est l’une de ses propriétés classiques, utilisée pour les télécopies multi-pages et les scans de livres. Le TIFF écrit par cette conversion contient exactement une page, et c’est explicite dans le code source : les pages multiples ne sont pas préservées, et un WebP animé donne la première image.

Pour une image fixe, c’est sans importance. Pour un WebP animé, c’est une perte, et c’est explicite. La conversion vers APNG ou vers un format vidéo préserve l’animation, et c’est l’une des autres conversions de ce site. Pour un cas où l’archivage d’une animation est nécessaire, le bon outil est un utilitaire qui produit un TIFF multi-pages, ce qui n’est pas le cas ici.

Le WebP peut porter un canal alpha. Le TIFF peut techniquement en porter un, mais le TIFF que cette conversion écrit ne le fait pas. La transparence est aplatie sur un fond — blanc par défaut, et modifiable par le contrôle de couleur de fond — et c’est explicite dans le code source.

Pour un cas où la transparence doit être préservée, le PNG est le format à utiliser, et c’est explicite sur la page de cette conversion-là. Pour un cas d’archivage où la transparence n’est pas pertinente, aplatir sur blanc est le défaut raisonnable, parce qu’un TIFF archivé est en général destiné à un flux qui ne gère pas la transparence de toute façon.

Le WebP peut porter un profil ICC. Le TIFF aussi. La conversion lit le profil depuis le WebP, et selon ce que le décodeur expose, l’embarque dans le TIFF. Le résultat est une image dont l’espace colorimétrique est explicitement documenté, ce qui est la propriété qui rend le TIFF utile en prépresse et en archivage : un opérateur qui ouvre le fichier vingt ans plus tard sait exactement dans quel gamut les pixels ont été encodés.

Pour un WebP qui portait un profil sRGB, c’est sans surprise : le TIFF porte sRGB et tout est cohérent. Pour un WebP sans profil, le TIFF est implicitement sRGB, et c’est la convention la plus largement respectée. Pour un WebP avec un profil de gamut étendu, le profil passe si le décodeur l’expose, et c’est explicite dans le code source que c’est ce qui est tenté.

Le WebP peut porter des métadonnées : EXIF pour les informations de prise de vue, XMP pour les modifications, IPTC pour les droits, et le profil ICC pour l’espace colorimétrique. Le pipeline raster décode les pixels et les ré-encode sans transporter aucune de ces informations à travers, parce que le code de l’encodeur ne porte que `ImageData` et la qualité.

Pour une image qui n’avait rien à perdre — un asset UI, une capture d’écran, un pictogramme — c’est sans importance. Pour une photographie qui portait des métadonnées, c’est une perte réelle, et la page de suppression des métadonnées sur le WebP source est l’outil qui efface ce qui doit l’être, plutôt que la conversion qui le perd implicitement. Pour un cas où les métadonnées doivent être préservées dans le TIFF, le bon outil est un utilitaire qui copie explicitement les blocs, ce qui n’est pas le cas ici.

Le WebP est avec perte à la qualité standard, et le TIFF est sans perte par construction du format. La sortie est donc sans perte par rapport aux pixels qui ont été décodés, mais ces pixels étaient déjà dégradés par l’encodage WebP en amont. Le TIFF produit est la meilleure représentation possible du WebP, et c’est explicite.

Pour un asset qui doit être archivé fidèlement, c’est la source originale qu’il faut convertir, pas le WebP. Pour un cas où la source originale n’existe plus et où le WebP est tout ce qui reste, le TIFF est la meilleure sortie possible parce qu’il est sans perte par rapport à ce qui est disponible, et c’est le bon choix pour un archivage où la fidélité au WebP est ce qui compte.

Le TIFF est lu par tout. Adobe Photoshop, GIMP, Affinity Photo, les visionneuses d’images, les logiciels de prépresse, les outils d’archivage, les presses offset numériques, les scanners haut de gamme, et la longue traîne d’utilitaires qui ont besoin d’un format d’image sérieux. La compatibilité est ce qui justifie l’usage, et c’est la propriété qu’il faut avoir en tête en convertissant : la cible veut du TIFF, et le TIFF s’ouvrira.

Pour un envoi à un imprimeur, à un service d’archivage, à un éditeur qui demande du TIFF en prépresse, c’est la conversion qui résout la question. Pour un envoi par messagerie ou pour un cas où la taille compte, c’est presque toujours le mauvais choix, et le PNG ou le JPG servent mieux l’usage.

Déposez jusqu’à cent WebP ensemble, et chacun sort en TIFF. Pour une migration vers un flux d’archivage ou de prépresse, c’est une conversion qui revient : des images qui doivent être livrées en TIFF, une bibliothèque à convertir en lot, un service qui demande un format d’image précis.

Comme rien n’est téléversé, un lot ne coûte pas de bande passante et ne heurte aucun quota quotidien. Le ZIP qui sort contient tous les TIFF, et il sera substantiel en taille à cause du non compressé : quelques gigaoctets pour un lot de cent images 4K est attendu. Pour un cas d’archivage où la taille n’a pas d’importance, c’est un workflow qui marche en local et qui se vérifie dans l’onglet réseau des outils de développement pendant qu’une conversion tourne.

Le navigateur décode le WebP avec les codecs qu’il a déjà et encode le TIFF dans le même onglet, sans serveur, sans compte, sans quota. Aucun octet de l’image n’est téléversé, et la conversion n’adresse jamais le réseau sauf pour charger le code de l’encodeur TIFF à la demande.

Pour des images qui peuvent porter des métadonnées privées ou un asset de marque, c’est une garantie qui compte. La vérification se fait dans l’onglet réseau des outils de développement pendant qu’une conversion tourne : c’est la seule forme sous laquelle l’affirmation « privé » signifie quelque chose, et c’est explicite dans le code source de cette conversion que c’est ce qui est garanti.