Profils vs duplication de modules

[temperdu]

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#7brpb...19DUW6cbD4=

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 :

• "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
  

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é.

[manu]

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 ?

[temperdu]

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.

[manu]

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...

[temperdu]

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...

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.

[manu]

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 ?

[jpverrue]

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"

[temperdu]

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"

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.

[jpg54]

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 %.

[Carafife]

Il se peut que je sois un parfait abruti.

Quand même pas!

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