Convertir MOV en TIFF

Le décodeur prend l’image à l’instant demandé et l’encodeur l’écrit en TIFF sans compression. Le format TIFF existe depuis 1986 et la variante non compressée est son mode par défaut historique : la valeur de chaque pixel est posée dans le fichier, sans DCT ni palette. Aucun pixel n’est jeté et aucun n’est approximé, ce qui est la définition utile d’une image d’archive.

Le format n’est pas compact — un TIFF sans compression pèse plusieurs fois ce que pèserait un PNG sur la même image, et des dizaines de fois ce que pèserait un JPEG. C’est un choix délibéré et assumé dans la chaîne d’écriture, documenté dans le code de l’encodeur : LZW, Deflate et JPEG-dans-TIFF posaient des problèmes d’interopérabilité qui justifiaient de renoncer à la compression. Pour un original d’archive, la taille est le prix de la lisibilité dans vingt ans.

La conversion prend une image, à l’instant indiqué en secondes depuis le début. Par défaut c’est la première image — 0 seconde — mais n’importe quel moment jusqu’à 24 heures est accepté. L’image arrive à pleine résolution et dans son orientation d’origine, avec la note de rotation appliquée si le fichier en portait une.

Une vidéo MOV n’a pas qu’une seule image à proposer, et la sortie non plus. Il n’y a pas de mode « toutes les images » et il n’y a pas de sortie en lot : pour une planche-contact, il faut relancer la conversion à des instants différents et assembler les TIFF soi-même. Pour un usage en archive c’est presque toujours suffisant, parce que l’instant d’intérêt est connu à l’avance et qu’une planche-contact se fait avec un outil spécialisé mieux placé pour cela.

Le MOV peut transporter du 8 bits, du 10 bits (HDR), ou plus rarement du 12 bits par canal. Le décodeur rend l’image dans la profondeur qu’il trouve, et l’encodeur la pose telle quelle. Un MOV HDR en 10 bits donne un TIFF en 10 bits, et un MOV SDR en 8 bits donne un TIFF en 8 bits, sans conversion intermédiaire.

Cela mérite d’être su, parce que la chaîne d’archivage en aval peut y attacher de l’importance. Un TIFF en 10 bits est exploitable par les outils qui savent le lire, et ignoré par ceux qui ne le savent pas : Photoshop l’ouvre, un ancien viewer le rend plat en 8 bits. Si la cible exige du 8 bits, la conversion vers du PNG aplatira proprement, et il est préférable de garder l’original MOV et le TIFF côte à côte plutôt que de détruire la profondeur par commodité.

Un iPhone enregistre des images en paysage et y attache une note d’orientation. Un téléphone tenu à la verticale produit des pixels en paysage, avec une instruction de rotation que le lecteur applique. La conversion lit l’instruction et l’applique, donc un clip portrait sort en portrait dans le TIFF.

Cela peut ne pas être ce que veut un logiciel d’archive strict. La note de rotation est portée par le MOV, pas par chaque image, et un MOV dont la note a été retirée par un éditeur sort avec les pixels bruts. Si la cible lit seulement les pixels et ignore les métadonnées, vérifiez sur un cas avant d’alimenter une chaîne en lot.

Le contrôle demande un nombre en secondes avec un pas d’un dixième. La conversion cherche l’image la plus proche de cet instant, ce qui est presque toujours l’image exacte sur une vidéo à 30 images par seconde mais ne l’est pas sur une vidéo à 23,976 images par seconde, où un pas d’un dixième de seconde peut tomber entre deux images et donner l’une ou l’autre.

Pour un usage en archive cela n’a pas d’importance, parce que l’instant d’intérêt est presque toujours une scène à la seconde près et qu’une image de différence est invisible. Pour un travail d’incrustation ou de référence, l’instant exact doit être calculé à partir de la cadence : instant en secondes multiplié par la cadence, arrondi à l’entier le plus proche, et c’est cette image-là qui est extraite.

Le bloc EXIF qui pourrait porter le modèle d’appareil, la date, les coordonnées GPS et les réglages d’exposition reste dans le MOV. Le TIFF qui sort est techniquement propre : pas d’EXIF, pas de GPS, pas de profil ICC. Cette absence est cohérente avec ce que produit le reste de la chaîne d’écriture d’images : un décodage vers les pixels puis un ré-encodage ne transporte rien, parce que rien n’est prévu pour le faire.

L’information qui accompagnait l’image n’est pas perdue pour autant : elle est dans le MOV, qui reste la source canonique. Un flux d’archive typique garde le MOV original, le TIFF dérivé pour consultation, et un petit side-car JSON qui porte les métadonnées utiles. C’est un choix d’organisation à faire avant d’alimenter la chaîne, parce que le TIFF seul ne dit pas d’où il vient.

Une valeur au-delà de la durée de la vidéo produit une erreur qui nomme la durée réelle : « le fichier ne dure que 14,3 secondes ». Une valeur négative est refusée, et la valeur 0 produit la première image, qui n’est pas toujours représentative — un clip de téléphone commence par une main qui s’écarte du déclencheur et une demi-seconde de la mauvaise chose à l’image.

L’astuce classique est de prévisualiser la vidéo dans n’importe quel lecteur et de noter l’instant exact, plutôt que d’estimer. Pour une scène à 3,7 secondes, le résultat sera l’image à 3,7 — pas celle à 3,8 ni celle à 3,6. L’instant se déduit aussi du timecode si le MOV en porte un, et c’est plus précis que la barre de progression d’un lecteur.

La conversion lit votre MOV, choisit l’image, l’encode et la propose au téléchargement. Aucune requête ne porte le fichier, parce que le décodeur et l’encodeur sont chargés dans l’onglet et tournent dans votre propre processus. Les images d’archive n’ont pas de secret, mais c’est une bonne discipline de savoir que le fichier ne quitte pas l’appareil sur lequel il se trouve déjà.

Pour un MOV qui contient une scène sensible — un tournage sous embargo, un entretien préalable, un document d’identification dans un film de famille — la conversion locale évite la copie sur l’infrastructure d’un tiers. L’onglet réseau des outils de développement est le test d’acceptation, et l’absence de requête sortante pendant la conversion en est la confirmation.

Un MOV corrompu, un MOV issu d’un éditeur qui a réécrit les métadonnées sans respecter la spec, un MOV dont l’index est cassé par une écriture interrompue : tous ces cas finissent en erreur lisible, avec un message qui dit où le décodeur s’est arrêté. La conversion ne devine pas et ne produit pas une image par défaut, ce qui serait pire qu’une erreur franche.

Pour un MOV produit par un téléphone ou une caméra, ces cas sont rares, parce que le matériel respecte la spec. Pour un MOV retravaillé dans un éditeur non linéaire, un index cassé est un incident classique, et le message d’erreur est l’indice à donner à l’auteur du fichier pour qu’il ré-exporte depuis sa timeline plutôt que depuis son dossier de rendu. Le MOV qui ne se lit pas est un problème en amont, et le masquer produirait une image silencieusement fausse.