Récupérer la plage dynamique, prise 2

De l’eau a coulé depuis mon précédent article sur la plage dynamique.

Depuis 2 semaines, j’ai appris à programmer en C, incluant l’OpenCL et les instructions SSE2. J’ai travaillé à temps plein pour comprendre comment darktable marchait, à l’intérieur, et vous/me/nous développer deux nouveaux modes pour des modules déjà existants, qui vont grandement simplifier la retouche et donner de meilleurs résultats. Le nouveau tutoriel aura passablement moins d’étapes.

1. Récupérer le contraste

Vous vous souvenez comme on a superposé les modules « correction du profil d’entrée », « courbes de base » et l’exposition ? Oubliez tout ça.

Dans le module « correction du profil d’entrée », j’ai ajouté un nouveau mode : logarithmique. Ce que fait cet algorithme est mathématiquement équivalent aux profils neutres N-Log et S-Log qui sont utilisés dans les encodeurs vidéo des réflexs modernes afin de préserver tous les détails dans les basses lumières. Ici, on va s’en servir comme de compression de la plage dynamique :

Notez que l’interface n’est pas encore traduite et que, n’en déplaise à certains, on programme en anglais. La première étape consiste à régler le gris moyen de la scène (input middle grey). Vous êtes feignant ? Moi aussi, c’est pouquoi vous pouvez simplement utiliser la pipette pour sélectionner la tonalité correspondante. Celle-ce sera ensuite redirigée vers le milieu de l’histogramme par l’algorithme. Si vous sélectionnez toute l’image, c’est la luminosité moyenne qui est retenue.

Ensuite, il faut régler l’intensité du noir (output black exposure), en indice de lumination (EV en anglais) à partir du point gris (qui est considéré à 0 EV). Idem, ça se fait en 2 secondes grâce à la pipette, en allant choisir la zone la plus sombre de l’image. Ici, je mets le noir à 4.18 EV à gauche du gris.

Dernière étape, la plage dynamique (dynamic range). Si vous sélectionnez toute l’image avec la pipette, il va simplement pendre la luminosité maximale et considérer que ce sera l’extrémité droite de la plage dynamique.

Et paf ! L’histogramme est à peu près centré, rien n’est brûlé. Il reste le buisson, derrière, qui est un peu bouché. Il suffit de le déboucher en diminuant le point noir dans le module exposition :

Là, vous allez me dire « c’est fade et désaturé ». Oui, mais c’est une base de travail. Et c’est là qu’entre en jeu mon deuxième module.

2. La couleur

La balance couleur a un nouveau mode, « slope – offset – power ». Ce mode est standard et respecte la norme de l’Association Américaine des Cinéastes. Comme tout standard, son objectif est de pouvoir échanger des réglages et des paramètres d’un logiciel à l’autre. Blender et la plupart des logiciels d’édition vidéo en sont déjà munis. Ce mode s’ajoute au « lift – gamma – gain » qui travaille dans un espace sRGB corrigé en gamma, ce qui pose plein de problèmes et de limites sur lesquelles je ne vais pas m’étendre. Je n’ai jamais eu de bon résultat avec ce module. Ici, on travaille dans l’espace Prophoto RGB linéaire.

On commence par ajouter un peu de saturation sur le master :

Ensuite, on va rajouter du contraste. D’abord, on va choisir le pivot (fulcrum) qui est la tonalité de gris qui n’est pas affectée par l’addition de contraste. Au dessus de cette tonalité, on ajoute plus de lumière, en dessous, on en retire. Encore une fois, il y a une pipette. On va choisir la tonalité du visage, puisque c’est le sujet de la photo :

Pas mal, non ? Beaucoup de gens s’arrêteront là. Mais on peut aller plus loin, et se pencher sur la gradation de teinte. La gradation, en anglais color-grading, est une opération qui consiste à ajuster les couleurs séparément pour, soit supprimer sélectivement les dominantes, soit en rajouter pour donner une ambiance à la photo (au cinéma, on met le méchant en vert, la pinup en magenta, la maman en orangé, et le psychopathe en bleu). Ici, je trouve qu’on manque de magenta et que le visage est trop vert.

Attention, les niveaux doivent se régler dans un ordre précis pour avoir un bon résultat : on règle d’abord le slope, ensuite l’offset, puis en dernier, le power (qui est l’équivalent du gamma). J’ai été sympa, si vous ne vous souvenez plus de l’ordre, il est rappelé dans le nom du mode (slope / offset / power) :

Là dessus, un petit coup de courbes des tonalités, pour remettre un petit boost de contraste dans l’espace Lab, zones de couleurs pour la teinte, contraste local, (similaire à ce que j’ai montré dans mon précédent article), et voilà :

Pour comparaison, la version avec la méthode précédente :

3. Bénéfices :

Premièrement, en terme de workflow, c’est très rapide, tout est automatisé au maximum avec des pipettes qui mesurent ce que vous avez besoin sans avoir à gratter les curseurs pendant des heures. C’est rapide, à condition de suivre la méthode dans laquelle ça a été pensé. Le module de correction du profil d’entrée se voit ajouter les modes de fusion classiques des autres modules, ce qui permet aussi d’utiliser la fusion paramétrique pour plus de souplesse.

Ensuite, le résultat est largement meilleur, en terme de luminosité, de rendu général, de couleur etc. On a ensuite un contrôle bien plus fin sur la couleur, ce qui rend – enfin ! – la retouche de couleur agréable et professionnelle sous darktable. J’attendais ça depuis longtemps.

Pour finir, j’ai codé des versions OpenCL de ces deux modules pour que ça soit rapide. Le code C de base est optimisé aussi, le tout est assez performant en terme de calcul.

4. Limites

La balance des couleurs  a toujours ces affreux curseurs RGB, quand la totalité des logiciels qui implémentent cette approche utilisent des roues chromatiques, beaucoup plus simples à contrôler. Le code pour les roues chromatiques est inclus, mais commenté, dans le code source du module, il semble qu’on ne soit pas très loin de le faire marcher, mais je n’ai pas eu de nouvelles du développeur précédent.

5. Et maintentant ?

Les fonctionnalités ont été soumises aux développeurs, et sont en attente de révision. Un d’entre eux s’est déjà montré hostile au profil logarithmique dans ce module précisément (pas en général). Rien ne garantit que ça soit un jour intégré au code source, mais si vous vouler les tester, vous pouvez compiler ma branche.

Attention, il se peut que le code change dans un futur proche, et que vos retouches soient alors invalides. Sauvegardez vos bases de données et travaillez sur des copies virtuelles de vos photos.

Mais tous les tests et les retours sont les bienvenus.

Mise à jour : j’ai commencé à rééditer des photos de cet été avec ces modules

Sortie de darktable (ancienne version ) + retouche Photoshop
Sortie directe de darktable (nouvelle version avec nouveaux modules)
sortie de darktable (ancienne version)
sortie de darktable (nouvelle version avec nouveaux modules)
sortie de darktable (version précédente)
sortie de darktable (nouvelle version avec nouveaux modules)

Auteur : Aurélien PIERRE

Photographe portraitiste à Montréal. Spécialiste en calcul, modélisation et simulation numérique pour le traitement d'image (débruitage, défloutage) et le génie thermique.

21 réflexions sur « Récupérer la plage dynamique, prise 2 »

  1. Je crois que l’on ne peut que se réjouir de voir “la vie du code” de darktable s’enrichir ainsi grâce à de nouveaux esprits. Je ne sais pas comment fonctionne en interne l’organisation du développement de darktable, mais c’est à espérer que les développeurs regardent d’un œil bienveillant les propositions d’Aurélien. En tout cas merci à Aurélien pour son engagement dans cette aventure.

  2. Alors là, chapeau !
    Je suis admiratif tant du résultat que du travail accompli pour y arriver (et en anglais en plus, là, ça me terrasse).
    Merci. En espérant que ce soit pris en compte pour une prochaine version. Mais il faut garder sous le coude le déroulé des opérations …

  3. Un super boulot que nous met à disposition Aurélien, j’espère qu’il sera dans la hotte du Père Noël. J’ai compilé les 2 scripts. Pour le module “correction du profil d’entrée”, il est impressionnant déjà seul et je l’ai essayé sur des photos que je destinais à la poubelle (mais je ne jette aucune photo) et en moins d’une minute, j’ai récupéré une photo plus qu’acceptable notamment sur des photos de spectacle ou de l’intérieur d’église pour avoir une bonne définition dans les vitraux sans passer par les prises HDR.
    Je ne comprend pas bien la position d’autres développeurs car Aurélien a permis soit d’utiliser ces 2 modules comme on le connait ou alors on choisit ce qu’il a fait pour ces 2 modules un peu comme dans le module “contraste local”.
    Un très grand merci Aurélien pour ce partage magique. Je dois dire que je ne suis jamais aussi arrivé à quelque chose d’acceptable avec la balance des couleurs.

    1. le souci que Roman Lebedev a avec mon code est dû au fait que je coupe les valeurs inférieures ou égales à zéro (le logarithme n’est pas défini à partir de zéro), ce qui pose des problèmes de compatibilité car les modules dt sont censés pouvoir prendre toutes les valeurs en entrée. Ceci dit, le module dans sa version actuelle calcule la racine n-ième de l’entrée (un bonne vieille correction gamma, quoi), qui n’est pas non plus définie pour des entrées négatives.

      Je pense avoir finalement réussi à le convaincre que, gamma ou logarithme, le problème est le même : on ne peut pas calculer pour des pixels qui ont des valeurs négatives ou nulles dans ce module. À suivre, mais je ne lâcherai pas le morceau avant d’avoir eu raison. Qui s’y frotte s’y pique.

  4. effectivement, c’est fichtrement que dis-je mes yeux n’en reviennent pas !!
    Quelle différence entre les deux méthode c’est fou.
    Mais quel est donc ce démon outre-atlantique qui nous pond des trucs aussi ahurissant que stupéfiants !!
    alors là Aurélien chapeau bas pour ce travail et le résultat obtenu, je ne comprend pas pourquoi on peut être contre ce genre d’avancée sur ce logiciel, sûrement encore une querelle de mathématicien qui nous dépasse nous pauvre humain ignares 😉 .
    Il ne nous reste plus qu’à apprendre à compiler effectivement
    Encore une fois bravo pour ton travail et merci de partager tes recherches.

    1. On voit bien la perte de l’espèce de voile terne grisâtre/verdâtre (du moins comme cela apparaît sur mon écran).
      Bon: Wiki-Ubuntu==> Apprentissage compilation==> Exécution=(prise de tête?)=>Râââh super!

      1. Ce que je suppose qu’il se passe :

        les profils ICC de correction des couleurs d’entrée sont effectués sur des mires d’étalonnages (IT8, Color Checkr, etc.) dont les valeurs de luminance vont de 18 % à 96 % (en Lab), ça fait 2.5 EV de plage dynamique. Entre 0 et 18 % de luminance, le profil ICC extrapole les corrections de couleur, c’est à dire qu’il prolonge le comportement mathématique observé aux valeurs supérieures, mais avec une erreur (inconnue).

        En studio, on a habituellement 6-8 EV de plage dynamique. En paysage, 10-14 EV. La conséquence, c’est que 75-90 % des pixels ont une valeur inférieure à 18 %, c’est à dire sont hors de domaine où le profil ICC est valide. Du coup, ces couleurs sont mal corrigées.

        Avec le profil logarithmique, on ajuste les luminances de façon à centrer l’histogramme sur 50 % de luminance. De cette façon, 60 à 80 % des pixels sont remappés dans le domaine de validité du profil ICC avant la correction de couleur.

        C’est ce qui pourrait expliquer qu’on ait des couleurs plus saturées et vibrantes avec la correction logarithmique. À confirmer.

        Ensuite, après la correction des couleurs, il faut bien évidement remettre du contraste, sinon c’est très fade.

  5. Je voudrais bien profiter aussi des avancés proposées par Aurélien, mais…
    Si quelqu’un peut m’expliquer comment on compile… je suis sous Linux Mageia 6 sur un PC fixe et Windows 10 sur mon PC portable
    Merci d’avance

    1. @Philippe, viens faire un tour sur Telegram pour qu’on puisse t’aider, jpg54 a créé un groupe de discussion sur la compilation de darktable 😉

  6. Bonjour et merci pour votre excellent travail…

    Première fois que je me laisse tenter par une compilation…

    Mais je bloque là!!??

    Merci de vos possible lumière

    CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
    Could NOT find RSVG2 (missing: RSVG2_LIBRARY RSVG2_INCLUDE_DIR)
    Call Stack (most recent call first):
    /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
    cmake/modules/FindRsvg2.cmake:27 (find_package_handle_standard_args)
    src/CMakeLists.txt:302 (find_package)

    — Configuring incomplete, errors occurred!

    LinuxMint 18.3 Sylvia 64-bit-Noyau Linux 4.13.0-43-generic x86_64-AMD Athlon(tm) X4 750K Quad Core Processor × 4

      1. Ok… mais c’est que du bonheur… chaque fois que je relance la compil il manque encore un truc! et là je bloque après l’installation de LCMS2.
        ——————————————————————————————————–
        Réponse de la console de compilation :
        CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
        Could NOT find LCMS2 (missing: LCMS2_LIBRARY LCMS2_INCLUDE_DIR)
        Call Stack (most recent call first):
        /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
        cmake/modules/FindLCMS2.cmake:35 (find_package_handle_standard_args)
        src/CMakeLists.txt:302 (find_package)

        — Configuring incomplete, errors occurred!
        —————————————————————————-
        j’essaie d’installer liblcms2-dev et j’ai cette réponse : “à désinstaller Gimp et tout un tas de truc inhérent à Gimp!!! et propose de réinstaller vers une version antérieur liblcms2-2” j’y perds mon latin… 😉

  7. Bravo Aurélien! Le résultat est bluffant. Les écarts dans la plage dynamique sont en effet un gros problème et je ne parle même pas des vieux objos qui, mal traités niveau de la surface de leurs lentilles compliquent encore le truc. J’en appelle souvent au concours du curseur des noirs mais pouvoir caler l’histo là ou on le désire à partir de butées maîtrisées c’est le rêve…
    Il n’y a plus qu’à espérer son implémentation dans une future version.
    Cool!

    1. Je ne crois pas que ça a été fait par un francophone. En anglais, tu peux essayer de voir : https://discuss.pixls.us/t/darktable-windows-build-help-needed/8335
      Maintenant, @RawFiner a partagé une méthode qui permet de compiler darktable dans docker qui existe sous WinDows. Il pense qu’il va y avoir des problèmes et je n’ai pas encore essayé.
      Je pense quand même que le plus simple serait que tu installes une distribution Linux en dual-boot avec WinDows.
      Vincent, j’ai créé un groupe pour la compilation de darktable sur telegram, si tu veux je peux t’y inviter si tu t’inscris sur celui darktable.fr : https://darktable.fr/2017/02/groupe-telegram-darktable-fr/

      1. Merci Jpg, je tenterai peut-etre un linux virtualisé dans windows à l’occasion, et une compile linux… si je trouve le temps, malheureusement pas tout de suite.
        Bonne journée

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.