Si vous venez de Darktable, vous vous attendez peut-être à cela dans la chambre noire :

tandis qu’Ansel vous offre ceci :

Ce n’est pas un accident, et il est temps d’expliquer pourquoi, et pourquoi cela ne sera pas étendu avec des options de personnalisation.
Les images naissent des pipelines
Un pipeline de pixels est une séquence de filtres dans laquelle les pixels sont traités pour aboutir sur un support. Photoshop appelle ces filtres couches , se conformant à une métaphore héritée du papier et de la peinture matte. Da Vinci Resolve, Blender, Natron, etc. les appellent nœuds , se conformant à une métaphore enracinée dans les graphes orientés et les organigrammes , mieux connus des ingénieurs. Les deux ont une manière de montrer comment ces filtres sont organisés, soit avec une pile de couches soit avec le graphe de nœuds (alias organigramme).
La partie importante est, l’ordre importe.
Un bref historique de la mauvaise conception
Darktable appelle ces filtres modules. Mais “modules” fait référence à la logique de programmation modulaire : chaque module est codé séparément, en utilisant une API uniforme, et ne sait rien des autres modules. La chaîne elle-même ne sait rien de l’intérieur des modules, elle ne fait que connecter les entrées et les sorties. C’est une manière propre de développer, mais c’est complètement irrelevant pour l’utilisateur final.
Le problème est que Darktable a 2 types de modules :
- les modules de la table lumineuse (et les modules du panneau de gauche de la chambre noire), qui sont des boîtes à outils arbitraires et donc _purement des éléments/cadres GUI,
- les modules de la chambre noire, qui sont à la fois un filtre de pixels situé quelque part dans la chaîne, et également une boîte à outils GUI. (comme les modules précédents).
- les modules de la table lumineuse (et les modules du panneau de gauche de la chambre noire), qui sont des boîtes à outils arbitraires et donc _purement des éléments/cadres GUI,
- les modules de la chambre noire, qui sont à la fois un filtre de pixels situé quelque part dans la chaîne, et également une boîte à outils GUI. (comme les modules précédents).
- les modules de la table lumineuse (et les modules du panneau de gauche de la chambre noire), qui sont des boîtes à outils arbitraires et donc _purement des éléments/cadres GUI,
- les modules de la chambre noire, qui sont à la fois un filtre de pixels situé quelque part dans la chaîne, et également une boîte à outils GUI. (comme les modules précédents).
Et ces différents modules, en plus d’être nommés de la même manière, se ressemblent exactement…

C’est 3 erreurs ici :
- nommer un objet GUI par son nom d’implémentation technique au lieu de son objectif fonctionnel,
- nommer et représenter de la même manière 2 objets conceptuellement différents,
- ne pas réussir à représenter l’ordre des modules de manière claire et hiérarchique.
- nommer un objet GUI par son nom d’implémentation technique au lieu de son objectif fonctionnel,
- nommer et représenter de la même manière 2 objets conceptuellement différents,
- ne pas réussir à représenter l’ordre des modules de manière claire et hiérarchique.
- nommer un objet GUI par son nom d’implémentation technique au lieu de son objectif fonctionnel,
- nommer et représenter de la même manière 2 objets conceptuellement différents,
- ne pas réussir à représenter l’ordre des modules de manière claire et hiérarchique.
En conséquence, de nombreux utilisateurs considèrent encore tous les modules comme des boîtes à outils arbitraires et ont demandé pendant des années des moyens de les réorganiser arbitrairement dans la fenêtre, ce qu’un manque de leadership technique a autorisé, sous la forme d’un groupe de modules terriblement codé (3500 lignes de code, subtilement cassé) et surcomplexifié, consommant 3 % de votre CPU même lorsque vous n’interagissez pas avec l’application, tant que votre chambre noire reste inactive.
La cerise sur le gâteau est que les groupes sont étiquetés par des icônes, à des fins de compacité, mais ces icônes sont absolument cryptiques et seuls les utilisateurs de longue date font semblant de savoir ce qu’elles représentent (j’ai dessiné celle représentant les rayons de lumière traversant une lentille mince, que les gens prennent pour un OVNI – j’ai appris de cette erreur).
Les bons workflows sont conscients du pipeline
Ça fait 3 ans que je suis payé par les utilisateurs pour leur expliquer les tenants et aboutissants du logiciel, et pour répondre à la même question encore et encore : où commencer un workflow et comment le dérouler. Ce qui me frappe encore, c’est que les gens avec un master, qui ont lu la doc et regardé la plupart de mes vidéos, sont encore incapables de démarrer un workflow d’édition d’image par eux-mêmes. Soit c’est un design criant de manière erronée, soit la plupart des gens avec une éducation supérieure sont idiots. En fait, même si les gens étaient idiots, il est plus facile de faire un design à l’épreuve des idiots1 que de s’attendre à ce qu’ils se développent un cerveau du jour au lendemain, donc de toute façon le design est mauvais par rapport au public cible.
Si vous ouvrez Photoshop, les couches s’empilent intuitivement. Nous avons tous travaillé avec des couches pour des projets artistiques à l’école primaire. Cela ne vous viendrait pas à l’esprit de commencer à travailler sur la couche la plus basse après avoir mis de nouvelles choses au-dessus. Eh bien, les 70 autres modules de Darktable, organisés dans des onglets par thème, d’une manière qui ne tient pas compte de la chaîne ni du workflow, sont garantis de décourager les nouveaux venus et de promouvoir de mauvaises habitudes chez les anciens.
Les workflows sains sont conscients du pipeline, ce qui signifie que l’ordre dans lequel vous ajustez les filtres devrait être défini par l’endroit où ces filtres se trouvent dans la chaîne de traitement. Mais je dis conscients du pipeline, et non définis par la chaîne, car le début et la fin de la chaîne (propriétés de la scène et de l’affichage) devraient être configurés en premier, afin d’avoir une bonne vision d’ensemble sur ce que nous faisons entre les deux. Notamment si vous allez manipuler des signaux HDR sur un écran SDR, vous devez mettre vos lunettes de soleil HDR pour voir votre signal en SDR. Mais ce que vous voyez n’est pas ce qu’il y a dans votre chaîne. C’est pourquoi le workflow ne suit pas 1:1 la chaîne, mais reste assez proche de celle-ci.
Imaginez que vous définissiez une teinte dans le module équilibre des couleurs, ciblant les hauteurs de teinte à travers le paramètre gain. Ensuite, vous trouvez l’image trop sombre et l’éclaircissez avec le module exposition. Mais exposition vient (bien) avant équilibre des couleurs dans votre chaîne, donc maintenant vous devez mettre à jour le réglage de la teinte car il sera probablement trop fort sur les demi-teintes. Maintenant, convolver cela avec un autre module intermédiaire (ou plus) qui utiliserait un masque paramétrique sur n’importe quelle métrique de la luminosité ou de la luminance… Vous êtes parti pour une édition circulaire, une expérience d’édition particulièrement inefficace et frustrante où chaque nouveau réglage invalide le précédent. Bien sûr, il y a ceux qui pensent que la photographie étant un art, tout est une question d’opinion et de préférences, donc finalement rien de tout cela n’a d’importance. Art ou pas, un château de cartes tombera entièrement chaque fois que vous commencerez à jouer avec les niveaux inférieurs, donc finalement c’est une question de combien de temps vous êtes prêt à perdre, et cela n’a rien à voir avec les opinions ou les préférences. Je serais aussi d’avis que les amateurs du week-end sont tout aussi pressés par le temps que les photographes professionnels : ces derniers pour des raisons économiques, les premiers parce que le week-end ne dure que 2 jours et ils devront être de retour au bureau le lundi matin avec assez de plaisir dans leur système pour supporter une autre semaine.
Alors comment savez-vous quand vous éloigner de l’ordre de la chaîne ? Eh bien, vous réservez une session avec moi pour la démo. Mais il existe une autre solution (plus d’informations plus bas)…
Dans tous les cas, offrir aux utilisateurs plus d’options pour personnaliser l’interface utilisateur (et peut-être renforcer la fausse impression initiale que les modules ne sont que des boîtes GUI) ne va pas le résoudre. C’est en fait donner aux gens plus d’options pour se nuir. Ce que vous voulez et ce qui est bon pour vous…
Réexaminer le problème
Alors que Darktable s’est dégradé en un terrain de jeu pour les geeks où nouveau signifie mieux et où chaque problème appelle plus de code amusant, Ansel est là pour résoudre les problèmes simples de manière simple, en vue de produire un cheval de travail fiable. Alors repartons du sommet.
Nous avons 70 modules. Bien qu’Ansel ait déprécié une bonne partie d’entre eux, il y a encore «trop», au sens où ils sont tous utiles pour certaines fins mais vous n’en avez pas besoin tout le temps, et pas tous en même temps. De plus, l’espace d’écran est limité et nous ne pouvons vraiment pas présenter tous les modules en même temps. Et même si nous le pouvions, présenter un tableau de bord Airbus à votre photographe moyen ne serait pas gentil.
Nous devons donc choisir quels modules afficher à quel moment. Emphase sur moment.
Dérouler l’axe temporel
En suivant l’idée du juste à temps, il semble naturel que l’axe temporel soit scindé en étapes de workflow. Ainsi, la sélection de tous les modules visibles à un moment donné correspond à ceux dont vous aurez besoin maintenant et dans les prochaines minutes. En passant à la prochaine étape de workflow, vous passez dans l’interface GUI et changez la vue. C’est pour ainsi dire un diaporama.
Cela dessine un chemin linéaire à suivre, pour obtenir une structure et un guidage à partir de l’encombrement apparent. Les GUI ne sont pas seulement destinés à exposer des contrôles, ils sont également là pour enseigner, communiquer et faire connaître les possibilités disponibles.
Ainsi, chaque onglet est désormais une diapositive de notre diaporama de workflow, qui est étroitement lié à l’ordre de la chaîne. Et de la structure est apparue de l’encombrement.
Avec quelques exceptions. Par exemple, les modules de débruitage doivent se produire tôt dans la chaîne pour la cohérence du signal, mais ils apparaissent plus tard dans le workflow que, disons, la calibration des couleurs, car ils fonctionnent au niveau pixel et ne changeront pas généralement la teinte globale (à moins que vous ne rencontriez de graves dommages de bruit qui pourraient décaler l’axe vert/magenta, mais cela est typiquement au-dessus de 8000 ISO). Même chose avec les algorithmes de mise au point : aucun de ceux-ci ne changera de manière spectaculaire la luminosité, la teinte ou la chrominance de manière à invalider les réglages précédents (dans le sens du workflow) concernant les réglages globaux de couleur et d’exposition, et mes réglages appropriés dépendront également de combien vous avez monté l’exposition de l’image (aggravant ainsi la force visuelle du bruit). Ces exceptions à la règle sont expliquées par l’analyse numérique des filtres de pixels, ce qui signifie que les personnes qui n’ont pas lu le code source avec leur connaissance antérieure du traitement du signal n’auront aucune idée.
Mise en œuvre
Principe
- Étapes du workflow == onglets de module.
- Ces onglets portent des noms textuels, ce qui peut prendre plus de place dans le GUI mais vous n’avez pas besoin de lire une doc et/ou deviner leurs significations : c’est écrit sur l’étiquette. Étapes du workflow == onglets de module.
- Ces onglets portent des noms textuels, ce qui peut prendre plus de place dans le GUI mais vous n’avez pas besoin de lire une doc et/ou deviner leurs significations : c’est écrit sur l’étiquette. Étapes du workflow == onglets de module.
- Ces onglets portent des noms textuels, ce qui peut prendre plus de place dans le GUI mais vous n’avez pas besoin de lire une doc et/ou deviner leurs significations : c’est écrit sur l’étiquette.
- Les premiers et derniers onglets sont spéciaux
- Ils affichent respectivement la liste des modules activés (chaîne) et la liste complète des modules disponibles (tout). Les premiers et derniers onglets sont spéciaux
- Ils affichent respectivement la liste des modules activés (chaîne) et la liste complète des modules disponibles (tout). Les premiers et derniers onglets sont spéciaux
- Ils affichent respectivement la liste des modules activés (chaîne) et la liste complète des modules disponibles (tout).
- Tous les onglets ne sont pas immédiatement visibles
- Selon la largeur du panneau latéral, certains onglets seront cachés, ce qui est bien car vous allez les suivre de gauche à droite en séquence, donc vous n’avez pas vraiment besoin de savoir ce qui suit Tous les onglets ne sont pas immédiatement visibles
- Selon la largeur du panneau latéral, certains onglets seront cachés, ce qui est bien car vous allez les suivre de gauche à droite en séquence, donc vous n’avez pas vraiment besoin de savoir ce qui suit Tous les onglets ne sont pas immédiatement visibles
- Selon la largeur du panneau latéral, certains onglets seront cachés, ce qui est bien car vous allez les suivre de gauche à droite en séquence, donc vous n’avez pas vraiment besoin de savoir ce qui suit
- Dans les onglets, les modules sont organisés comme des couches dans l’ordre de la chaîne
- C’est-à-dire de bas en haut. C’est ainsi que vous devriez les définir. Donc, la pile de modules représente la pile d’effets/filtres/couches au-dessus de l’image brute. Dans les onglets, les modules sont organisés comme des couches dans l’ordre de la chaîne
- C’est-à-dire de bas en haut. C’est ainsi que vous devriez les définir. Donc, la pile de modules représente la pile d’effets/filtres/couches au-dessus de l’image brute. Dans les onglets, les modules sont organisés comme des couches dans l’ordre de la chaîne
- C’est-à-dire de bas en haut. C’est ainsi que vous devriez les définir. Donc, la pile de modules représente la pile d’effets/filtres/couches au-dessus de l’image brute.
Résumé : suivez l’ordre GUI de gauche à droite, et de bas en haut (car ce sont des couches), et vous avez votre workflow sans lecture fastidieuse de la doc.
Les modules de la chambre noire peuvent être réordonnés dans n’importe quel onglet en maintenant Ctrl+Shift2 tout en effectuant un glisser-déposer avec la souris, sur les en-têtes de module. Soyez conscient que cela réorganise également les modules dans la chaîne, ce n’est pas à utiliser comme une commodité GUI. Il est préférable de le faire dans les onglets “chaîne” ou “tout”, où vous avez un aperçu complet du contenu de la chaîne.
Remplacement des modules favoris
La conception actuelle n’a pas de moyen de définir des modules favoris dans un onglet spécial. Je ne vois pas l’intérêt d’ajouter plus de fioritures pour résoudre le problème d’avoir initialement des fioritures.
Pour ces modules spéciaux, vous pouvez attribuer des raccourcis aux événements “afficher” (alias ouvrir, afficher, déplier) ou “activer” (alias activer). Allez dans le menu Modifier, puis en bas cliquez sur Raccourcis clavier, puis avec le curseur spécial que vous avez, cliquez sur votre futur module préféré en-tête (sur son nom). Exemple ici avec le module d’exposition :

Par défaut, vous serez invité avec l’événement “afficher”, dans la colonne des éléments (un autre label que je devrais changer). Vous pouvez le modifier pour l’événement “activer” ou “instance” (alias instancier). L’effet n’a pas d’amplitude pour celui-ci, je n’ai pas testé dans quel cas il est utilisé et l’ensemble est un gâchis comprimé de toute façon.
Dans tous les cas, ces raccourcis vous amèneront instantanément à vos modules préférés sans polluer davantage l’espace GUI.
Conclusion
Cela ne résout pas le problème des modules appelés quelque chose d’inintéressant pour les utilisateurs, et des modules de traitement d’image ayant la même apparence que ceux non destinés au traitement image. J’ai quelques idées à ce sujet, mais ce sera pour une autre fois.
Notes de côté
De nombreux autres outils précédemment cachés dans des boutons-icônes cryptiques ont été fusionnés dans le menu global. Ce menu peut être déplié en appuyant sur Alt suivi de la lettre mnémonique du menu (qui sera soulignée après avoir appuyé sur Alt). Une fois dépliés, les menus peuvent être navigués avec les touches fléchées.
Retourner à la table lumineuse est maintenant mappé sur la touche Échap/Retour. Dans la table lumineuse, la recherche de texte pour image est également mappée sur Ctrl+F (comme on pourrait s’y attendre). Parcourir les images peut se faire avec les touches Flèche, la sélection avec la touche Espace, et ouvrir une image en chambre noire peut être fait en appuyant sur la touche Entrer.
Cela signifie que l’application est maintenant presque entièrement navigable avec le clavier sans avoir à se rappeler les raccourcis. Ces raccourcis sont affichés de toute façon dans le menu, à droite des entrées.
Le tableau de tous les raccourcis peut maintenant être trouvé dans le menu Aide, précédemment il n’était accessible que… via un raccourci.
Translated from English by : Aurélien Pierre, ChatGPT. In case of conflict, inconsistency or error, the English version shall prevail.
And I mean “idiot-proof” in a “prevent pouring water into the acid” way, not in a “cancel chemistry labs because acid can burn” way. It’s not idiot-proof if the idiot is not allowed to do anything. ↩︎
It’s shitty but that’s because Gtk’s way of handling drag and drop events sucks. ↩︎