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
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!
Pas de souci 
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à.
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.
Cool! ?
C’est l’objectif oui.
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 !
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 ! 
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.
D’accord, je vais essayer ça, merci pour ta réponse !
[hr]
Je n’ai plus le problème en compilant depuis ton github. C’est d’ailleurs assez curieux, la compilation s’arrêtait sur une erreur, j’ai dû installer une librairie qu’il me manquait, c’est sans doute ça qui posait problème. Aucune idée de comment la première compilation avait réussi malgré ça.
Bref, ça marche
Merci en tout cas
Je me demandais si l’algorithme pourrais s’appliquer à mon image :
https://www.dropbox.com/s/7zpntrqdvtesael/20170325_274.NEF?dl=0
C’est la photo d’un original sur sa drôle de machine dans une petite rue de Paris en face d’un magasin qui fait écho à son invention.
dans ma précipitation j’ai fait le point sur la vitrine et non sur le personnage. A f/4 j’ai un petit flou sur la personne et son bizarre engin.
Est-ce rattrapable même légèrement ?
En attendant le module de déconvolution tu sais déjà améliorer les choses avec ce qu’il y a dans DT.
Ici le flou est léger les outils d’accentuation peuvent donner une belle sensation de netteté.
Techniquement, ici on a trois flous : un flou d’objectif (défaut optique), un léger back-focus (flou de mise au point sur le monsieur), un léger flou de mouvement (uniquement sur le monsieur). De plus, le sujet n’est pas continu (on voit l’arrière-plan apparaître au milieu du sujet). On n’est donc sur un cas limite de mon algo, puisque je ne peux pas masquer et déflouter sélectivement, et que donc je vais retirer du flou de mouvement sur les parties statiques.
Néanmoins, voici ce que j’ai réussis à faire (en prenant le flou sur la tête du monsieur, donc en essayant de refaire de focus sur lui) :
Variante moins dramatique corrigeant seulement le flou d’objectif (en prenant le flou sur de trottoir à hauter du sujet) :
Même retouche sur le fichier source (sans la déconvolution) :
À noter que j’ai été un peu bourrin sur les curseurs pour aller plus vite, et que le contraste local laplacien se comporte de façon complètement différente sur les 2 images, malgré des réglages identiques.
Hors-sujet : il me fait penser à https://www.youtube.com/watch?v=dBlO7B8kKi8
Bonjour.
Je me permets de faire un petit déterrage, car le module de déconvolution développé sur ce fil m’intéresse, mais je n’arrive à le trouver dans DT. J’ai fait une recherche rapide mais (re)découvrant DT via ce sujet (je savais que DT existait, mais je n’avais jamais tenté de m’en servir), je j’ai pu passer à côté d’un pan du logiciel.
D’où ma question : qu’en est-il de son intégration dans DT ?
Pour l’instant toujours en développement dans une branche parallèle d’Aurélien et pas intégré dans la version de base.
Le problème de cette approche, c’est que tu peux attendre ta photo 20 minutes dans les cas sévères, et pour un logiciel qui essaie d’être temps-réel, c’est pas génial comme ergonomie… Depuis, j’ai essayé d’autres options un peu moins lourdes (quelques minutes max).
Suggestion: Ce module pourrait peut-être être proposé comme outil complémentaire de DT sachant qu’il ne peut être temps réel?
Et puis ça présente l’intérêt de pouvoir le faire tourner en tâche de fond pendant qu’on peut faire autre chose par ailleurs.
En tous cas, il présente un réel intérêt, et il est dommage de le laisser de côté, alors qu’il comblerait les besoins de nombre de photographes.