Réglages de base ?

[aurelienpierre]

S'il y a bien un truc que j'ai appris en faisant du développement, c'est qu'on ne peut pas satisfaire tous les usages avec un seul outil, et que la conception, c'est des choix et des compromis à faire.

Dans DT, chaque pixel passe dans un « tuyau » où différents filtres sont installés dans un ordre immuable, dicté par la physique ou les maths du filtrage réalisé. Chaque filtre est piloté depuis un module. Du coup, restreindre le module à une zone est plus naturel (et probablement plus propre côté codage) que de « charger » une zone avec des modules et de les dupliquer dans l'interface. L'approche Une fonction = Un module est parfaitement rationnelle.

Mais comme Pascal l'a expliqué, tu peux centraliser la gestion des masques dans le module adéquat. La plupart des freins que te mentionnes n'en seraient pas si tu avais lu la doc et assouplis un peu tes paradigmes.

Admettons... Comment se fait-il alors que les autres logiciels fonctionnent tous sur le principe inverse (un calque ou une zone sur laquelle on applique une ou des corrections) ? Ceux que j'ai testés dernièrement : Lightroom, CaptureOne, Luminar, On1, DXO PhotoLab, AfterShot Pro, LightZone, PhotoFlow sont tous sur ce modèle. J'en oublie sûrement...

Parmi ceux-ci, j'ai d'ailleurs été impressionné par les U-point de DXO PhotoLab (issus des plug-in Nik Collection), que je trouve vraiment intuitifs, puissants et bien adaptés à la photo.

Quant à Darktable, cela fait plusieurs années que je m'y intéresse car il est puissant, libre et natif sous Linux. Non seulement je me suis fadé le manuel, mais pas mal des tutos de Carafife, et j'ai travaillé l'an dernier sur le code source pour modifier le pinceau, même si en fin de compte mes modifs ne m'ont pas satisfait.

J'ai fait plusieurs plugins pour Bibble il y a quelques années (USM, corrections LAB), donc oui je pense que je connais un peu le sujet...

En ce qui concerne le pinceau, le choix de Cairo est mal adapté car c'est du vectoriel et de base il n'y a pas de gestion du flou (on peut le rajouter, mais c'est une verrue, ça n'a pas été conçu pour ça). Le développeur a utilisé la même mise en oeuvre que pour les splines (sélection de type contour) et je le comprends car c'était plus simple. Mais il faudrait faire autrement, peut-être avec libmypaint, à voir... Il faut que l'on puisse voir l'étendue de la zone floue lorsque l'on dessine au pinceau et pas seulement après-coup en affichant le masque. Il ne faut pas que l'on voie tous les points de contrôle du tracé, idéalement il faudrait seulement que l'on puisse voir ceux de l'enveloppe concave, sauf que c'est compliqué quand il y a des "trous" dans le tracé au pinceau (ex : un tracé en 8).

J'aimerais bien travailler là-dessus, mais d'une part je n'ai pas le temps et puis je préfèrerais qu'un vrai développeur s'y mette...

Mon idée de réorganiser les modules en mettant dans un seul module les cinq ou six outils les plus courants ne me paraît pas contrevenir à la philo de Darktable et permettrait de gagner en efficacité lorsqu'on équilibre une image... Ça ne semble vraiment pas compliqué à mettre en oeuvre d'un point de vue codage.

En même temps, un pinceau en vectoriel, ça donne ça. Si tu veux gérer des flous de canal alpha, il faut passer en bitmap, comme ce que fait Photoshop avec ses masques et plein de raffinements cools comme le flux de la brosse, la détection de contours etc. Mais le bitmap ne se stocke pas dans une base de données, alors tu créées d'autres problèmes.

L'étendue de la zone floue est visible pendant le tracé au pinceau avec le contour en tirets. Dans ma pratique, c'est amplement suffisant, les sélections précises étant mieux gérées par l'outil chemin.

« Parmi ceux-ci, j'ai d'ailleurs été impressionné par les U-point de DXO PhotoLab (issus des plug-in Nik Collection), que je trouve vraiment intuitifs, puissants et bien adaptés à la photo. »

Je ne suis pas d'accord. La seule fois que j'ai utilisé des points de contrôle, c'était dans le module flou d'objectif de Photoshop, et je trouve que c'est la façon la moins intuitive de définir un masque vectoriel. Beaucoup trop approximatif, tu perds des heures à l'ajuster pour finir avec rien de satisfaisant à la fin. L'humain voit des contours, pas des champs de gradients.

« Mon idée de réorganiser les modules en mettant dans un seul module les cinq ou six outils les plus courants ne me paraît pas contrevenir à la philo de Darktable et permettrait de gagner en efficacité lorsqu'on équilibre une image... »

Je ne suis pas d'accord. Une retouche efficace suit des étapes balisées, idéalement le même ordre que celui d'application des modules. Si tu commences à répliquer les modules dans un ordre aléatoire, déjà qu'ils ne sont pas nécessairement dans l'ordre d'application, tu ouvres la portes de l'Enfer. Les modules de base sont déjà dans l'onglet du même nom (le premier), je ne vois pas ce qu'on peut faire de plus.


« J'aimerais bien travailler là-dessus, mais d'une part je n'ai pas le temps et puis je préfèrerais qu'un vrai développeur s'y mette... »

On est tous logés à la même enseigne. Dans mes cartons, j'ai un module de déconvolution aveugle par apprentissage machine, un module de débruitage, et un algo de dématriçage qui débruite en même temps… Et moi aussi, j'aimerais bien me contenter de pondre l'algo mathématique et de laisser l'intégration en C à des gens qui le maîtrisent, mais ça n'arrivera pas, alors il faut que j'apprenne le C et le fonctionnement interne de DT sur mon temps libre de sommeil.