Correspondance LR => DT , avec tutos à dispo

[valmy]

tu as sûrement raison , je racontes n'importe quoi, mais mes yeux voient ce que je vois :



Quand on pousse DT à +3 et LR à +5, je suis conscient que mes blancs sont cramés (j'ai poussé au max pour voir jusqu'où ça irait) mais avec mon appareil, quand je pousse le correcteur d'expo à fond ça ressemble plus au résultat de LR que de DT. le dégradé du blanc cramé à ce qui reste de couleur reste propre .

Ce que tu vois dans darktable, c'est un écrêtage pur et simple des canaux saturés (> 100 %), avec le canal rouge qui sature avant les deux autres, au niveau du profil de couleur de sortie (d'ailleurs : est-ce que LittleCMS2 est actif ? Normalement, il devrait gérer l'écrêtage mieux que ça). Ça se passe mal parce qu'aucune stratégie intelligente n'a été sélectionnée pour remapper/compresser les hautes lumières dans l'intervalle [0 ; 100] % (qui est l'intervalle de travail de l'écran), donc on coupe à 100% et c'est moche. C'est normal, connu, prévisible, planifié, tout va bien. Il faut ajouter un deuxième niveau de correction, par exemple utiliser filmique, qui s'intercale juste avant le profil de couleur de sortie, et qui est fait juste pour remapper ] 0 ; + infini[ (intervalle de l'énergie lumineuse de la scène) vers [0 ; 100] %  (intervalle de travail de l'écran) de façon intelligente et contrôlée.

Je suis en train de t'expliquer que LR ne crame pas les blancs puisqu'il ne se contente pas de faire une correction d'exposition mais rajoute des bricolages additionnels non documentés, donc il ne fait pas ce qu'on lui demande et qui est écrit sur le réglage. Le problème de ce genre de magie, c'est que ça peut te péter à la tronche de façon subtile et vicieuse. Comment tu sais à partir de quelle valeur LR comprime les blancs (et donc casse la linéarité des couleurs) ? Comment tu sais s'il les comprime avant ou après les retouches de couleur ? (c'est super important pour garder les teintes intactes, il faut garder le pixelpipe linéaire le plus longtemps possible). Tu ne sais pas… Et si tu veux éditer du HDR avec des valeurs supérieures à 100 % (pour l'enregistrer en 32 bits flottants et le retravailler ailleurs), tu ne peux pas : LR te force à bosser entre [0 ; 100] % sans rien te demander, ce qui est un workflow « display-referred » qui a 30 ans d'âge,  qui ne s'adapte pas au HDR, et qui fonctionne au prix de tas de bricolages immondes. Soit, en première approche, ça a l'air plus facile, mais ça n'est pas propre et, au moment où ça va péter, il n'y a aucun débrayage manuel dans le bazar.

darktable fait ces choses (en tout cas, ici) correctement : il fait une correction d'exposition qui ne corrige que l'exposition, il applique la compression des blancs à la demande de l'utilisateur, en lui laissant le choix de la valeur à partir de laquelle on comprime, et en affichant à quel endroit du pipe la correction est faite (et, dans la prochaine version, en te permettant de réordonner les filtres), et globalement, il documente ce qui est fait sur tes pixels.

Y a pas besoin d'avoir fait BAC+5 pour comprendre une courbe de densitométrie de film, et voir que le numérique ne se comporte pas du tout pareil, et comprendre l'intérêt d'appliquer une transformation de type filmique avant d'envoyer les pixels à l'écran. Explication à 15min43 dans cette vidéo : https://darktable.fr/2019/06/comment-lin...tographie/

Ce qui peut paraître étrange au non-développeur que je suis c'est de savoir Adobe en possession d'un bataillon d'ingénieurs à disposition pour développer LR vu ses revenus de location et il ne fait pas ce que tu fais tout seul sous le capot de DT pour certains traitements. C'est pourtant pas les moyens financiers et humains qui lui manque ...