Aurélien Pierre

Le logiciel libre tourne sur deux transactions à sens unique. Les utilisateurs prennent le produit sans rien donner en retour, parce que trois siècles de marché nous ont appris qu’une chose téléchargeable à l’infini n’a pas de prix. Les développeurs décident sans répondre à personne, parce que la licence dit qu’ils ne doivent rien — pas même une explication. D’un côté on prend sans payer, de l’autre on règne sans rendre de comptes. Ce ne sont pas deux problèmes : c’est le même, vu de ses deux bouts, et l’essentiel de ce qui ne va pas dans le logiciel libre pousse dessus.

Connaître le public est la première étape de la conception, et déclarer la portée est la première étape de la gouvernance : chaque demande, signalement de bug et contribution est mesuré contre cette page. Il y a deux façons honnêtes de critiquer le projet. Le tenir à ce que cette page promet — cette critique-là est toujours recevable, et le projet ne peut pas l’écarter sans se contredire. Le mesurer à un objectif qu’il n’a jamais adopté — c’est alors un souhait, recevable comme souhait et refusable comme tel. Cette page existe pour que chacun puisse distinguer l’un de l’autre.

Ce code protège deux groupes de deux dangers. Il protège les utilisateurs — y compris les non-techniciens, les non-anglophones, le débutant entré par hasard — d’être traités comme des programmeurs ratés. Et il protège les gens qui font le travail de la pression d’une foule qui les dépasse en nombre de mille contre un. La plupart des codes de conduite ne regardent que dans une direction ; celui-ci refuse de choisir, parce que le projet a vu ce que coûte chacune des deux.

Tout est public dans l’open-source : le code, les bugs, les demandes, la discussion. Tout le monde peut s’inviter — ce qui est une force seulement si la conversation est disciplinée, et un désastre au ralenti sinon. Cette page est la discipline. Ce n’est pas de l’étiquette : chaque règle ici existe parce que sa violation a un coût mesurable en travail perdu, et le protocole de signalement des bugs comme le protocole de conception sont bâtis dessus.

Un signalement de bug est un témoignage : ce que vous avez fait, ce qui s’est passé, ce que vous attendiez. C’est tout ce que le projet vous demande — la traduction en causes, en diagnostics et en correctifs est notre travail, pas le vôtre. Vous ne serez jamais blâmé de ne pas connaître les ordinateurs, d’écrire un anglais imparfait, ou d’un signalement qui se révèle être un problème de documentation : un utilisateur qui ne parvient pas à suivre une instruction technique a trouvé un défaut de conception ou de documentation, pas commis une faute personnelle (code de conduite).

Quelles ressources peuvent être trouvées en ligne et dans les bibliothèques pour aider à comprendre un peu de théorie de la couleur ?

Cette page regroupe la plupart des erreurs et des idées fausses sur Ansel que l’on peut trouver sur internet.

Cet article documente les mathématiques actuellement implémentées dans le module diffuse or sharpen d’Ansel, telles qu’on les trouve dans src/iop/diffuse.c, src/common/bspline.h, data/kernels/diffuse.cl et data/kernels/bspline.cl. Il ne s’agit pas d’un guide d’utilisation. C’est une reconstruction du modèle numérique à partir du code source, avec les affirmations scientifiques rattachées aux références citées dans les commentaires du code.¹

Cet article présente les mathématiques de la reconstruction des hautes lumières d’Ansel : la conception originale des guided laplacians de 2021, dont les idées générales n’avaient jamais été qu’esquissées sur le forum pixls.us,¹ et la transposition harmonique, la méthode qui l’a remplacée après qu’une étude sur vérité terrain a mis au jour un bug de récupération de la magnitude.² Il est organisé de sorte que chaque lecteur trouve sa section : les résultats et l’Intuition & contexte de chaque méthode ne demandent aucune mathématique ; les développeurs trouveront les sous-sections Implémentation & optimisations et l’étude de performance ; les conclusions théoriques et l’annexe cimetière sont écrites pour être réutilisables en dehors de la photographie ; et comment ce travail a réellement été mené documente le protocole de recherche homme–machine qui le sous-tend.

Ansel n’est pas un projet de loisir. C’est un outil de travail conçu pour accomplir des tâches, et le pacte l’engage à des responsabilités qu’un loisir ne porte jamais. Le financement est votre moitié de ce pacte : le projet répond de vos besoins ; les conditions de travail de ceux qui le font sont, en retour, en partie les vôtres. Quelle est la différence avec un projet de loisir ?

Linux accuse toujours un retard considérable sur MacOS et même sur Windows lorsqu’il s’agit d’assurer la cohérence des couleurs affichées à l’écran. L’adoption largement imposée du serveur graphique Wayland dans la plupart des distributions Linux a encore aggravé cet état de fait, la gestion des couleurs ayant longtemps été refusée par les développeurs de Wayland. La spécification d’un CMS dans Wayland a finalement été ébauchée en 2020 et le code a été intégré en amont dans Wayland en 2025, par des contributeurs externes, et après une longue bataille des développeurs des logiciels de CMS antérieurs contre les développeurs historiques de Wayland.¹ Depuis, l’état de la prise en charge du CMS est très aléatoire selon les environnements de bureau et les distributions. Et pourtant, les résultats préliminaires de la télémétrie d’Ansel montrent une adoption de Wayland à hauteur de 67 % parmi les utilisateurs d’Ansel.

Jiyoné (Guillaume Stutin) a repris la maintenance d’Ansel depuis octobre 2025. L’objectif actuel est de transformer Ansel en une coopérative  où les utilisateurs peuvent devenir membres et contrôler démocratiquement les orientations et les priorités du projet, mais aussi garantir une rétribution équitable et un environnement de travail sûr à celles et ceux qui consacrent leur force de travail au projet. J’ai exposé la description du problème et la solution proposée sur la page démocratie.

Entre janvier 2022 et mars 2026, Ansel a intégré 297 commits (hors fusions) concernant la grille de la table lumineuse, ses vignettes, ainsi que leur pipeline de rendu et leur mise en cache. J’ai essayé de me contenter du code brouillon de la table lumineuse de Darktable, seulement dégraissé, aussi longtemps que j’ai pu mais malheureusement, ce n’était que de la dette technique pure et c’était atrocement lent.

En effet, Darktable « gère » la médiocrité de sa table lumineuse en réduisant sa taille : les panneaux latéraux gauche et droit occupent une grande surface d’affichage, ce qui laisse encore moins de place à repeindre pour la table lumineuse. Comme Ansel a supprimé le panneau latéral droit, fusionnant son contenu avec celui de gauche et le menu global, il y avait plus de surface à peindre, plus de travail CPU à effectuer, et la conception désastreuse de la table lumineuse en devenait d’autant plus nuisible.

Depuis que j’ai commencé à utiliser Darktable, vers 2012, j’ai toujours été surpris par la très faible quantité de RAM qu’il utilisait. Les gens pensent qu’il est bon qu’une application utilise la mémoire avec parcimonie, et c’est certainement vrai lorsqu’on parle de votre environnement de bureau. Mais pour un logiciel de production qui fait du rendu pixel lourd sur des images de 12 à 54 mégapixels, cela signifie que les mêmes calculs coûteux sont refaits encore et encore au lieu d’être enregistrés pour être réutilisés plus tard. C’est précisément à cela que sert un cache : éviter des calculs coûteux. Et il devrait utiliser toute la RAM disponible pour cela, parce que calculer gaspille de l’énergie, ce qui a un impact concret si vous travaillez sur batterie. En plus, vous avez payé cette RAM et l’utiliser ne vide pas votre batterie. Le CPU et le GPU, eux…

Mémoires d’un type qui a passé beaucoup trop de temps à nettoyer la merde des autres et à payer pour leurs mauvaises décisions, épisode #trop.

Le copier-coller d’historique et les styles sont des fonctionnalités centrales d’Ansel, et celles qui lui font mériter, ou non, son titre d’« application de workflow ». Mais c’est aussi l’une des choses les plus difficiles à bien faire en interne. Les utilisateurs voient une liste de retouches, mais sous le capot ces retouches dépendent de l’ordre du pipeline, des instances de modules et des masques. Si deux images ont des topologies de pipeline différentes, copier naïvement les retouches peut produire des incohérences.

Dans mon billet fondateur Darktable : dans le mur au ralenti, j’ai présenté le désastre qu’a été le nouveau « grand turducken MIDI ». Le but de ce turducken¹ était de réécrire le système de raccourcis clavier pour l’étendre aux périphériques MIDI.

À ce jour, je suis encore furieux contre cette entreprise de destruction massive. Voici un récapitulatif des raisons :

1. il a remplacé en 2021 un système de raccourcis clavier qui était plutôt bon, complet, bien testé, stable et codé en moins de 1 500 lignes (commentaires compris),
2. …pour ajouter la prise en charge des périphériques MIDI et des manettes PlayStation (!?!)…
3. …mais dans mon enquête Darktable de 2022, un an après cette nouvelle fonctionnalité, sur 1 251 utilisateurs participants :
   • 81 % des utilisateurs n’avaient pas de périphérique MIDI et n’en prévoyaient pas,
   • 2 % ne savaient même pas ce qu’était un périphérique MIDI,
   • 8 % des utilisateurs avaient un périphérique MIDI mais ne l’utilisaient pas avec Darktable,
   • 6 % envisageaient peut-être d’acheter un périphérique MIDI à l’avenir,
   • 2 % des utilisateurs avaient un périphérique MIDI qu’ils utilisaient réellement avec Darktable,
4. le code était absolument terrible, en termes de :
   • qualité de code : des instructions if/switch-case illisibles imbriquées sur 4 niveaux, au milieu de fonctions de 1 000 lignes (j’ai publié des extraits d’exemple dans mon article),
   • volume de code :
     • 3 546 lignes de code pour Darktable 4.0,
     • 4 397 lignes de code pour Darktable 5.0,
     • l’augmentation du volume est une conséquence directe des tentatives de correction de bugs dans une architecture qu’on ne peut pas corriger parce que sa complexité produit davantage de complexité. Tout cela vient de la conception, mais résoudre des problèmes créés par la complexité en ajoutant encore plus de complexité n’est pas une solution.
   • complexité du code :
     • complexité cyclomatique  :
       • 1088 pour Darktable 4.0,
       • 1245 pour Darktable 5.0 (détails ),
     • complexité cognitive  :
       • 1885 pour Darktable 4.0,
       • 2098 pour Darktable 5.0 (détails ).
     • c’est de loin la fonctionnalité la plus complexe du logiciel, alors même qu’elle ne traite pas les images. À titre de comparaison, la deuxième fonctionnalité la plus complexe est le décodage des métadonnées EXIF, avec une complexité cognitive de 1348.
5. il ne décode pas les modificateurs de touches par conception, mais ne traite que les frappes matérielles, ce qui signifie :
   • que l’entrée « 1 » du pavé numérique est décodée en Keypad End,
   • que l’entrée « 1 » d’un clavier AZERTY français est décodée en Shift+&, ou en Shift+" en BÉPO,
   • vous devez donc dupliquer tous vos raccourcis basés sur des chiffres pour chaque manière de saisir un nombre, et vous préparer à ce que la fenêtre de configuration des raccourcis ne contienne aucun chiffre réel dans les combinaisons de touches.
6. la conception côté utilisateur est absolument affreuse, avec beaucoup trop d’actions et d’émulations à configurer (« effets »), qui ne sont même pas entièrement documentées 4 ans plus tard (qu’est-ce que « ctrl-toggle » ? « right-activate » ?), et la configuration des raccourcis utilise une étrange fenêtre scindée qui n’a aucun sens,
7. l’implémentation est elle aussi terrible : la fonctionnalité connaît toute l’interface graphique du logiciel, et l’interface graphique du logiciel connaît le code des raccourcis. Il n’y a ici aucune modularité, et modifier quoi que ce soit dans le code des raccourcis peut avoir des effets inattendus et indésirables partout dans le logiciel.² Il suffit de voir le graphe de dépendances ci-dessous,
8. plusieurs « raccourcis » (ou assignations MIDI) peuvent être attachés à une même action, ce qui signifie que chaque interaction utilisateur doit parcourir toute la liste des actions disponibles, entraînant une gestion des raccourcis très inefficace, des lags dans l’interface dans certains cas et des faux positifs « combinaison de touches inconnue » dans des cas particuliers.

Après avoir finalement câblé tout le site web et la documentation à un flux de travail de traduction étanche (en utilisant po4a par-dessus Hugo), qui utilise exactement les mêmes outils et logique que l’application Ansel, j’ai eu l’idée de traduire automatiquement les traductions vides, d’abord à partir des fichiers de traduction logicielle, puis via l’API ChatGPT, qui fait un très bon travail pour traduire la syntaxe Markdown.

Travaillant seul, vous ne pouvez pas compter sur la paresse sociale , donc vous devez être astucieux. Vous pouvez consulter la liste des choses que j’ai déjà automatisées en arrière-plan pour Ansel.

Alain Oguse a appris le tirage photographique avec Claudine  et Jean-Pierre Sudre  à la fin des années 1960, et a effectué son début de carrière en photographie commerciale. Après avoir pris sa retraite, il a commencé à chercher des méthodes permettant de retrouver le grain argentique dans les numérisations de négatifs, avec la même netteté et qualité que ce qu’il obtenait en lumière quasi-ponctuelle sous l’agrandisseur, dans les années 1970.

En décembre 2019, j’ai demandé à quelqu’un de s’occuper de fournir des packages AppImages  pour Darktable. Le bénéfice évident aurait été de permettre des tests anticipés, avant la sortie, de la part de personnes qui ne peuvent pas construire le code source elles-mêmes, afin de fournir espérons-le des retours précoces et aider à déboguer avant la publication. Cela n’a jamais été une priorité, ce qui signifie qu’il était acceptable d’avoir une ruée avant et après la sortie pour corriger les bugs.

Nous savons tous ce qu’est le “blanc”. On peut se représenter une feuille de papier. Nous savons qu’elle est blanche parce que nous l’avons appris. Mais si vous placez la feuille de papier sous un soleil d’été, ou sous un ciel nuageux, ou à la maison équipée d’ampoules domestiques chaudes, ce blanc va changer de couleur. Cela pourrait vous déranger pendant les premières secondes, puis vous oublieriez rapidement : votre cerveau va adapter. Mais (s’)adapter (à) quoi ?

Cela s’appliquera à Darktable en amont comme à Ansel car ils partagent la majeure partie de leur pipeline de couleurs. La procédure suivante vous aidera à résoudre vos problèmes de couleur, qu’il s’agisse d’une apparence incohérente entre l’exportation et l’aperçu, ou entre écran et imprimé, ou entre 2 applications.

Ansel hérite de Darktable son infrastructure de base de données : les historiques de modifications non destructifs sont sauvegardés image par image dans une base de données SQLite, avec les métadonnées et autres données définies par l’utilisateur. Pour intégrer de nouvelles images à la base de données, il faut « importer » ces images depuis un disque ou une carte mémoire. C’est à cela que sert l’outil d’importation.

Malheureusement, l’importateur de Darktable est une autre fonctionnalité qui a été massacrée autour de 2020 pour devenir quelque chose de profondément déroutant : un navigateur de fichiers ne ressemblant à aucun navigateur connu jusqu’alors, qui parvient à manquer de fonctions de base (comme Ctrl+F ou un aperçu EXIF) tout en étant encombré d’options inutiles (voir ci-dessous). C’est ainsi que nous perdons beaucoup d’utilisateurs potentiels dès l’étape zéro du flux de travail. Quel bel exemple de ce qu’une « application de workflow » peut faire !

J’ai pensé, pendant très longtemps, qu’il y avait un mécanisme de bouton d’arrêt sur le pipeline de pixels. Le cas d’utilisation est le suivant :

1. vous modifiez un paramètre de module,
2. les aperçus (celui de la chambre noire central et la vignette dans le panneau de gauche, également utilisé pour l’histogramme et les sélecteurs de couleurs) reconstruisent leur pipeline pour tenir compte de ce changement,
3. l’un des aperçus finit de se rendre avant l’autre, et le résultat n’est évidemment pas celui que vous vouliez,
4. vous modifiez à nouveau le paramètre du module, sans attendre la fin de la recomputation.

Dans ce cas, vous souhaitez annuler tous les pipelines actifs car leur résultat ne sera pas utilisé, et commencer immédiatement à tout recalculer avec les nouveaux paramètres. Sauf que Darktable ne fait pas ça, il laisse le pipeline se terminer avant de le redémarrer, et en regardant les commentaires dans le code source, il semble que ce soit une régression assez récente et non le comportement initialement prévu.

Darktable a sa propre bibliothèque d’objets GUI, pour les curseurs et les comboboxes (alias menus déroulants ou boîtes de sélection), appelée Bauhaus (dans le code source, c’est dans src/bauhaus/bauhaus.c). Bien qu’ils utilisent Gtk en tant que moteur arrière, les objets Bauhaus sont des objets personnalisés. Et comme beaucoup de choses dans Darktable, personnaliser signifie pourri.

En 2022, ‍j’ai remarqué des redessinages parasites et des lenteurs , lors de leur utilisation, conduisant à une expérience utilisateur frustrante : le redessinage des widgets semblait attendre la conclusion des recalculs de la chaîne, ce qui signifiait que les utilisateurs n’étaient pas vraiment sûrs que leur changement de valeur était pris en compte, ce qui pouvait les amener à réessayer, déclenchant un autre cycle de recalcul coûteux, et gelant effectivement leur ordinateur pendant plusieurs minutes frustrantes d’intermédiaires coûteux recalculs de la chaîne.

Rawspeed (la bibliothèque fournissant les décodeurs pour les fichiers raw des appareils photo) a déprécié le support pour GCC < 12. En conséquence, je ne peux plus construire le AppImage sur Ubuntu 20.04 (en utilisant Github runners) mais je dois le construire sur 22.04.

Cela signifie que toute distribution Linux ayant une libc antérieure à 2.35 ne pourra pas démarrer les nouveaux AppImages à partir d’aujourd’hui. Cela ne devrait pas affecter la plupart des utilisateurs exécutant des distributions mises à jour en 2021 ou plus récemment. Ubuntu 20.04 et d’autres distributions LTS/stables anciennes (Debian stable) pourraient être affectées.

Le flux de travail relatif à la scène promet une retouche indépendante du medium de sortie. Il va typiquement produire une image encodée en sRGB sur 8 bits, c’est à dire des valeurs codées entre 0 et 255. Pour simplifier, nous allons nous limiter au cas 8 bits dans la suite. Les concepts demeurent en 16 bits, la différence est que la plage d’encodage va de 0 à 65535, ce qui est un détail.

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.

J’ai découvert par accident que le script de build Linux utilisait un package build, ce qui signifiait que les optimisations CPU étaient limitées à des optimisations génériques afin de produire des binaires portables pouvant être installés sur n’importe quelle plateforme x86-64. Par ‘utiliser’, je veux dire que le build package n’était pas explicitement désactivé, donc il était activé par défaut.

De toute façon, cela est maintenant désactivé par défaut, puisque les packages réels (.exe et .appimage) ne sont pas construits via ce script, qui est principalement destiné à aider les utilisateurs finaux. Pour revenir à l’ancien comportement, vous devrez exécuter :

2022 a été si mauvaise en termes de courriels indésirables et de bruit que j’ai commencé la Secrétaire Virtuelle , un cadre Python pour écrire des filtres de courriels intelligents en croisant des informations provenant de plusieurs sources pour deviner ce que sont les courriels entrants et s’ils sont importants/urgents ou non. Quand je parle de courriels indésirables, il s’agit aussi des notifications Github, des pings sur pixls.us (heureusement, j’ai fermé mon compte sur ce forum stupide), YouTube et des courriels directs de personnes espérant obtenir de l’aide en privé.

Voici comment démarrer avec la retouche dans Ansel, en passant par les étapes les plus basiques qui vous serviront fidèlement dans la plupart des cas.

Cette video a été enregistrée sur Darktable 3, mais les mêmes modules et principes s’appliquent à Ansel.

Cet article montre comment effectuer un ton monochrome sur des images numériques dans Ansel, afin d’émuler le rendu des couleurs des développements type cyanotype, platinotype, sépia et virage partiel.

Cela fait environ 3 mois que j’ai rebrandé “R&Ddarktable” (ce que personne ne semble comprendre), en “Ansel”, puis acheté le nom de domaine et créé le site web de zéro avec Hugo (je n’avais jamais programmé en Golang auparavant, mais il s’agit principalement de code de modèle).

Il me reste alors un total de 70 heures pour faire fonctionner les builds packaуs nocturnes pour Windows et Linux pour une livraison continue, ce que Darktоrque n’a jamais bien fais (« tu peux compléter toi-même, ce n’est pas difficile »), seulement pour voir le traqueur de bugs exploser après la sortie (rien de mieux que de chaîner le sprint pré-sortie avec un sprint post-sortie pour réduire votre espérance de vie.)

Qu’est-ce qui se passe quand une bande de photographes amateurs, devenus développeurs amateurs, rejoints par une poignée de développeurs back-end qui développent de la librairie pour développeurs, se décide à travailler sans méthode ni structure sur un logiciel métier pour utilisateur final dont le cœur de compétence (colorimétrie et psychophysique) se situe quelque part entre un BTS photo et un BAC+5 en sciences appliquées, tout en se promettant de sortir 2 versions par an sans gestion de projet ? Tout ça bien sûr dans un projet logiciel dont les fondateurs et la première génération de développeurs sont passés à autre chose ?

Dans cet article, vous apprendrez ce qu’est le flux de travail relatif à la scène, comment Ansel l’utilise et en quoi il profite au traitement d’image numérique en général.