Les développeurs d'Ansel, un logiciel de retouche photo open source dérivé de Darktable, ont annoncé une refonte complète de leur pipeline de rendu. Cette mise à jour, publiée entre le 29 mars et le 6 avril 2026, répond à des limitations historiques liées à la gestion de la mémoire et à l'architecture du pipeline, héritées de Darktable. L'objectif affiché est d'optimiser l'utilisation de la RAM et d'éviter des calculs redondants qui nuisaient aux performances, notamment sur les ordinateurs portables fonctionnant sur batterie.

Problèmes hérités de Darktable

Selon l'équipe d'Ansel, dès les débuts de Darktable vers 2012, l'application utilisait très peu de mémoire vive. Si une utilisation parcimonieuse est souvent perçue comme positive pour un environnement de bureau, elle devient un inconvénient pour un logiciel de production manipulant des images de 12 à 54 mégapixels. Le problème est que les mêmes calculs lourds sont effectués à plusieurs reprises au lieu d'être mis en cache pour être réutilisés. Or, la mise en cache est précisément conçue pour éviter des calculs coûteux, et elle devrait utiliser toute la RAM disponible, car le calcul sollicite le processeur et la batterie, alors que la mémoire vive ne consomme quasiment pas d'énergie.

Le projet Ansel souligne que les photojournalistes et les nomades numériques retouchent souvent leurs photos sur des ordinateurs portables alimentés par batterie, sur le terrain. Il est donc essentiel que les logiciels open source prennent en compte cette réalité et optimisent la consommation d'énergie.

Dans Darktable, un paramètre de RAM permettait de définir la quantité de mémoire à utiliser, mais il n'existait aucun moyen de suivre la consommation réelle de RAM. Ce paramètre a ensuite été remplacé par une préférence qualitative jugée « idiote » par l'équipe d'Ansel, qui ne renseigne pas réellement sur la quantité de mémoire allouée. En conséquence, le cache n'a jamais vraiment fonctionné et tout était recalculé en permanence.

Une refonte nécessaire

L'équipe d'Ansel explique que la sous-utilisation du cache provenait d'un manque de visibilité sur le cycle de vie des données, condition préalable à la mise en cache. Cela découlait d'un pipeline de pixels « vraiment alambiqué » (l'article émet des doutes sur la capacité de quiconque à dessiner un schéma complet du traitement des pixels chez les développeurs de Darktable) et de métadonnées d'image calculées, copiées et stockées à plusieurs endroits.

Le cache du pipeline avait pour objectif d'allouer des tampons d'entrée et de sortie pour les modules et éventuellement de les réutiliser. Mais sa taille était définie en nombre d'entrées, très limitée, et non en quantité de mémoire allouée, ce qui le rendait peu utile et forçait une utilisation trop conservatrice.

Il est donc apparu que « corriger le cache » impliquait de « corriger le pipeline », ce qui impliquait de « rendre le cycle de vie des données visible, traçable et géré globalement », ce qui a nécessité une refonte de l'architecture de haut en bas. Cette refonte a eu des bénéfices inattendus sur les performances, dépassant largement les optimisations internes par module effectuées parallèlement par Darktable.

Ce qui a changé depuis 2022

Cet article fait suite à une précédente publication intitulée « Correction du cache du pipeline et de bugs vieux de dix ans » (Fixing the pipeline cache and 10-year-old bugs). Ce premier chapitre avait pour but de localiser les problèmes les plus graves et d'arrêter les défaillances les plus embarrassantes. Le nouveau chapitre décrit la suite, lorsque les développeurs ont réalisé que les bugs du cache n'étaient pas des bugs isolés, mais les symptômes d'un moteur de rendu dont les responsabilités étaient mélangées depuis trop longtemps.

Le problème initial n'était pas simplement que le cache ne mettait pas assez en cache. Le problème réel était que toute la pile du pipeline s'était développée autour d'un comportement accidentel : les rafraîchissements de l'interface graphique pouvaient déclencher le traitement d'images de manière non régulée. Les aperçus de masques, par exemple, entraînaient des calculs superflus.

La nouvelle architecture permet une gestion centralisée et prévisible du cycle de vie des données. Le cache utilise désormais toute la RAM disponible selon les besoins, réduisant les recalculs inutiles et améliorant la réactivité, notamment pour les photographes travaillant sur le terrain.

L'équipe d'Ansel conclut que cette refonte est une étape cruciale pour offrir un outil performant et écoénergétique, adapté aux usages professionnels mobiles.