Profils vs duplication de modules

Utilisation de darktable Module Chambre Noire
1

Suite à un problème motivé ici https://darktable.fr/forum/showthread.php?tid=2382 j’ai fini par comprendre (avec l’aide de jpg54 sur Telegram), que mon soucis était assez général, et venait de la manière dont les instances multiples de modules étaient gérées, quand ces modules sont appliqués au moyen de styles.

J’ai produit des exemples simples pour reproduire le problème. J’ai fait un exemple avec des modules exposition, et un autre avec des modules noise-profile. Les fichiers sont ici : https://framadrop.org/r/m1ig_ZPTwI#7brpbv4T8r5PPGC9d/on+FsbIjlwFirQ319DUW6cbD4=

Or donc, sur une photo, en appliquant le style « Exposition > auto moyen Fuji » (resp. « Débruitage > complet »), on applique deux modules d’exposition (resp. réduction du bruit (profil)) et on a dans le pipeline :

et respectivement

A chaque fois, un des modules porte le nom du type de module (« exposition » ou « réduction du bruit (profil) ») , et l’autre se voit affublé d’un suffixe " 1", et se trouve après dans le pipeline.

J’ai maintenant intégré les modules un par un dans des profils séparés :
[list]
[]« Exposition > auto moyen » (resp. « Débruitage > chroma ») pour appliquer à chaque fois le premier module « exposition » tout court (resp. « réduction du bruit (profil) » tout court)
[]« Exposition > compensation Fuji » (resp « Débruitage > luma ») fait pour appliquer spécifiquement le module dupliqué, celui avec un « 1 » à la fin de son nom pour qu’il n’y ait pas de confusion
[/list]
En repartant de zéro (supprimer l’historique dans la table lumineuse) puis en appliquant successivement chaque style, on pourraît espérer arriver à la configuration illustrée ci-dessus, mais on arrive à

et respectivement

En gros, les premiers modules issus de l’application de « Exposition > auto moyen » (resp. « Débruitage > chroma ») ont été supprimés et remplacés par ceux issus de l’application de « Exposition > compensation Fuji » (resp « Débruitage > luma ») bien que ces styles ne mettent pas en oeuvre des modules avec les mêmes noms.

Est-ce qu’il y a un moyen d’employer un style pour ajouter un module du même type qu’un module déjà dans le pipeline, au lieu de remplacer ce dernier ?

Là j’ai simplifié au maximum pour isoler le problème, mais ça peut être pénible et limiter largement le workflow avec des styles un peu plus complexes. Quid par exemple de quelqu’un qui aurait utilisé un Egaliseur aux petits oignons mais aimerait à la fin des fins utiliser le débruitage d’Aurélien Pierre (qui comporte un équaliseur), sans écraser son premier boulot ? Quid si j’ai fait un dodge & burn avec des masques manuels, et qu’un autre style emploie le module qui va bien ? On peut imaginer des tas et des tas d’exemples. Mon soucis initial à moi était que les styles Fujifilm sous-exposent de 0.72EV, et j’aimerais appliquer une correction correspondante mais sans affecter mes réglages d’exposition, indépendants du style utilisé.

2

Ai-je bien compris ? Il faudrait donc appliquer les styles prédéfinies avant de réaliser des traitements « à la main », en créant alors de nouvelles instances de modules déjà employés par l’application de styles ?

3

Plus généralement : on règle un module (à la main ou automatiquement avec un stylé prédéfini) et après, on veut appliquer un (autre) style prédéfini qui fait autre chose, mais qui emploie un module de même type (même avec un suffixe 1, 2 etc). Dans ce cas, je ne trouve pas de moyen pour empiler le second module au lieu de remplacer le premier. J’espérais qu’en employant dans le second style un module explicitement plus avant dans le pipeline (avec un suffixe 1, 2 etc), DT ferait le tri. Mais non : les noms des instances de modules n’ont pas l’air de les distinguer, si bien que je ne parviens pas au comportement attendu.

Je ne sais pas si je suis limpide ;( mais je fais de mon mieux. J’ai édité un peu le post original pour qu’on comprenne mieux.

4

OK, donc appliquer un style prédéfini après tout autre traitement écrasera les valeurs des modules déjà activés que le style utilise également.

Ce qui impose d’appliquer d’abord un style prédéfini puis faire d’autres traitements, hormis d’autres styles prédéfinis travaillant sur les mêmes modules, en créant de nouvelles instances des modules déjà activés par le style…

5

C’est là tout le problème : je ne parviens pas à appliquer un style employant un module, sans écraser les modules de même type déjà dans l’historique. C’est gênant.

6

Il faudrait pour cela que dt prenne en compte que chaque module utilisé par le style à appliquer est déjà activé et, dans ce cas crée une nouvelle instance. Ce qui n’est apparemment pas le cas…

Du coup il faut faire attention d’appliquer le style en premier en regard des modules qu’il active, par rapport aux autres traitements à suivre « à la main » et en instanciant les modules déjà activés.

Il pourrait être intéressant de tester dt pour voir si l’application d’un style travaillerait sur la dernière instance de module créée, en activant un module avec des paramètres « à la main », en créant une nouvelle instance vierge de celui-ci puis en appliquant un style intervenant sur ce module. S’appliquera-t-il sur la 1ère ou la 2ème instance ?

7

Il faut aussi vérifier que dans le module développement la liste déroulante « mode » est bien sur « empiler » et non sur « écraser ». Car si elle est sur « écraser » le comportement que tu signales est « normal »

8

Hmmm… je ne suis plus chez moi mais vérifier ça est la première chose que je ferai en rentrant. Il se peut que je sois un parfait abruti. En tout état de cause, ne sachant même pas que cette option existait, il y a peu de chances que je l’ai modifiée.

9

Je viens de faire un essai avec un de tes RAW, j’ai fait 2 instances expositions :

j’ai bien les 2 modules dans le pipeline ou je peux les inverser. De plus il se présente de la même façon et pas avec un avec centile en %.

10

Quand même pas! :smiley:

Je crains que même en suivant la piste évoquée par JP cela ne marche pas… DT va prendre en considération le fait d’écraser ou empiler deux styles entre eux mais traitera ces deux derniers en ne distinguant pas les modules communs. Je reproduis cette particularité chez moi (Linux DT 2.4.1) et ce quelque soit l’ordre de l’instance dans le style…

Peut-être suis-je passé à coté auquel cas les copains corrigeront :cool:

11

Je viens de comprendre pour le module exposition, on a centile en % quand on active automatique. J’ai jamais utilisé automatique sur mes photos, je n’endormirais moins bête et il faudra que je lise le manuel quand même.

12

J’ai essayé avec l’option « emplier ». Ca ne marche pas. J’ai fait un screencast pour montrer le problème, histoire d’être certain d’être bien compris.
https://vimeo.com/256633228[/video]
En gros :

[list=1]
[]Avec un style intégrant 2 modules de même type, c’est bon : les deux y sont
[]Je remets à zéro et prends soin d’actiover le mode « empiler »
[]J’applique un premier style avec un module « exposition » : c’est bon il s’applique
[]J’applique un second style avec un module « exposition 1 » et il remplace « exposition » bien que n’ayant pas le même nom, et malgré le mode « emplier »
[*]Si je réapplique « exposition 1 », il remplace « exposition »
[/list]
Donc pas trop avancé, finalement. Rermarquez, même si cette histoire d’empiler avait marché, ça n’aurait pas été top en termes de workflow pour choisir rapidement entre plusieurs styles, nécessitant une compensation d’expo ou pas.

13

Oui, cela est normal. Un style remplace toujours les modules correspondants. Donc un style avec un module exposition (1, 2, 3 ou n°4 peu importe) remplacera le module exposition cible. Les noms des modules n’ont aucune sémantique, c’est juste pour les reconnaître dans l’interface.

14

Bon et bien la messe est dite. J’ai donc supprimé les styles Fuji de ma config parce que je ne voyais pas comment insérer ça dans un flux de travail raisonnable. Les t3mujinpack feront bien l’affaire : n’agissant que sur la courbe, ils ne nécessitent en effet pas de correction d’exposition et peuvent être employés directement de la table lumineuse.

Je suis nouveau avec DT mais j’ai bcp utilisée COP et LR, et un peu DXO. J’ai des licences de tout ça mais je préfère DT. La modularité ainsi que la généralisation des masques dans DT donne une flexibilité sans égale (en tous cas comparé aux ténors commerciaux). Comme on n’a rien sans rien, ça vient en revanche au prix de clics assez nombreux en fin de compte.

AMHA, DT aurait le meilleur des deux mondes avec un système de styles un peu plus avancé. Il est en premier lieu nécessaire de pouvoir organiser ses styles dans des dossiers. Et on exploiterait vraiment la modularité de DT en pouvant a) identifier les instances de modules b) les appliquer en prenant en compte la sémantique induite par ces identidiants (qui pourraient même être des noms modifiables par l’utilisateur). Ca ouvrirait vraiment des tas de possibilités pour des développements très rapides directement de la table lumineuse, à partir d’un ensemble de styles fonctionnant bien ensemble, mais ne se pourissant pas les uns les autres en écrasant leurs modules respectifs.

15

Je regarderais les styles faits à partir de DxO FilmPack.

16

Merci mais ne t’embête pas trop. J’ai déjà abusé du temps de tt le monde.

J’ai aussi exploré les t3mujinpack et finalement ils sont bien. J’étais rapidement passé à autre chose une première fois parce que je trouvais les Portra 400 très bizarres (bcp trop saturés). Mais les 160 sont bien. Pour le reste, les styles sont pas mal donc je ferai avec sans soucis.

17

Dans une discussion sur Telegram, jpg54 a attiré mon attention sur le module « contraste lum. saturation ». Intégrer ça dans les DTStyles Fuji pour compenser l’assombrissement de 0.72EV qu’ils produisent, serait peut-être la solution. Ca laisserait libre le module de contraste pour autre chose, comme une expo auto par exemple, des Dodge & Burn avec le module expo etc. Pourquoi 0.72EV précisément ? … ça vient sans doute de là… https://photographylife.com/does-fuji-cheat-with-its-sensors (voir la toute fin de l’article, section Update)

En tout état de cause, comme on sait que les DTStyles Fuji sous-exposent de 0.72EV, à quoi correpond précisément +0.72EV en termes de CLS dans le module qui va bien ? Ca se calcule ? Parce que manifestement, juste toucher au curseur de luminosité, ça ne rend pas pareil.