Possible nouveau module déconvolution

[FrEd85]

Oui merci aussi pour les explications avec la vidéo, très intéressant !

Juste par curiosité, quand tu dis dans la vidéo (@~20:22) parlant de la déconvolution de Richardson-Lucy qu'elle réalise une estimation de la distribution de gradiant en se basant sur des lois et des observations statistiques, est-ce que ça veut dire que ce n'est pas figé et que ces statistiques peuvent évoluer, vers une amélioration, un affinement ?

Merci encore pour ce travail et cette restitution.

alors, pas exactement… Je n'ai pas été complet sur ce sujet dans la vidéo car la théorie dépasse le niveau lycée que j'essaie de suivre.

L'algorithme classique de Richardson-Lucy se contente de retirer du flou d'une image, d'une façon très imparfaite, et suppose de connaître précisement le flou appliqué. Le problème principal de cette méthode est qu'elle amplifie le bruit (qui est inconnu à l'avance), car le bruit et les détails nets sont tous dans les hautes fréquences, et l'algo de R-L ne fait pas la différence entre les deux.

La version de Perrone/Favaro que j'ai codée réalise une régularisation basée sur des observations statistiques, qui permet de supprimer le bruit sans (trop) supprimer les vrais détails fins. Ici, les stats sont utilisées pour essayer de différencier le bruit des détails nets à priori (car on ne peut pas faire autrement). Pour ce faire, ils attribuent une pénalité aux pixels qui ont un comportement qui dérive de la loi statistique (ils les effacent partiellement de la solution).

La loi statistique qu'ils utilisent montre que le logarithme de la variation totale suit une distribution de Cauchy (la variation totale, c'est la norme vectorielle du gradient sur les lignes et sur les collonnes de pixels). D'autres versions existent (sans le logarithme, ou utilisant des ondelettes au lieu de la variation totale) et peuvent donner de meilleurs résultats dans des cas très précis. L'idée c'est toujours de trouver une description mathématique (on appelle ça un modèle) qui permette de faire la différence entre du bruit et du détail, pour venir nettoyer l'image déconvoluée des anomalies que créée la méthode de Richardson-Lucy. J'ai choisi cette méthode parce qu'elle retombe sur l'image nette dans plus de 50 % des cas et que c'est une des meilleures disponibles (et aussi parce que les chercheurs ont publié leur code source Matlab). Je l'ai juste un peu adaptée pour la rendre plus rapide et compatible avec une utilisation en photo par des gens sans doctorat ;-)

Donc évidemment, il n'est pas exclu que quelqu'un arrive un jour avec un modèle plus précis. C'est la beauté des sciences.

---

Merci pour ces explications Pierre, super travail pédagogique. Il mériterait une diffusion plus large en transposant quelques exemples sur lesréglages de Rawtherapee à destination de nos amis photographes travaillant sur Windows...
François

De rien. Mais mon nom c'est Aurélien.

On me demande souvent une version RawTherapee, mais je n'utilise pas ce logiciel (je ne l'aime pas) et je ne connais pas ses développeurs. Ceci dit, une fois codé en C, le plus gros sera fait et l'intégration ne devrait pas être très compliquée.

Salut Aurélien,
Pardon pour la confusion entre ton nom et ton prénom. Je n'aimais pas RT nom plus... Jusqu'à la version 5 ! Elle merite qu'on s'y attarde un peu un gros effort d'ergonomie, de stabilité et de performance ont été menés. C'est bien d'avoir le choix en linux aussi non ?
Cordialement,
François

[pascal]

Oui, c'est bien d'avoir le choix. J'ai RT installé depuis plusieurs années sur ma machine. Je teste de temps en temps, mais à chaque fois je me dis que RT n'est pas fait pour moi. L'ergonomie est aux antipodes de ce que je recherche, je n'arrive pas à m'y faire!

[aurelienpierre]

Pas de souci ;-)

[aurelienpierre]

Bonjour tout le monde,

dernières nouvelles de ce travail : mes algorithmes ont été portés en C par Edgardo et fonctionnent dans une version HAUTEMENT INSTABLE de darktable. Le module est assez inutilisable puisque très lent. Je peux quand même donner le Github s'il y a des aventuriers.

Mais mais mais… je viens de trouver des astuces algorithmiques (mathématiques, quoi), pour l'accélérer en demandant moins de calcul pour le même résultat. cette nouvelle technique plus des astuces de programmation (optimisations diverses) m'ont permis d'accélérer le temps de fonctionnement jusqu'à 3× pour la version Python. On passe sous les 20 min de traitement pour une image de 24 Mpx (contre plus d'une heure en faisant moins de tours de boucle avant).

De pluuuuuus, 75 % du temps de calcul de cette méthode est alloué à l'estimation du flou, qui se faisait jusqu'à présent en même temps que le défloutage de l'image (pour gagner du temps). J'ai changé de stratégie en n'estimant le flou que sur une région de 255×255 px, puis en défloutant toute l'image avec les informations recueillie dans la zone échantillon. Ça me permet non seulement de faire une estimation hyper précise en moins d'une minute, mais aussi de stocker le profil de flou pour redéflouter plus tard (comprendre : calculer le flou une fois et se contenter de déflouter quand vous changez le zoom du la table lumineuse DT). Ça fait qu'au moment de l'exportation, 75 % du calcul est déjà fait.

Voilà voilà.

[mmoy]

> mais aussi de stocker le profil de flou pour redéflouter plus tard

Est-ce que ce profil de flou est stocké dans la base de données (et le .xmp) ? Ça permettrait aussi de conserver l'info après fermeture/réouverture de dt.

[Carafife]

Cool! ?

[aurelienpierre]

> mais aussi de stocker le profil de flou pour redéflouter plus tard

Est-ce que ce profil de flou est stocké dans la base de données (et le .xmp) ? Ça permettrait aussi de conserver l'info après fermeture/réouverture de dt.

C'est l'objectif oui.

[jpg54]

J'ai déjà testé les premières versions de darktable sur quelques unes de mes photos. InStable qu'il dit, ben, mon ordi n'a pas explosé ni appris à voler !

[rawfiner]

Bonjour à tous
J'ai essayé de compiler tout ça (j'avais essayé le script python qui m'avait donné de bons résultats), je me suis donc basé sur la branche rlucy du github d'Edgardo (commit 0c864ef8bd5afa9aac3647becd245f33f654d622)
Malheureusement, le module a pour effet de m'assombrir la photo, jusqu'à ce qu'elle devienne complètement noire.
Plus j'augmente le nombre d'itérations (que ça soit pour le deblur strength ou pour le refine quality), plus la photo devient sombre (j'ai eu ce comportement sur toutes les photos avec lesquelles j'ai essayé).
Une idée d'où ça peut venir ? (je comprends bien que c'est instable et pas encore finalisé, je pose juste la question au cas où vous auriez déjà rencontré ce problème)
D'avance merci, et en tout cas bravo pour le boulot ! :-)

[aurelienpierre]

bizarre. Essaie peut-être avec ma version : https://github.com/aurelienpierre/darktable/tree/rlucy

De toute façon l'algorithme utilisé n'est plus à jour, les maths ont changé, il faut que je répercute les modifs du Python de développement vers le C.