TZ=Indian/Antananarivo

Ahanements d'octets austraux
Billet classé dans la catégorie : Accueil > Photos > Workflow1

dimanche 17 décembre 2006

[ 15:30 ] Méthode LPMM : introduction

C'est pour la bonne cause, Vola...

Vous imaginez, depuis un mois, je me retrouve avec une quantité industrielle de photos parfois prises dans des conditions assez peu confortables. Ben oui, on ne va quand même pas réveiller bébé avec un flash...

Photo réalisée dans des conditions difficiles

Ça crée pas mal de challenges en matière de classement et de traitement, et du coup me voilà obligé à retomber dans ma geekerie, pour vous parler de la méthode LPMM.

LPMM ? Non, ce n'est pas Liberal Party of Madagascar for Malagasy, mais au choix :

ou comment avoir des photos numériques rapidement, mais en pouvant reprendre la main les jours où l'on se prend pour Sebastiao Sagaldo ou Ramily. Et en plus, sans investir un kopeck supplémentaire en logiciels.


Les appareils ne sont pas tous pareils

Bon, pour commencer, une petite justification de mon goût pour les solutions technologiques un rien exotiques.

Parmi les reproches que je fais à la plupart des appareils numériques, figurent en bonne place le manque d'autonomie (j'ai entendu trop de personnes dire il faut que je rentre, mes batteries sont à plat), la lenteur, et la visée "à bout de bras" qui signale à tout le monde que vous allez prendre une photo et vous promet que cette photo sera vraisemblablement floue.

Il me fallait donc un appareil combinant :

Faute de budget suffisant pour un reflex, la finale s'est joué entre deux appareils permettant de garder un certain contrôle sur les réglages, le Canon Powershot A620 (déjà remplacé par les A630 et A640) et le Fujifilm FinePix E900. L'un est un best-seller, l'autre pas.

Les débats sur hardware.fr, dpreview et Steve's Digicam m'ont fait privilégier le mode RAW, l'affichage en temps réel de l'histogramme et le contrôle de l'exposition au flash du Finepix par rapport à l'écran LCD orientable du Canon.

Je suis raisonnablement content de mon choix, mais ça reste un compromis ; être à Madagascar entraîne des difficultés et des complexes à renouveler ses joujoux aussi vite qu'on le souhaiterait (Petit Papa Noël, tu penses à moi ?) ; ceci n'empêche pas de fantasmer sur un reflex numérique car le petit Finepix a quand même quelques défauts communs à pas mal de compacts :

J'ai quand même fini par assumer jusqu'au bout les deux derniers défauts de l'appareil, puisque je me suis mis à photographier presque exclusivement en RAW (donc enregistrement lent d'énormes fichiers), et en configurant l'appareil pour maintenir l'affichage de l'image prise jusqu'à nouvel appui du déclencheur. Quitte à être condamné à deviner l'instant décisif, autant être en mesure de privilégier la qualité.

Latence, puissance et patiences

Les fichiers RAW font environ 18,3 Mo, à rapprocher des 2,3 Mo typiques en mode 9 megapixels "normal" et des 4,6 Mo d'un 9 megapixels "fin" qui ne mérite pas vraiment son nom. Bonjour l'achat d'une carte d'au moins 1 Go si on veut la qualité maximale et la garde de la pédale du chef !

Ceci étant, un fichier RAW, ce n'est qu'une image latente, pas encore rentrée en contact avec le révélateur. Cette image latente, il faut la développer, dans le cas présent sur son petit ordinateur préféré.

Les logiciels livrés avec l'appareil (Fuji FinePix Viewer et RawConverter LE) pouvant être considérés comme une sympathique aumône destinée à ceux qui auraient enclenché par erreur le mode RAW, il m'a fallu quêter la solution efficace et économiquement supportable. J'ai un peu tout essayé, y compris des possibilités assez peu mises en avant comme GraphicConverter et VueScan (pas si ridicule que cela), pour finalement recommander deux solutions :

Mais par leur approche, pratiquement tous ces logiciels graphiques me semblent en contradiction de ma logique photographique. Mon Mac n'est pas de la première jeunesse (euphémisme...), et tous ces logiciels imposent un temps agaçant avant d'afficher le moindre aperçu. Et puis, à nous donner tellement d'options, on nous impose le sentiment d'avoir à revenir systématiquement vers le fichier raw d'origine en cas d'erreur, de changement d'humeur ou de destination un peu différente de l'image (web, impression couleur, tirage sur mini-lab, noir et blanc ou couleur...).

L'apport positif d'un négatif (qui ne l'est pas)

Au bon vieux temps de l'argentique, on développait un film en chambre noire, en suivant les indications du fabricant. On savait bien de toute façon que le film renfermait plus d'information que ne pouvait en restituer naturellement le papier, et qu'il faudrait choisir le contraste de celui-ci, laisser monter ou retenir l'image en la masquant, pour retrouver sur le tirage ce que nous avions vu. Le développement était un traitement purement scientifique, sans remords possibles ; l'heure des choix artistiques subjectifs sonnait au moment du tirage.

Alors, au temps du numérique, on devrait pouvoir rentrer à la maison, lancer avant le dîner une ou deux commandes et seulement après, sans avoir à revenir au RAW, choisir entre obtenir vite fait 60 fichiers destinés au tirage et 30 fichiers à expédier par mail à Tonton et Tantine, ou couper les cheveux en quatre et fignoler un tirage aux petits oignons.

Cela suppose de stocker des images sous un format contenant potentiellement autant d'information que le format RAW, mais plus directement lisible, afin de faciliter la lecture et le choix des traitements ultérieurs.

Ce format doit coder chaque couleur primaire au minimum sous 16 bits pour permettre ultérieurement de rééquilibrer/affiner l'exposition et le contraste sans perdre de l'information.

Ce qui m'a amené à regarder de plus près dcraw, outil open source qui est le petit cousin (tous les ténors s'en sont au moins inspiré...) de bien de logiciels de traitements de fichiers RAW .

dcraw sait générer un fichier 16 bits, mais en mode linéaire, c'est à dire avec un Gamma de 1, alors que notre oeil est habitué à évaluer des images avec un contraste "exagéré" (Gamma de 1,8 sur les écrans de Mac, 2,2 sur les écrans de PC étalonnés, 2,5 sur les écrans de PC non étalonnés). Le fichier généré par dcraw apparait "trop sombre", illisible.

Photo réalisée dans des conditions difficiles

Deux options existent alors :

C'est cette deuxième option qui conserve l'information intrinsèque stockée dans le fichier RAW que j'ai privilégié.

Problème : où trouver des profils adaptés à un gamma de 1, permettant d'obtenir une image interprétable sur l'écran ? Ça nous éloigne évidemment fortement des profils "classiques" sRGB et Adobe RGB 1998 qui correspondent à des gammas de 2,2.

J'ai cru trouver mon bonheur sur le site de Raw Developer. Mais de toute évidence, les photos traitées avec le profil Fuji Finepix E900 trouvé sur ce site, si elles ont un contraste et une luminosité satisfaisantes, apparaissent bien trop rouges. D'ailleurs examiné avec l'Utilitaire ColorSync d'Apple, ledit profil apparait aberrant, avec un espace de couleur couvert allant au delà du spectre visible par l'oeil humain...

En fait, j'ai obtenu un profil très différent et bien plus satisfaisant en faisant un export direct à partir de Raw Developer (Onglet "In", "Create/edit custom" input profile, choisir en haut du dialogue le réglage "Camera default", et ensuite "Save Profile to file...").

L'examen sous Colorsync du profil ainsi obtenu montre que l'espace de couleur est assez proche de celui du profil sRGB, mais les courbes de réponses aux différents tons correspondent bien à un gamma de 1.

On pourrait se contenter de cet espace pour le post-traitement, mais si l'on veut faire des corrections et conversions de colorimétrie, un espace de travail plus large semble utile. Aussi, je convertis l'image dans un autre profil de gamma 1, l'espace AIM RGB Pro, trouvé sur ce site, où l'on trouvera également un argumentaire pour l'utilisation de tels profils dans le traitement d'images.

Une fois ces transformations colorimétriques appliquées à la sortie de dcraw, qui est ensuite traduite dans un format standard adapté, on obtient un fichier que je considère comme un "quasi-négatif" ; on peut le lire et l'interpréter sans problème, mais il n'est pas vraiment utilisable tel quel, car il mérite encore un certain nombre de corrections et il faut avoir des connaissances en colorimétrie pour l'exploiter.

Petite coquetterie, je complète ce fichier avec la plupart des données EXIF du fichier RAW d'origine (ce n'est pas tant une coquetterie que cela, ces informations peuvent être fort utiles pour le choix du post-traitement).

A suivre : les post-traitements pour des usages courants, les logiciels et scripts utilisés.

Dernière mise à jour le 17/12/2006 22:57
Commentaires du blog hébergés par Disqus


<- Mince, on vote ce dimanche ?
Joseph et la logistique ->
 Accueil |  Humour | Macintosh | Bidouilles | Sélection | Éditeur 

Certains droits protégés par licence Creative Commons , 2006 Barijaona Ramaholimihaso
Réagissez par les liens de commentaires ou par courriel : reactions (arobace) barijaona.com