Je ne sais pas si j’ai bien compris ce que tu veux, mais pour moi c’est tout à fait possible : il suffit de tirer sur les poignées qui sont sur la ligne de dégradé (celle en pointillé) ex :
[hr]
Non je ne parle pas de la zone dégradé d’une zone mais de l’outil de masque dessiné dégradé et du module dégradé.
Salut à tous,
j’ai déjà posté là-dessus sur LinuxFR et j’en remets une couche ici 
puisqu’il y a un développeur Darktable dans le coin…
Je précise que j’ai pas mal testé Darktable et que j’apprécie l’énorme effort des développeurs, la qualité du logiciel (couleurs, rapidité, fonctionnalités), etc.
Néanmoins, il me manque surtout une fonction pour vraiment l’adopter, c’est le pinceau de retouche…
Je m’explique : je sais que je peux utiliser les masques dessinés pour faire des retouches locales, mais je trouve que c’est compliqué et peu ergonomique. En effet, si je veux appliquer plusieurs types de corrections sur une zone (par exemple l’exposition, le contraste local, la réduction de bruit, la netteté, etc.). Il va me falloir activer à chaque fois un nouveau module, rappeler le masque, appliquer la correction, etc. Bref, c’est long, compliqué, pas productif…
Dans Lightroom et Capture One (je viens de tester la version 10), on sélectionne l’outil Pinceau, on dessine la zone et on applique les corrections que l’on veut dessus. On voit en temps réel les modifs et pas après coup. On reste dans le même module (le Pinceau de retouche, en l’occurrence). Et c’est pareil pour les autres outils de retouche. C’est archi efficace… On retouche une photo en très peu de temps…
Alors la question : pourrait-on avoir ce genre de fonctionnement dans Darktable ? Par exemple, on pourrait avoir un module supplémentaire '« Pinceau de retouche » qui ferait ça. Est-ce que c’est techniquement possible sous Darktable (je veux dire sans modifier trop la manière dont les modules sont appliqués les uns sur les autres) ?
Merci de vos réponses / idées…
Et j’ai répondu quoi sur LinuxFR 
Que oui darktable est un peu plus complexe que Ligtroom sur ce point mais aussi beaucoup plus puissant. En effet là ou Lightroom ne propose que quelques réglages avec le pinceau darktable propose le traitement local sur tous les modules! Donc un outil pinceau avec les effets en second aurait une interface illisible et peu pratique dans darktable qui comporte nombre de module.
Un outil vient avec son ergonomie, on aime ou on n’aime pas ce n’est pas le sujet ici, mais il est très difficile de casser l’ensemble pour proposer une interface différente. C’est mon point de vue… Maintenant si quelqu’un vient avec une idée de l’interface utilisateur (simple et bien intégré) qui va dans ton sens pourquoi pas…
Personnellement je préfère et de loin le coté systématique de darktable: 1 module + filtre paramétrique + masque dessiné et je ne changerais pour rien au monde avec lightroom qui propose : 1 outils masque dessiné + quelques traitements, les autres traitements n’ont pas de masque dessiné et dans Lightroom il n’existe même pas de masque paramétrique.
My 2 cents!
Dans un premier temps j’ai aussi eu cette impression. Mais maintenant que je connais mieux Darktable, avoir la puissance de l’outil localisé dans tous les modules combinable avec les masques paramétriques et les modes de fusions est incomparablement plus puissant que ce que propose LR.
Reste qu’une détection automatique des bords de l’outil pinceau serait un plus dans Darktable sans pour cela en changer le fonctionnement global.
Il ne s’agit pas de proposer une interface différente. Peut-on juste envisager un module supplémentaire qui fasse ce que je propose ? Je suis d’accord que l’approche de Darktable permet de faire plus de choses que Lightroom ou Capture One, mais au prix d’une complexité d’utilisation vraiment élevée.
Lorsqu’on traite beaucoup d’images, l’approche Darktable est vraiment fastidieuse et surtout ne correspond pas à la logique du photographe : sélection d’une zone, puis corrections sur cette zone. Darktable fait l’inverse : sélection d’une correction, puis choix de la zone sur laquelle appliquer la correction. Ce qui – à mon avis – est un non sens total…
@bibifric05, oui tout est envisageable, mais c’est un boulot considérable et une duplication de beaucoup de code darktable pour faire cela. Donc ça a probablement 0% de chance d’arriver sauf si une personne le fait et que l’ensemble des devs fait whaou!!! Et quand je dis duplication je le pense vraiment car tous les modules darktable sont indépendant, oui oui le module exposition ne voit rien du module recadrage ou zone couleurs. Il ne sait même pas que cela exist… D’ailleurs le module ne sait pas non plus qu’il existe des masque paramétriques et encore moins des masques dessinés! C’est la grande force de l’architecture du programme.
Sinon on doit pouvoir éviter "est un non sens total… " car ça fonctionne bien pour moi par exemple (et je suis photographe) comme beaucoup d’autres photographes
Merci pour ces précisions, j’essaierai de jeter un oeil au code source… J’imagine que c’est du C++ avec des classes un peu propres ?
Sinon, je maintiens que l’approche utilisée pour les masques n’est pas la bonne. Il faut pouvoir dessiner le masque, puis appliquer les corrections directement sur ce masque. Même ce vieux Bibble (puis aujourd’hui AfterShot Pro son piètre successeur) fonctionnait sur ce principe…
LViatour dans les premières pages de ce fil parlait du manque de l’alignement d’images pour du stacking (HDR) dans DT.
Perso j’utilise CombineZP sous Windows qui travaille avec des Jpg. En parcourant le Web, j’ai trouvé ceci pour Linux:
http://www.lenaturaliste.net/portail/articles-des-membres/5-techniques-diverses/61-focus-stacking-en-ligne-de-commande-sous-gnulinux
Question, le script peut il être inclus dans DT, ou à défaut être fait à la suite du traitement DT pour répondre à l’attente de Luc
Non du C tout simplement. Au niveau architecture code c’est basé sur des hooks… On pourrait faire mieux
[hr]
Le site dépôt lua-scripts a tout cela et même plus. C’est pas encore dans la branche principale mais on peut le faire fonctionner en bidouillant un peu. La dernière fois que j’ai regardé j’avais des problème de compatibilité avec dt 2.2.
Aïe ! Bon, je regarderai quand même…
Un point qui m’agace entre autres et qui doit être facile à corriger, c’est le pinceau tout noir qui cache l’image. Il ne doit pas être difficile de le rendre transparent ou semi opaque, non ?
Surtout qu’il n’est pas facile de voir la zone de dégradé de l’outil il y a bine le rond plein et le cercle qui délimite la zone de dégradé mais ce n’est pas aussi parlant q’un masque semi transparent avec la zone de dégradé visible.
Sur ce point je suis 100% d’accord. Note que l’opacité de l’outil est représenté par la transparence du pinceau, mais on pourrait envisager une semi transparence lorsque l’on dessine. Si j’ai un peu de temps je proposerais un patch dans ce sens. Ce que tu peux faire c’est d’ouvrir un ticket Redmine. Je me l’assignerais.
OK, je viens de le faire (sous le nom de roland65), merci !
en tous les cas merci à vous
à l’utilisation du nouveau module correction des perspectives je me rends compte qu’il devrait à terme fusionner avec l’outil recadrage et en devenir une option dans l’outil de recadrage.
Je m’explique: Dans l’outil recadrage je peux mettre une contrainte carrée ou 16/9 mais dans l’outil de correction de perspective auto, le mode de recadrage auto après redressement ne tient pas compte de cette contrainte.
De même que je peu trouver que le redressement auto ne me plait pas et que je veuille faire une retouche manuelle je dois désactiver la retouche auto et retourner dans l’outil recadrage pour faire une perspective manuelle.
Idem dans le module de recadrage si j’utilise le redressement manuel des perspectives je n’ai pas la fonction de recadrage automatique.
Si je fais un redressement dans l’outil de recadrage que je trouve plus précis (grâce à la ligne que je peux tirer sur le sujet) il est perdu une fois que je passe dans l’outil de redressement des perspectives auto et je dois donc redresser avec l’outil de redressement dans ce module via curseur beaucoup moins précis.
@LViatour, en fait l’idée est de supprimer pas mal de chose en double présent dans l’outil recadrer et de réécrire ce dernier qui au fil du temps est devenu très difficile à maintenir. Donc tout cela va changer dans les prochaines versions.
@pobry, du moment qu’ils ne retirent pas des fonctions car je trouve bien d’avoir toutes les fonctions de recadrage, redressement, perspectives contraintes dans un seul outil.
Je pense vraiment que l’idée pour le moment est d’avoir 2 outils séparés. Un pour les perspectives, un pour le recadrage, mais ce ne sont que quelques discussions pour le moment. Le design final n’est pas fait.
https://redmine.darktable.org/issues/9715 won’t fix, j’aurais bien voulu un truc comme ca 