Convertir ICO en TIFF

Notre encodeur TIFF utilise `UTIF.encodeImage` sans compression, et c’est un choix documenté dans le code source. Le commentaire qui justifie ce choix est sans détour : LZW, Deflate et JPEG-in-TIFF ont chacun des problèmes d’interopérabilité, et la solution simple est de n’utiliser aucun de ces schémas. Le fichier produit est donc un bitmap brut, beaucoup plus gros qu’un PNG équivalent, et c’est le prix de la simplicité.

Pour un ICO source de 256 × 256, le PNG encapsulé pèse 15-25 Ko. Le TIFF non compressé du même visuel pèse 200-260 Ko. Pour une icône 32 × 32, le PNG fait 1-2 Ko et le TIFF fait 3-4 Ko, ce qui reste supportable. Pour un logo d’application en 512, on monte à 800 Ko-1 Mo, ce qui commence à devenir lourd pour un asset. Si la taille de fichier compte, restez en PNG.

TIFF supporte un canal alpha, et notre encodeur le porte. Une icône avec ses coins arrondis arrive donc en TIFF avec sa transparence, posée sur rien. C’est un comportement cohérent avec PNG et JXL, et c’est l’un des formats raster qui préservent réellement la transparence dans notre pipeline, aux côtés de WebP et AVIF. Pour un asset destiné à être composé sur un fond, c’est une sortie correcte.

La nuance est que le TIFF a un modèle d’alpha différent du PNG (extra samples, et non un canal explicite), et certains logiciels anciens lisent mal l’alpha TIFF. Pour un archivage long, c’est un risque. Pour un flux print qui passe par un logiciel qui comprend l’alpha TIFF (Photoshop, GIMP, les grandes suites), c’est sans problème. Vérifiez la chaîne en aval avant de choisir cette cible.

Un TIFF peut être multi-pages, mais un ICO est multi-tailles. La conversion lit l’ICO comme une image fixe, prend la plus grande taille, et la passe au codec TIFF. Le fichier produit est un TIFF simple, mono-page, à la résolution de la taille lue. Si l’ICO source était un set de tailles, seule la plus grande arrive en sortie.

Pour les usages qui ont besoin de plusieurs tailles de l’icône, c’est un pipeline inadapté. Il faut un outil qui sache extraire chaque taille de l’ICO. Notre convertisseur le fait dans un seul cas, et c’est celui où l’utilisateur a demandé l’ICO et veut une image raster simple, ce qui est le cas pour l’immense majorité des demandes de conversion. Le multi-tailles reste un cas spécialisé.

Le bon usage de cette conversion est un flux qui exige du TIFF en sortie pour des raisons en aval. Une chaîne d’archivage qui veut du TIFF comme format de conservation, un flux print qui prend du TIFF en entrée, un logiciel ancien qui ne lit que du TIFF. Pour ces cas, c’est la cible qui s’impose, et la conversion depuis l’ICO est un détail dans le pipeline.

Le mauvais usage est de croire que TIFF est « mieux » que PNG parce que c’est plus ancien ou plus « pro ». Un PNG bien optimisé est plus compact qu’un TIFF non compressé, et la qualité visuelle est identique au pixel près. Pour la plupart des usages modernes, PNG est supérieur. Pour un asset qui doit entrer dans une chaîne qui exige TIFF, cette conversion existe, et c’est ce qu’il faut utiliser.

Notre encodeur TIFF écrit en RGB 8 bits par canal, ce qui correspond à 24 bits par pixel, et c’est ce que la plupart des chaînes en aval attendent. Un ICO source est lui-même en 8 bits par canal, donc rien n’est perdu sur ce point. Si la source avait un profil colorimétrique (sRGB, Adobe RGB), il est perdu en sortie, et le TIFF est supposé sRGB par défaut, comme un PNG ou un JPG non tagué.

Pour un print professionnel qui doit respecter un profil précis, c’est un défaut, et il faut un outil qui accepte le profil comme paramètre. Notre pipeline raster n’accepte que `ImageData` et `{ quality }`, et le profil n’est pas dans cette liste. C’est cohérent avec les autres cibles raster, et c’est ce qui fait que le fichier produit est léger et propre.

L’ICO encapsule un PNG, qui peut porter EXIF, XMP, ICC. Notre pipeline décode en pixels, ré-encode en TIFF, et tout ce qui n’est pas pixel disparaît. Aucun tag d’auteur, de date, de logiciel source ne traverse. Le TIFF produit est un fichier propre, sans aucune métadonnée technique.

Pour un envoi, c’est en général ce que l’on veut. Pour un archivage qui doit conserver la trace de la création, c’est un défaut, et il faut un outil qui accepte les métadonnées comme paramètre. Notre pipeline ne le fait pas, et c’est explicite dans le code. Pour cette cible précise, c’est moins limitant que pour JPG, parce que le TIFF a un modèle de métadonnées riches dans la spec, mais notre encodeur n’exploite pas ce modèle.

Un ICO 32 × 32 devient un TIFF de 3 à 4 Ko. Un ICO 256 × 256 pèse 200-260 Ko. Un ICO 512 × 512 monte à 800 Ko-1 Mo. Le ratio entre TIFF et PNG est typiquement de 8 à 12 fois, selon la complexité de l’image. Le décodeur TIFF est rapide, le fichier est portable, et c’est presque tout ce qu’on peut dire de positif sur la taille.

Pour un envoi en pièce jointe, c’est rédhibitoire pour les grandes tailles. Pour un archivage sur disque, c’est sans importance. Pour un flux qui prend du TIFF en entrée, c’est sans importance aussi. Le bon réflexe est de ne convertir en TIFF que si la chaîne en aval l’exige, jamais par défaut. Pour un usage général, PNG est plus sensé.

L’ICO source n’est pas uploadé, le TIFF produit n’est jamais transmis. La conversion se fait dans l’onglet, en mémoire, par les encodeurs chargés à la demande. Pour les icônes d’application qui peuvent indiquer une suite logicielle interne, c’est important. Aucun fichier ne quitte l’appareil, et l’onglet réseau reste vide pendant la conversion.

Les fichiers jusqu’à 100 Mo sont pris en charge, ce qui est très large pour ce format, et l’ensemble du calcul est client pour cette paire. C’est la seule forme sous laquelle la phrase « privé » signifie quelque chose : aucune requête vers l’extérieur pendant que la conversion tourne, et l’assertion se vérifie dans l’onglet réseau des outils de développement.