Comprendre le format Raw - Deuxième partie

[NdLR : je vous propose une introduction au format Raw extraite (et légèrement adaptée pour le web) du début du deuxième chapitre de mon livre Le format Raw : développement et flux de production, paru aux Éditions Dunod. Cette introduction est découpée en trois parties et dotée de liens de circulation des unes vers les autres. Voici la deuxième partie, intitulée dans le livre Comprendre le format Raw.]

Dans la première partie, nous avons évoqué les différents processus, de nature essentiellement électronique, qui aboutissent au fichier Raw tel que l’appareil l’enregistre sur la carte mémoire. Il ne s’agit pas de données brutes au strict sens du terme, car le signal a subi plusieurs traitements de réduction du bruit avant et après la conversion analogique/numérique. Disons que le Raw contient des données aussi brutes que possible, dont il tire son nom (raw = brut en anglais).
Examinons à présent le contenu de ce fichier et les méthodes qui permettent de le convertir en image de type bitmap. En direction des photographes encore hésitants sur l’adoption du format Raw et qui liraient cet article pour se convaincre définitivement de ses bienfaits, je propose ma vision du match «Raw contre Jpeg» dans la troisième partie.

Si le Raw est d’un point de vue technique un format d’image, il n’est pas encore une image au sens bitmap du terme dans la mesure où il doit être interprété pour être visualisé. Il est donc en réalité une infinité d’images en puissance. C’est sur cela que se fondent l’analogie entre le Raw et le négatif numérique, et l’adoption du terme de développement pour désigner le processus d’interprétation et de transformation en format d’image classique.
Quelle que soit la nature d’un fichier informatique (texte, son, image, etc.), il est toujours codé en langage binaire. L’ordinateur doit le décoder afin que vous puissiez le lire, l’écouter ou le visionner. Le Jpeg est dans ce cas : il ne nécessite rien d’autre qu’un décodage binaire pour être transformé en image affichable. L’erreur serait de croire que le Raw est juste un fichier codé de manière un peu plus complexe, que seuls quelques logiciels seraient capables de décoder et d’afficher en tant qu’image.
Nous l’avons vu, le Raw est pour l’essentiel un enregistrement brut de la lumière reçue par le capteur. De nombreux paramètres majeurs caractérisant une image ne sont pas spécifiés et relèvent de l’interprétation : luminosité, contraste, balance des blancs, calage de la colorimétrie et de la dynamique, etc. Tous ces ingrédients doivent être injectés au Raw pour le transformer en image. Fabriquer une image affichable à partir d’un Raw est donc fondamentalement différent d’un simple décodage de bits.
Quand un logiciel ou une simple visionneuse est capable d’afficher un Raw, c’est qu’elle a procédé à sa conversion en lui fournissant tous les paramétrages nécessaires. Ce n’est donc pas le Raw qui est affiché, mais l’une des interprétations de ce Raw parmi une infinité. Pour cette raison, aucun logiciel ne vous proposera la même image par défaut, ce qui est la cause de bien des interrogations tant nous sommes habitués à ce qu’une image s’affiche partout de la même manière (pour peu qu’elle intègre un profil de couleur).
On peut légitimement se demander ce que sont devenus tous les paramétrages du boîtier soigneusement pensés puis programmés : balance des blancs, contraste, saturation, netteté, modes Scène, etc. La réponse n’est pas simple, car elle dépend du logiciel utilisé pour traiter le Raw. Seuls les logiciels propriétaires sont en mesure de comprendre ces réglages et de les prendre en compte, car leurs algorithmes sont apparentés à ceux du processeur du boîtier (ils sont le plus souvent capables de fabriquer le même Jpeg que celui que le boîtier aurait produit). Pour les logiciels indépendants, le réglage « +1 » en saturation – pour citer un exemple – n’a pas de sens a priori. Ils ne sauront pas à quoi cela correspond pour leurs propres algorithmes. Seul l’univers logiciel du constructeur est à même de comprendre les instructions en provenance du boîtier et de les appliquer.
Cela peut occasionner de mauvaises surprises lorsque l’affichage par défaut d’un Raw dans un logiciel indépendant est très différent de celui affiché sur l’écran de l’appareil sitôt après la prise de vue. Il ne peut pourtant en être autrement, mais c’est là l’une des causes de méfiance envers le format Raw.

L’interprétation proposée par un logiciel propriétaire n’est pas nécessairement meilleure que celle d’un autre logiciel. Aucun algorithme ne peut prétendre reproduire la vérité, et il faut également abandonner l’idée que le Jpeg produit par le boîtier en est plus proche que les autres. Bien que très répandue, elle est également fausse. En argentique, une même prise de vue pouvait donner des résultats très différents selon le type de film utilisé et selon ses modalités de développement. Il en va de même en numérique. En revanche, l’utilisateur peut être attaché aux choix colorimétriques de son constructeur, ce qui le portera alors vers le logiciel livré avec son boîtier, même si les éditeurs indépendants s’efforcent d’en reproduire le rendu par défaut.

Nous avons vu dans la partie précédente qu’avec la technologie de filtrage par une matrice de Bayer, chaque couche RVB est enregistrée de manière incomplète. La conversion du Raw en image passe par une phase dite de dématriçage destinée à reconstituer l’information manquante. Cette phase est d’une importance capitale, car la précision des couleurs et la finesse des détails de l’image finale en dépendent. Les algorithmes utilisés sont d’une grande complexité et constituent une bonne part des différences qualitatives entre les logiciels.

Pour prendre la mesure de la difficulté de l’opération de dématriçage, imaginez que la scène photographiée est un damier noir et blanc dont la forme et le nombre de cases s’ajustent très exactement à la répartition des pixels du capteur. La lumière des cases blanches arrive sur les pixels recouverts de filtres verts et la « non-lumière » des cases noires sur les pixels recouverts de filtres rouges et bleus. Le capteur va donc enregistrer des valeurs maximales aux emplacements des pixels verts qui auront reçu la lumière blanche et... pas le moindre photon sur les pixels rouges et bleus. Le dématriceur, qu’il s’agisse du processeur du boîtier ou d’un logiciel, va être tenté de conclure que les valeurs de la couche verte sont uniformément maximales, et que celles des couches rouges et bleues sont uniformément nulles car rien ne lui permet d’envisager une autre solution. Finalement, il va conclure que le damier noir et blanc est uniformément vert ! Ce cas est bien sûr caricatural, mais il permet de mesurer la difficulté de l’entreprise.

Une autre étape importante de la conversion d’un Raw est le redressement de la réponse tonale du capteur, car celui-ci fonctionne différemment de la vision humaine. Pour le capteur, l’intensité lumineuse est proportionnelle au nombre de photons reçus. La réponse tonale est donc linéaire, représentée par un gamma = 1. Celle de l’œil est différente, et possède un gamma valant approximativement 2,2.

Lorsque l’intensité de la lumière est doublée, notre œil procède à une compensation automatique qui réduit la perception d’accroissement de la luminosité (et inversement, notre œil s’adapte à une baisse de luminosité, que nous percevons moins forte qu’en réalité). C’est particulièrement vrai aux extrêmes, tandis que la réponse de l’œil est plus proportionnelle lorsque l’éclairement est modéré. La réponse de l’œil est donc proche de celle du film argentique, qui présente une courbe sensitométrique aplatie aux extrêmes et quasi linéaire au centre.

Sur les reflex, les bridges et les compacts experts, le Raw est codé sur 12 ou 14 bits. Cela signifie qu’il possède 16 ou 64 fois plus de nuances qu’une image bitmap codée en 8 bits, comme le Jpeg. Si pour une visualisation sur écran ou un tirage sur papier les 8 bits du Jpeg suffisent, ce n’est plus le cas lorsque des retouches doivent être réalisées. La faiblesse de la profondeur de codage génère des artefacts qui se traduisent par des trous dans l’histogramme. La compression aggrave le problème, car si les informations détruites l’ont été de manière intelligente afin que cela ne soit pas perceptible en affichage ou en impression, elles font défaut quand une retouche un peu appuyée modifie l’image.

Cela étant, seule la profondeur de codage nous intéresse ici. Pour éviter le problème lié à la compression dans l’illustration ci-dessus, j'ai exporté un Raw sans modification en TIFF 8 bits et en TIFF 16 bits. J'ai appliqué à ces deux images identiques un renforcement du contraste à l’aide de la Courbe des tonalités, puis une légère augmentation de la luminosité. On constate qu’à l’issue du traitement, l’histogramme issu du TIFF 8 bits présente une forme de peigne, découvrant les pertes d’informations dans l’image. L’histogramme du TIFF 16 bits est resté parfaitement régulier grâce à sa profondeur de codage plus importante.

À suivre...

Lire la première partie et la troisième partie

Ajouter un Commentaire

Nom (obligatoire)

Adresse email (obligatoire)

Url de votre site Web ou Blog

Titre

     Recevoir une notification par email lorsqu’une réponse est postée

Rafraîchir

Enregistrer

Annuler