Convertir ORF en TIFF

TIFF date de 1986 et n’a jamais été le format d’aucun appareil photo grand public. C’est en revanche le conteneur d’archive de la photographie argentique numérisée, des scanners, des banques d’images, des bibliothèques de recherche, et c’est aussi le format d’export de presque tous les logiciels de développement qui existent. Un ORF qui doit entrer dans un de ces pipelines passe en TIFF parce que tout le monde en aval sait le lire.

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. Quand la taille compte, PNG est la bonne réponse. Quand la portabilité dans un écosystème hétérogène compte, TIFF est la bonne réponse.

L’ORF porte un JPEG de prévisualisation que l’appareil a généré à 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 de la courbe de tonalité d’une autre manière que celle qu’Olympus a choisie à la prise de vue.

Cette fidélité a une limite évidente : si l’appareil a été réglé sur un style de picture flat, neutre, ou noir et blanc, c’est cette apparence qui est dans le TIFF. Le fichier ne contient aucune information sur ce qu’il aurait pu devenir avec un développement différent, et c’est ce qui distingue un dérivé d’un maître.

Si l’ORF contient un TIFF multi-pages comme aperçu — ce qu’Olympus fait sur certains modèles pour la mise au point avec empilement ou les bracketing d’exposition — 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 ORF.

Conséquence pratique : si l’empilement de mise au point ou le bracketing a généré un TIFF de plusieurs pages, c’est la première exposition qui sort, et les autres sont laissées dans l’ORF. Pour les reconstituer, il faut un logiciel qui lit la structure de pages complète, et ORF ne fournit pas cette voie.

Le capteur d’un Olympus récent enregistre en 12 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, exactement à la granularité de ce que l’appareil a choisi de prévisualiser.

Pour une sortie qui sera ajustée fortement — normalisation, étirement de contraste, alignement par histogramme — c’est la mauvaise source. Développez l’ORF dans le logiciel de votre choix et exportez un TIFF 16 bits, qui est l’entrée correcte pour ce genre d’opération.

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 TIFF qui sort est un conteneur de pixels et rien d’autre, comme le précise le module d’encodage. Le profil ICC de l’aperçu, qui décrivait l’espace colorimétrique d’interprétation Olympus, est retiré également, et la sortie est implicitement en sRGB sans le déclarer.

Un pipeline qui a besoin de ces informations doit les lire de l’ORF séparément et les porter dans un sidecar ou un manifeste. C’est en général la meilleure conception : un catalogue qui lit ses paramètres d’un fichier descriptif séparé est reproductible, alors qu’un catalogue qui les lit dans le dérivé qui se trouve sur le disque ne l’est pas. Un TIFF dérivé qui prétend savoir de quel objectif il vient ment, et la discipline d’un jeu de données propre est de ne jamais laisser cette confusion s’installer dans le catalogue, parce qu’une fois qu’elle y est, elle est très longue à retirer.

TIFF non compressé stocke chaque pixel sur le nombre d’octets nominal, sans chercher à exploiter la redondance du contenu. Une photographie de 20 mégapixels fait environ 60 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 60 Mo affiché dans une page web 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 ORF Olympus, 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, l’ORF est ce qui contient les lectures de capteur pour le faire. Le TIFF ne porte aucune des données qui rendraient cela possible.

L’arrangement qui marche dans un catalogue est de garder l’ORF 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é.