Je suis allé au Libre Graphics Meeting, début juin, à Saarbruecken, pour rencontrer les développeurs de darktable, en particulier Johannes Hanika, son fondateur, et Tobias Ellinghaus, son deuxième plus gros contributeur. On a discuté de l’avenir de darktable, des orientations à donner et des choses à corriger. On a, aussi, discuté des utilisateurs, de leurs attentes, de leurs priorités.

Et on a un problème :

Les attentes des utilisateurs sont de plus en plus irréconciliables avec l’évolution des techniques d’imagerie numérique.

Les attentes des utilisateurs, ce sont ces préjugés, ces hypothèses fondamentales, sur ce qu’est une image et ce que devrait être sa retouche. Elles viennent, en grande partie, de l’héritage des logiciels Adobe, qui héritent eux-même de la photo argentique. Or la photo a radicalement changé depuis l’ère argentique, en terme de technique, de reconstruction du signal et d’hypothèses de base.

Les vieux de la vieille vous le diront tous : tout se joue à la prise de vue. Beaucoup vont donc chercher l’exposition parfaite dans l’appareil. Mais qu’est-ce qu’une exposition parfaite ? Rappelons que le film couleur a environ 5-6 EV de plage dynamique, et le film N&B argentique peut monter à plus de 12 EV, mais dans tous les cas, le papier n’aura jamais plus que 5-7 EV de plague dynamique (soit un D-max de 1,5-2,3). Dans ce contexte, on sacrifie les très hautes et très basses lumières, on place les tons moyens au centre de l’histogramme, et paf ! la photo est « parfaitement » exposée sans effort. Sauf pour ceux qui pratiquaient le dodging & burning sous l’agrandisseur, afin de récupérer le contraste sélectivement, mais ça demandait déjà une certaine expertise. Tout le pipeline graphique (normes ICC) a été construit dans les années 1980-90 pour des photos de 8 EV et moins, où l’on pose l’hypothèse que le gris moyen se trouve à 18 % de luminance, le blanc diffus (mat, à 20 % de réflectance) à 100 % de luminance, et le noir à 0 %, par définition (rappel : le noir absolu n’existe pas sur Terre). 100 % étant le blanc de l’écran, dont la plage dynamique est d’environ 8 EV aussi. C’est la raison pour laquelle beaucoup de logiciels écrêtent tout simplement les valeurs supérieures à 100 % (codé 255 en 8 bits), sans autre forme de procès.

Aujourd’hui, même votre réflex à 250 € a déjà au moins 12 EV de plage dynamique à 100 ISO. C’est 1,5 fois plus que votre écran. Ça veut dire que vous faites de la photo HDR sans le savoir. Ça veut dire, aussi, qu’il faut des moyens « intelligents » de remapper cette grande plage dynamique vers la plage dynamique, plus faible, de l’écran et du papier. « Intelligents » signifiant compresser le contraste global en perdant un minimum de contraste local et sans abîmer la couleur. La conséquence de tout ça, c’est que le 100 % de luminance n’encode plus obligatoirement un blanc diffus, mais peut encoder n’importe quoi (reflets spéculaires, lumière directe du soleil, etc.). De même, 18 % ne représente plus obligatoirement un gris moyen, mais le gris peut parfaitement se trouver entre 2 et 9 % de luminance. Car, pour tirer parti de cette plage dynamique étendue, vous « exposez à droite », c’est à dire que vous sous-exposez pour caler les hautes lumières juste sous le seuil de saturation du capteur, puis vous repoussez les ombres en logiciel, via le mappage de tonalité. Exit, donc, l’écrêtage des valeurs supérieures à 100 % pendant le traitement de l’image. On ne peut plus représenter les valeurs de pixels en % de la luminance écran, on devrait les représenter en terme d’énergie de la lumière sur la scène (entre ]0 ; + infini[).

Ce faisant, vous continuez d’utiliser des logiciels dont le pipeline graphique suppose et attend des valeurs de luminance dans [0 ; 100 %]. Leurs options de fusion paramétrée, les masques etc. affichent des curseurs de 0 à 100 % (ou de 0 à 255, en 8 bits). Et quand vous ouvrez votre fichier raw dans votre éditeur préféré, vous ne comprenez pas pourquoi il est si sombre, beaucoup plus que ce que l’appareil affichait à l’écran. C’est le poids de l’héritage. Car la photo HDR n’est plus WYSIWYG.

On arrive aux limites de l’utilisation aveugle du logiciel.

L’amélioration de la qualité des capteurs et des écrans pardonne de moins en moins les mauvais traitements infligés à la couleur de vos pixels. Toutes les approximations grossières que l’usage a imposé et que l’héritage à rendu « intuitifs » (courbes de tonalités, correction de luminosité sous forme de fonction « gamma », contrôles HSL/HSV, etc.), si elles pardonnaient encore à 8 EV, explosent à 10 EV et plus. Conséquemment, les stratégies de mappage des tonalités et du gamut deviennent de plus en plus complexes, et imposent à l’utilisateur de comprendre ce que « exposition » signifie dans le domaine de la scène réelle (lumière) et dans le domaine de l’écran (valeurs RGB), de même que de comprendre toutes les hypothèses avec lesquelles il travaillait dans le passé, sans le savoir. La stratégie « pousse-bouton », façon Lightroom, dans laquelle on utilise n’importe quel filtre dans n’importe quel ordre n’est plus possible : il faut s’intéresser au pipeline en entier, et à l’ordre dans lequel ses filtres sont appliqués.

Si toutes ces notions (théoriques et techniques) sont généralement intégrées chez les professionnels du cinéma (formations plus pointues, semble-t-il), les professionnels de la photo (et a fortiori les amateurs) ne veulent pas en entendre parler et, pour toute objection, on se prend dans les dents cette métaphore éculée :

« Je n’ai pas besoin de savoir comment fonctionne un moteur pour pouvoir conduire une voiture » – Papy Mougeot.

La seule raison pour laquelle votre grand-mère peut conduire sa voiture sans avoir la moindre idée de ce qui se passe sous le capot, c’est que sa voiture a été spécialement conçue (et bridée) pour ça. Est-ce que votre grand-mère gagne des rallies ? Demandez à un pilote de Formule 1 s’il sait comment fonctionne son moteur. En photo, c’est pareil. On perd en simplicité ce qu’on gagne en contrôle, on perd en contrôle ce qu’on gagne en simplicité. On ne peut pas gagner sur les deux tableaux. Le photographe est l’analogue du pilote, pas celui du conducteur de base coincé dans les embouteillages. Autrement, on parle d’un presse-bouton, piégé pour toujours dans les fonctionnalités user-friendly que le constructeur de l’appareil a prémâché pour lui. Et, je ne sais pas pourquoi, mais les gens semblent s’acharner à ne pas vouloir le comprendre. On a beau vivre à l’ère du high-tech, on n’a toujours pas inventé la magie. Tout se paie.

En terme de conception du logiciel (darktable, en l’occurence), ça commence à poser des problèmes croissants. Quand on résoud des problèmes de plus en plus complexes, fatalement la solution augmente en complexité. Si l’on veut éviter de complexifier la solution, il faut alors renoncer à traiter tous les problèmes et limiter la solution à un ensemble réduit de problèmes classiques, pour lesquels on peut faire des hypothèses réalistes et cacher des paramètres à l’utilisateur. Mais alors, on perd en versatilité et en adaptabilité. Dans darktable, nous somme tiraillés entre offrir une approche « simplifiée » à ceux qui le souhaitent, en sachant qu’on va leur donner de mauvaises habitudes et entériner de mauvais réflexes (« les couleurs sont sursaturées avec la courbe de base » - oui, c’est normal), ou une approche complète et complexe pour ceux qui veulent aller au fond, en sachant qu’on va effrayer les autres (« pourquoi mon image à l’air si fade quand je désactive tous les modules ? »). Pour l’instant, on offre les deux approches, avantage de l’architecture modulaire, mais ceux qui se rendent au niveau avancé ont alors de fortes chances de mixer l’approche simple et l’approche complète/propre (cf. tous ceux qui utilisent filmique avec la courbe de base active), alors qu’elles sont incompatibles et qu’ils n’en savent rien (et ce n’est pas faute de l’écrire dans la documentation…).

La frustration des utilisateurs vient de ce que la solution qu’on leur propose ne correspond pas à leurs attentes. Le problème est que leurs attentes sont de plus en plus irréalistes, en terme de simplicité et « d’intuitivité », par rapport aux défis posés par le HDR, parce que les workflows doivent changer pour supporter correctement des appareils HDR sans passer par des bricolages infâmes (qu’on a passé 30 ans à accumuler). Et pour comprendre ce qui doit changer, il faut déjà comprendre les fondamentaux de la couleur, numérique et psychophysique. Or, trop souvent, la photographie est le produit d’appel des arts graphiques, le truc qu’on choisit par défaut quand on a la flemme d’apprendre à dessiner ou à peindre, ce qui amène un public déjà peu motivé, qu’on perd totalement dès qu’on commence à parler de métamérisme et de bits d’encodage.

Il faut comprendre que l’intuitivité et la simplicité de la plupart des logiciels photo actuels sont aussi la cause des incohérences de couleur qu’on y rencontre, notamment avec les lumières colorées (éclairages de scène, couchers de soleil, bleus saturés qui virent vers le violet, etc.) : leur simplicité s’est faite au prix d’approximations, qui coûtent très cher en qualité dans une utilisation HDR, plus exigeante. Le HDR demande une extrême rigueur dans les mathématiques mises à l’œuvre pour le traitement, et donc des contrôles plus avancés, donc une interface plus chargée et riche en termes techniques précis, de nature à faire fuir le néophyte. Dans ce contexte, viser la simplicité de l’interface a des implications directes sur la qualité du résultat, et viser l’intuitivité n’est plus possible car il faut exposer à l’utilisateur des paramètres qu’on lui a caché pendant des décennies. darktable entre ici en « concurrence » avec des logiciels commerciaux qui cherchent à faire plaisir immédiatement aux utilisateurs, même quand ceux-ci veulent se tirer une balle dans le pied, et même s’ils les desservent à long terme. Logiciels commerciaux qui définissent ensuite les attentes des utilisateurs de darktable. Et c’est ainsi qu’on est prié d’aider les utilisateurs à se tirer dans le pied, parce que X, Y ou Z le fait facilement.

Des nouveautés vraiment cool sont prévues pour darktable. Par exemple, la possibilité de manipuler les pixels dans le domaine spectral, c’est à dire de simuler les photons pour jouer numériquement sur leur longueur d’onde, et obtenir des corrections de couleur beaucoup plus réalistes (en passant par des modèles physiques). Mais ça ne va pas simplifier le logiciel. En revanche, ça va résoudre des problèmes qui sont insolubles en RGB, et qui n’ont de solution rapide dans aucun autre logiciel. Le HDR amène de nouvelles possibilités d’expression, mais aussi de nouveaux problèmes. Ces problèmes sont, en grande partie, liés à des simplifications abusives héritées de la théorie de la couleur développée dans les années 1970, qui a aboutit à la chaîne de couleur ICC dans les années 1980-90. Pour les résoudre, il va falloir dé-simplifier la retouche. Ça veut dire qu’on va être obligé de demander à l’utilisateur un supplément de connaissances et de compétences pour prendre en main cette technologie. Ça veut dire qu’on va demander un effort supplémentaire à l’utilisateur. Autant vous dire qu’on se prépare à se faire engueuler.

Simple ne veut pas toujours dire plus efficace. Intuitif ne veut pas toujours dire plus performant. De plus en plus, vous allez devoir choisir votre camp : chauffeur du dimanche qui oublie de vérifier les angles morts parce que ça fait 40 ans qu’il a son permis et qu’il n’a jamais eu d’accident, ou pilote de course qui connaît ses pneus et son moteur par cœur et qui se sortira de n’importe quelle situation. Car l’une ou l’autre de ces approches induit des choix de conception différents, et qui sont de plus en plus irréconciliables entre eux. Il n’y en a pas une meilleure que l’autre, juste une facile et limitante, une autre difficile et quasi-illimitée, et dans l’absolu, il s’agit juste de faire un choix arbitraire et de s’y tenir, en assumant ses conséquences.