A quel moment appliquer un masque paramétrique ?

[aurelienpierre]

> Et puis tout çà fait aussi ressortir la notion d'ordre de traitement .... L'ordre de traitement des modules est-il fixe ou est-il fonction de l'ordre d'application lors du développement (celui de l'historique donc) ? J'ai cru comprendre , entre autre au travers des vidéos d'Aurélien, qu'il y avait une ordre fixe ... du moins pour certaines choses, et que l'ordre du pipe est plus ou moins reflété dans l'onglet "modules actifs".

Dans la version de développement de darktable actuel, qui sera publiée à Noël sous le numéro 2.8, l'ordre des modules peut désormais être changé par l'utilisateur, et c'est nouveau. Par contre, il reste des bugs. On va garder ça pour le futur darktable next-gen 3 ou 4 (en tout cas, le fondateur de dt est d'accord et je vais peser dans ce sens). Et même peut-être opter pour une interface nodale, comme dans les logiciels de 3D.

Dans daktable 2.6 et précédent, l'ordre des modules est fixe.

[Grosbeta]

Dans la version de développement de darktable actuel, qui sera publiée à Noël sous le numéro 2.8, l'ordre des modules peut désormais être changé par l'utilisateur, et c'est nouveau. Par contre, il reste des bugs. On va garder ça pour le futur darktable next-gen 3 ou 4 (en tout cas, le fondateur de dt est d'accord et je vais peser dans ce sens). Et même peut-être opter pour une interface nodale, comme dans les logiciels de 3D.

Dans daktable 2.6 et précédent, l'ordre des modules est fixe.

Dans le mesure ou j'utilise en général une version dev compilé depuis le git , j'avoue que si la réorganisation du pipe de traitement peut attendre d'être stabilisée avant d'intégrer la branche master ....égoistement ca me va bien !

Pour l'ordre de traitement actuel ( version 2.7.0+1594  ) , en lançant darktable avec l'option -d perf ... on constate que l'ordre de traitement semble effectivement être le reflet parfaire de l'onglet 'modules actifs'. Donc si ma méthode de test est valable, on a ainsi l'ordre du pipe de traitement.

Et puis, tant qu'à jouer, j'ai tester un masque paramétrique sur l'exposition.

- 1ère instance d'exposition ... sans masque. Je place l'expo à +2ev
- 2ème instance d'exposition avec masque paramétrique sur le canal L pour ne garder en entrée que les parties les plus sombres et leur redonner un léger boost.
- j'affiche le masque de l'instance 2 : seulement qq zones sont prises en compte.
- je rebascule sur l'instance 1 de l'expo et je passe de +2ev à 0.ev
- retour sur l'instance 2, celle avec le masque, affichage du masque : beaucoup plus zones prises en compte.

Je ne sais pas ce qu'en pense GM1901, initiateur de la discussion , et Aurélien,  mais pour moi cela me semble un comportement normal et logique .

[GM1901]

Je n'ai pas de problème avec le comportement actuel du logiciel et suis conscient qu'améliorer les choses nécessite des modifs en profondeur comme expliqué par Aurélien. J'ai initié le fil pour vérifier que ma compréhension était correcte. Par contre, sauf modifs dans la 2.8, je pense comme je l'ai dit ci-dessus que ça mériterait une clarification dans la doc pour, au moins, inciter les utilisateurs à être attentifs au moment où ils introduisent un masque paramétrique.

[Grosbeta]

Je n'ai pas de problème avec le comportement actuel du logiciel et suis conscient qu'améliorer les choses nécessite des modifs en profondeur comme expliqué par Aurélien.

A mon avis, le comportement actuel des masques paramétriques est correct :  leur "couverture / zone d'action" évolue en fonction des changements de réglage des traitements précédents dans le pipe de traitement.
Par exemple, si j'ai un masque basé sur des valeurs de luminance, lorsque je fais varier l'exposition (située assez tôt dans l'ordre des traitements) , le masque change.

Du coup, qu'appelles tu  "améliorer les choses" dans le cas des masques paramétriques ?

Ps : entièrement d'accord pour rendre les choses plus claires dans la documentation.

[aurelienpierre]

Enfin c'est quand même rare, en pratique, qu'on fasse un masquage 1D purement paramétrique. En général, le masque paramétrique est un moyen indirect de sélectionner une zone 2D, et avoir la zone qui bouge quand les modules précédents ont changé n'est pas ergonomique. Je pense que les seules fois où j'ai utilisé un masque paramétrique pour faire un masquage 1D, c'était pour alléger les défauts de modules dont j'ai découvert plus tard qu'ils étaient fondamentalement cassés (mappage des tonalité, par exemple, qui implémente des équations prévues pour le RGB en Lab…).

[Grosbeta]

@aurelienpierre
J'avoue ne pas comprendre ce que veux dire masquage 1D et masquage 2D.

Typiquement mon usage de masque paramétrique est le suivant :
- une première instance de réglage d'exposition.
- une 2ème instance de réglage d'exposition pour affiner l'expo avec un masque paramétrique 'L' , souvent pour exclure les hautes lumières. En général il s'agit d'essayer de rajouter un poil d'expo sans continuer à cramer les HL. Pas plus d'un 1/3ev sinon on a des effets étranges sur l'image en jouant sur des corrections partielles d'expo (apparition d'aplat ou de dérive de couleur si des zones censées avoir une expo différente se retrouve avec la même expo consécutive à la correction partielle.
Mais c'est peut-être une mauvaise méthode qui plus est pour rattraper une image mal exposée.

Autre exemple de masque paramétrique dans mon cas : avec le module de réduction de bruit, j'ajoute une instance qui va débruiter plus fortement les zones sombres ou claires de l'image ... donc un masque paramétrique sur le canal L.

Du coup, moi je trouve qu'avoir la "zone qui bouge" quand les modules précédents changent, c'est parfaitement logique. En général avec un masque paramétrique je vise une "plage de luminance", donc si des modifications de réglages en amont affecte la luminance globale de l'image, je trouve normal, logique et sain que le masque s'adapte pour continuer à couvrir la plage de luminance souhaitée. Numériquement, je vise toujours la même plage de luminance, simplement il se trouve que la partie de l'image correspondant à cette plage change.

Si je veux un masque "stable" au gré des variations de réglages de module, je passe par un masque dessiné.

[aurelienpierre]

Un masquage 1D traite les pixels un par un, en regardant seulement leur valeur. C'est ce qu'on appelle appliquer une fonction de transfert.

Un masquage 2D traite les pixels en régions, en regardant leur valeur mais aussi celle de leurs voisins. C'est ce qu'on appelle appliquer une convolution (terme mathématique qui désigne la classe d'opérateurs que sont le flou, la suppression de flou, la mise à l'échelle (interpolation), la rotation, mais aussi des filtres utilisés par le débruitage en moyennes non locales, les filtres guidés, etc.).

Le problème de ton approche (exposition avec fusion paramétrique pour exclure les hautes lumières), c'est qu'elle ne tient pas compte du voisinage des pixels. Imagine que tu pousses l'exposition d'un pixel sombre situé au milieu d'une région claire (qui, elle, ne bouge pas) : tu viens d'écraser le contraste local, et de perdre des détails. C'est exactement le problème que j'essaie de résoudre avec le masque guidé, dans mon module d'égalisation des tons (https://forums.darktable.fr/showthread.php?tid=3162). Ce que tu veux faire, en fait, c'est équilibrer l'exposition de façon homogène sur une zone homogène, pour préserver le contraste local.

Concernant le débruitage, normalement le modèle statistique de bruit (gaussien ou poissonnien) devrait déjà tenir compte de l'intensité du pixel : par définition, le bruit gaussien est invariant en fonction de l'intensité lumineuse, et le bruit poissonnien est un bruit quantique qui augmente avec l'intensité lumineuse (paradoxalement). Du coup, si tu as besoin d'atténuer l'une ou l'autre des zones, c'est que le modèle statistique du module n'est pas bon dès le départ (ou qu'on débruite des pixels RGB encodés en gamma, voire dans l'espace Lab, ce que font les modules de débruitage bilatéral et non-local).

Je suis de plus en plus convaincu que les masques paramétriques, bien utilisés, ne servent à rien d'autre qu'à planquer les faiblesses d'algorithmes cassés. En général, tu veux utiliser des masques 2D, et dans ce contexte, tu ne veux pas qu'ils bougent.