Biche à 64200 ISOs

[rawfiner]

J'ai regardé ce que donnaient les canaux RGB pour l'image non traitée (de manière détournée, en utilisant la visualisation faite pour les masques paramétriques)
Il s'avère que le canal V est assez propre !
Les canaux R et B sont vraiment méchamment bruités par contre (en les regardant à 100% c'est flagrant par rapport au vert).
J'ai commencé à essayé de faire du débruitage en utilisant les modes de fusion "RGB canal rouge" et "RGB canal bleu". C'est prometteur mais c'est vraiment compliqué de bien voir ce que l'on fait (à moins qu'il y ait un moyen simple de visualiser uniquement le canal R, G ou B ?).

[jpg54]

Au fait, tu as fait des essais sur les photos de Metz ?

[rawfiner]

@jpg54 non pas encore, mais ça va probablement venir ;-)

[jpg54]

Ok, je suis pas pressé. Je travaille sur autre chose mais j'essayerais de mon côté quand j'aurais un moment.

[aurelienpierre]

J'ai regardé ce que donnaient les canaux RGB pour l'image non traitée (de manière détournée, en utilisant la visualisation faite pour les masques paramétriques)
Il s'avère que le canal V est assez propre !
Les canaux R et B sont vraiment méchamment bruités par contre (en les regardant à 100% c'est flagrant par rapport au vert).
J'ai commencé à essayé de faire du débruitage en utilisant les modes de fusion "RGB canal rouge" et "RGB canal bleu". C'est prometteur mais c'est vraiment compliqué de bien voir ce que l'on fait (à moins qu'il y ait un moyen simple de visualiser uniquement le canal R, G ou B ?).

Un capteur à matrice de Bayer possède 2 fois plus de pixels verts que rouge ou bleu, par construction. Du coup, si on suppose que le bruit est réparti de façon homogère entre les canaux, le canal vert reçoit plus de signal… donc moins de bizarreries au dématriçage et un bruit mieux dilué. On en revient toujours à la physique du bazar…

[rawfiner]

@aurelienpierre Oui je suis complètement d'accord avec cette analyse. En voyant ça je me dis qu'il y a probablement qque chose à faire avec les modes de fusion RGB en essayant de gérer le débruitage des canaux un à un pour bien contrôler le résultat. Certes, c'est ce qu'est censé faire le module de réduction de bruit de profil, mais comme on est parfois plus précis en faisant les choses "à la main", il faudra que j'essaye de ce côté là.

[mimi85]

Bravo aurelien et rawfiner pour tenter de comprendre pour améliorer notre façon de traiter le bruit.

[rawfiner]

Je reviens ici, j'ai du nouveau.
@aurelienpierre, comme tu disais, darktable dispose effectivement des meilleurs algos de l'état de l'art, il s'avère qu'on manque juste d'un peu de flexibilité dessus !
Voici un résultat obtenu principalement avec juste UNE instance du module de réduction de bruit de profil (+bilat pour le bruit de chrominance, 5 passes de lissages des couleurs dans le dématriçage, le module pixels chauds, et un chouilla d'égaliseur et de réduction de bruit non local, mais le résultat tiens surtout de l'instance de réduction de bruit de profil, et ça reste très peu comparé à ce qu'il fallait pour les derniers essais...)
Je trouve ça vraiment fou, c'est pas très loin de ce que donne DXO (et on peut encore ajuster avec instances multiples etc) !
Pour obtenir ça, j'ai simplement changé dans le code de denoiseprofile.c "const int K = ceilf(7 * scale);" par "const int K = ceilf(30 * scale);". Je suppose que K contrôle la taille de la zone de recherche pour trouver des patchs dans l'algo de non-local means.
Par contre, l'inconvénient c'est que le module s'exécute VRAIMENT plus lentement (c'était à prévoir en même temps haha).
Mais bon, vu le résultat :-D

J'ai mis à côté (à gauche) le résultat obtenu actuellement avec les même paramètres pour donner une sorte de référentiel.

Je vais aussi regarder si je peux implémenter ça : https://pdfs.semanticscholar.org/c458/71...761fc0.pdf
Ça permettrait probablement d'avoir de meilleurs résultats sans avoir à augmenter la taille de la zone de recherche.
Bref, affaire à suivre...

[aurelienpierre]

Je reviens ici, j'ai du nouveau.
@aurelienpierre, comme tu disais, darktable dispose effectivement des meilleurs algos de l'état de l'art, il s'avère qu'on manque juste d'un peu de flexibilité dessus !
Voici un résultat obtenu principalement avec juste UNE instance du module de réduction de bruit de profil (+bilat pour le bruit de chrominance, 5 passes de lissages des couleurs dans le dématriçage, le module pixels chauds, et un chouilla d'égaliseur et de réduction de bruit non local, mais le résultat tiens surtout de l'instance de réduction de bruit de profil, et ça reste très peu comparé à ce qu'il fallait pour les derniers essais...)
Je trouve ça vraiment fou, c'est pas très loin de ce que donne DXO (et on peut encore ajuster avec instances multiples etc) !
Pour obtenir ça, j'ai simplement changé dans le code de denoiseprofile.c "const int K = ceilf(7 * scale);" par "const int K = ceilf(30 * scale);". Je suppose que K contrôle la taille de la zone de recherche pour trouver des patchs dans l'algo de non-local means.
Par contre, l'inconvénient c'est que le module s'exécute VRAIMENT plus lentement (c'était à prévoir en même temps haha).
Mais bon, vu le résultat :-D

J'ai mis à côté (à gauche) le résultat obtenu actuellement avec les même paramètres pour donner une sorte de référentiel.

Je vais aussi regarder si je peux implémenter ça : https://pdfs.semanticscholar.org/c458/71...761fc0.pdf
Ça permettrait probablement d'avoir de meilleurs résultats sans avoir à augmenter la taille de la zone de recherche.
Bref, affaire à suivre...

intéressant. Il faudrait donc un paramètre de plus dans l'interface ? Je pensais que c'était déjà géré par l'option "taille". Je crois que c'est Hanika qui a développé ça, faudrait lui demander sur la liste dev.

[rawfiner]

Ok je vais pas tarder à me mettre sur la liste dev alors. :-)
Il y a des todos dans le code qui me semblent liés, mais je les ai pas bien compris.
Et je viens d'apprendre qu'il y a un brevet lié à la publi dont je parlais, donc c'est raté pour ça snif ;-(

---

Au passage, l'option taille est, je crois, simplement liée à l'algorithme des moyennes non locales :
Il cherche dans un voisinages des carrés, de cette taille, similaire au carré source, et ensuite fait une sorte de moyenne pondéré de tout ça (c'est pas exactement ça, mais je viens de commencer à lire les papiers dessus, donc c'est pas encore suffisamment clair dans ma tête)
Lorsque taille vaut 0, dans darktable, un algo bilateral est utilisé à la place