Convertir RAF en TIFF

TIFF date de 1986 et reste le format pivot des chaînes de conservation en bibliothèque, en recherche, en archive. Un RAF qui doit entrer dans un de ces pipelines passe en TIFF parce que tout le monde en aval sait le lire : banques d’images, scanners, outils d’archivage, logiciels de retouche, visionneuses système, et même certains visionneuses web anciennes.

La conversion écrit en TIFF non compressé. Le module d’encodage appelle UTIF.encodeImage une fois, sans compression, ce qui produit un fichier plusieurs fois plus gros que le PNG équivalent. C’est le compromis connu du format, documenté en clair dans le module : pour la portabilité, la taille est payée. Quand la taille compte, PNG est la bonne réponse ; quand la compatibilité compte, TIFF est la bonne réponse.

Le RAF porte un JPEG de prévisualisation que l’appareil génère à la capture, et c’est ce JPEG qui est décodé puis réencodé en TIFF. Il n’y a pas de dématriçage, pas de lecture du capteur, pas d’application d’une balance des blancs différente de celle que l’appareil a choisie.

Pour un X-Trans, c’est l’information qu’il faut savoir : le filtre couleur propriétaire de Fujifilm complique sérieusement le dématriçage, et la conversion ne prétend pas le faire. Le TIFF sort avec l’apparence que l’appareil a produite, et c’est le fichier que l’archive reçoit. Pour un développement alternatif, c’est un logiciel dédié qui doit être utilisé, et cette conversion n’est pas la voie.

Si le RAF contient un TIFF multi-pages comme aperçu — ce que certains boîtiers Fuji font pour le bracketing d’exposition ou l’empilement de mise au point — seule la première page est lue. Le décodeur prend pages[0] et ignore le reste, ce qui est le comportement défini du module de lecture et qui s’applique à tous les formats, pas seulement RAF.

Conséquence pratique : si l’empilement a généré un TIFF de plusieurs pages, c’est la première exposition qui sort, et les autres restent dans le RAF. Pour reconstituer la série, il faut un logiciel qui lit la structure de pages complète, et RAF ne fournit pas cette voie. C’est une limite de la conversion, pas un défaut du fichier d’origine.

Les capteurs Fuji récents enregistrent en 14 bits, et TIFF accepte 16 bits par canal, mais l’aperçu extrait est un JPEG 8 bits. Le TIFF écrit est donc en 8 bits, à la précision du fichier que l’appareil a choisi de prévisualiser.

Pour un dérivé qui sera ajusté fortement, c’est la mauvaise source. Développez le RAF dans Capture One, darktable, ou Lightroom et exportez un TIFF 16 bits, qui est l’entrée correcte pour ce genre d’opération. C’est précisément pour ce cas que les logiciels de développement existent, et cette conversion ne les concurrence pas.

L’EXIF est retiré au réencodage. Pas de marque d’appareil, pas d’objectif, pas de focale, pas d’exposition, pas de coordonnées GPS, pas d’horodatage. Le profil de simulation de film que l’appareil a appliqué à l’aperçu n’est pas non plus exporté en tant qu’étiquette séparée : il est dans l’apparence de l’image, et c’est tout ce qui atteint la sortie. Le profil ICC de l’aperçu est retiré également, et la sortie est implicitement en sRGB sans le déclarer.

Pour un pipeline qui a besoin de ces informations, le RAF d’origine est l’autorité. Lisez-les de là dans un sidecar ou un manifeste de catalogue, et ne comptez pas les retrouver en ouvrant le dérivé. C’est la discipline qui maintient une archive propre : chaque format a un rôle, et le rôle du TIFF dérivé est le pixel, pas la métadonnée. Un dérivé qui prétend savoir de quelle simulation de film il sort est un dérivé qui ment, et cette confusion s’installe vite quand on mélange les rôles dans un même dossier.

TIFF non compressé stocke chaque pixel sur le nombre d’octets nominal, sans chercher à exploiter la redondance du contenu. Une photographie de 40 mégapixels fait environ 120 Mo, plus une surcharge d’en-têtes et d’IFD. Comparé au même fichier en PNG, c’est un facteur trois à cinq.

Le coût est consenti pour deux raisons. La première est la lisibilité : un TIFF non compressé n’a aucune étape de codage à défaire pour être lu, ce qui le rend robuste aux logiciels anciens ou aux chaînes de traitement partielles. La seconde est l’interopérabilité : presque tout, des visionneuses système aux outils d’archivage en passant par les logiciels de retouche, ouvre un TIFF non compressé sans configuration.

Pour un envoi par messagerie, une vignette de catalogue, une page web, n’importe quel usage où la bande passante ou le stockage compte, TIFF est le mauvais choix. Un TIFF de 120 Mo affiché comme vignette est un gaspillage qui ralentit la page et n’améliore rien pour le visiteur.

Pour ces usages, un JPEG sera plus petit pour une qualité visible équivalente, et un PNG sera plus petit encore quand la zone est plate. Le TIFF gagne sa place quand la destination en a besoin — un système d’archivage, un logiciel de retouche, un pipeline d’analyse — pas quand il est choisi par défaut par habitude.

L’intérêt du lot est l’uniformité. Déposez le dossier complet, appliquez la même largeur maximale, prenez le résultat en ZIP. Faire le travail en plusieurs sessions produit deux largeurs dans le même jeu de données, et c’est l’erreur qu’une collection homogène ne devrait jamais contenir.

Encoder en TIFF à ces résolutions prend du temps, davantage qu’en JPEG où l’aperçu est copié sans réencodage, et bien davantage qu’en PNG où la compression Deflate aide. Les fichiers d’entrée sont acceptés jusqu’à 100 Mo, ce qui couvre la plupart des RAF Fuji, même ceux qui contiennent un TIFF multi-pages complet en aperçu.

Le TIFF est une copie d’accès, pas un second maître. Si quelqu’un a besoin de re-développer la photo avec une balance des blancs différente, une exposition corrigée, ou un recadrage, le RAF est ce qui contient les lectures de capteur pour le faire. Le TIFF ne porte aucune des données qui rendraient cela possible, et c’est précisément la limite d’un dérivé d’aperçu.

L’arrangement qui marche dans un catalogue est de garder le RAF comme archive, le TIFF comme copie de travail visible, et tout ajustement comme un fichier à côté nommé de manière cohérente. Mélanger ces rôles dans un seul fichier est comment un projet finit avec deux versions légèrement différentes et personne ne sait laquelle est la bonne.

TIFF accepte plusieurs schémas de compression en interne : LZW, Deflate, JPEG dans TIFF, et aucune. Cette conversion écrit toujours sans compression, et c’est un choix conscient documenté en clair dans le module d’encodage : les variantes LZW et Deflate posent des problèmes d’interopérabilité anciens, JPEG-in-TIFF n’est pas universel, et la version non compressée est lisible par tout le monde sans configuration.

TIFF est aussi l’un des rares formats dont la prise en charge n’a pas bougé en trente ans : les bibliothèques de lecture et d’écriture sur Python, Perl, C, Java, et la plupart des langages, savent gérer le TIFF non compressé de la même manière qu’en 1995. C’est précisément la propriété qui en fait le bon format d’échange pour des données scientifiques, des images médicales, ou des assets de simulation qui doivent être réutilisés dans dix ans, et c’est aussi pourquoi la taille du fichier est le prix d’une interopérabilité qui ne se démodera pas. Pour un fichier de destination qui exige une compression TIFF, l’étape supplémentaire se fait dans un outil dédié.