Jiyoné (Guillaume Stutin) has taken over Ansel maintainance since october 2025. The current goal is to turn Ansel into a cooperative where users can become members and democratically control the project orientations and priorities, but also guarantee a fair retribution and safe working environment for those who commit their workforce to the project. I have layed out the description of the problem and the proposed solution on the democracy page.
Compiling the software natively on the computer use to improve runtimes on CPU by around 30 %, compared to pre-built packages. The reason is the compiler makes specific optimizations for the target hardware on which it is compiled, while pre-built packages have to stay generic and trigger more conservative optimization for the sake of wide support. Note that OpenCL kernels are, anyway, compiled for your particular GPU using your OpenCL driver, so the story is different there.
In his book, The Technological Society (1954), Jacques Ellul presents the difference between the pre- and post-industrial revolution as follows:
The pre-industrial era is the reign of the tool and of craftsmanship. The foremost property of tools is to be generic, versatile, and adaptable. It is up to the craftsman to develop his skills to make the tools follow his intent, so the hand will make up for the limitations of the instrument. This concept is still well known to musicians today: you have to practice, learn, try, fail, retry… there are no shortcuts. Ellul emphasizes the idea of parsimony that comes with tools: resources are limited, so your toolset is pretty much defined by what you can afford, carry, master, and build locally. Trends change slowly and are local, because they use local resources and adapt to local needs, and tools follow the same pattern. Tools are heirlooms passed from master to apprentice, from parent to child. They don’t get incompatible or outdated.
Between January 2022 and March 2026, Ansel landed 297 non-merge commits regarding the lighttable grid, its thumbnails, and their rendering pipeline and caching. I tried to make do with the scruffy Darktable lighttable code, only degreased, for as long as I could but unfortunately, it was pure technical debt and it was painfully slow.
Indeed, Darktable “manages” the crappiness of its lighttable by reducing its size: the left and right side panels take a lot of display surface, which leaves even less area for the lighttable to repaint. Since Ansel removed the right side panel, merging its content with the left one and the global menu, there was more surface to paint, more CPU work to do, and the terrible design of the lighttable became all the more harmful.
Since I started using Darktable, circa 2012, I have always been surprised by how little RAM it used. People think it is a good thing that an application uses the memory sparingly, and that is surely true if we talk about your desktop environment. But talking of a production software that does heavy pixel rendering on images from 12 to 54 Mpixels, this means the same heavy computations are done again and again instead of being saved to be reused later. That’s what a cache is for : avoiding expensive computations. And it should use all the available RAM for that, because computing is wasting power, and that has a concrete impact if you are working on battery. Also, you paid for that RAM and using it doesn’t empty your battery. The CPU/GPU on the other end…
Memoirs of a guy who spent too much time cleaning other people’s shit and paying for their bad decisions, episode #too many.
Copy/paste history and styles are core features in Ansel, and the one that makes it deserve (or not) its “workflow app” title. But it is also among the hardest to get right internally. Users see a list of edits, but under the hood those edits depend on the pipeline order, module instances, and masks. If two images have different pipeline topologies, naïvely copying edits can produce inconsistencies.
In my defining post, Darktable: crashing into the wall in slow-motion, I presented the trainwreck that the new “Great MIDI turducken” was. The purpose of this turducken1 was to rewrite the keyboard shortcuts system to extend it for MIDI devices.
To this day, I’m still mad about this enterprise of mass-destruction, here is a recap of he the reasons:
if/switch-case statements nested on 4 levels, in the middle of 1000-lines functions (I posted example snippets in my
article),Keypad End,Shift+&, or Shift+" on BÉPO,
The dependency graph of src/gui/accelerators.c (Great MIDI turducken) before the rewrite. Guess why we call it “spaghetti code "… This makes it clear that there is a double-sided dependency between the accels code and the rest of the GUI code. This is a nightmare to maintain.
Nachdem ich endlich die gesamte Website und die Dokumentation in einen wasserdichten Übersetzungs-Workflow (unter Verwendung von po4a über Hugo) integriert hatte, der zufällig das exakt gleiche Toolset und die gleiche Logik wie die Ansel-Anwendung verwendet, kam mir die Idee, leere Übersetzungen zu automatisieren, zuerst aus den Software-Übersetzungsdateien, dann über die ChatGPT-API, die bei der Übersetzung von Markdown-Syntax durchaus einen guten Job macht.
Wenn man allein arbeitet, kann man sich nicht auf soziale Faulheit verlassen, also muss man clever sein. Du kannst die Liste der Dinge, die ich bereits im Hintergrund für Ansel automatisiert habe, sehen.
Im Dezember 2019 habe ich darum gebeten, dass jemand die Erstellung von AppImages-Paketen für Darktable übernimmt. Der offensichtliche Vorteil wäre gewesen, frühe Tests zu ermöglichen, vor der Veröffentlichung, von Menschen, die den Quellcode nicht selbst erstellen können, um hoffentlich frühes Feedback zu liefern und beim Debuggen vor der Veröffentlichung zu helfen. Dies war nie eine Priorität, was bedeutet, dass es in Ordnung war, einen Vorveröffentlichungs- und eine Nachveröffentlichungsspur zu haben, um Bugs zu beheben.
…
Ansel erbt von Darktable seine Datenbankgrundlage: Die nicht-destruktiven Bearbeitungshistorien werden pro Bild in einer SQLite-Datenbank gespeichert, zusammen mit Metadaten und anderen benutzerdefinierten Daten. Das Bewusstmachen der Datenbank für neue Bilder erfolgt durch das „Importieren“ von Bildern von einer Festplatte oder einer Speicherkarte. Hier kommt das Importwerkzeug ins Spiel.
Leider ist der Darktable-Importer eine weitere Sache, die um das Jahr 2020 verstümmelt wurde und sich in etwas äußerst Verstörendes verwandelte, da er ein Datei-Browser ist, der keinem zuvor bekannten Datei-Browser ähnelt und grundlegende Funktionen (wie Strg+F oder EXIF-Vorschau) vermisst, während er dennoch mit nutzlosen Funktionen überladen ist (siehe unten). Hier verlieren wir viele potenzielle zukünftige Benutzer, und es ist nur der erste Schritt des Workflows. Was für ein großartiges Beispiel dafür, was eine „Workflow-App“ leisten kann!
Ich habe lange gedacht, dass es einen Abbruchmechanismus in der Pixel-Pipeline gibt. Der Anwendungsfall ist folgender:
In diesem Fall möchten Sie alle aktiven Pipelines beenden, weil deren Ausgabe nicht verwendet wird, und alles sofort mit neuen Parametern neu berechnen. Außer Darktable tut das nicht, es lässt die Pipeline beenden, bevor sie neu startet, und angesichts der Kommentare im Quellcode scheint es sich um eine relativ neue Regression zu handeln und nicht um das ursprünglich beabsichtigte Verhalten.
Darktable hat seine eigenen GUI-Widgets-Bibliothek für Schieberegler und Kombinationsboxen (auch Drop-Down-Menüs oder Auswahllisten genannt), genannt Bauhaus (im Quellcode unter src/bauhaus/bauhaus.c). Während sie Gtk als Backend verwenden, sind Bauhaus benutzerdefinierte Objekte. Und wie vieles bei Darktable, gleich benutzerdefiniert verfault.
Im Jahr 2022 bemerkte ich Parasiten-Neuzeichnungen und Lags bei deren Nutzung, was zu einem frustrierenden Benutzererlebnis führte: Das Widget-Neuzeichnen schien darauf zu warten, dass Pipeline-Berechnungen abgeschlossen waren, was bedeutete, dass Benutzer nicht wirklich sicher waren, ob ihre Wertänderung registriert wurde, was sie dazu bringen könnte, es erneut zu versuchen, einen weiteren Zyklus teurer Neuberechnungen zu starten, und ihren Computer tatsächlich für mehrere sehr frustrierende Minuten nutzloser Zwischenpipeline-Berechnungen einfror.
Rawspeed (die Bibliothek, die die Decoder für Kamera-Rohdateien bereitstellt) hat die Unterstützung für GCC < 12 eingestellt. Infolgedessen kann ich das AppImage nicht mehr auf Ubuntu 20.04 (mithilfe von Github-Runners) erstellen, sondern muss es auf 22.04 erstellen.
Das bedeutet, dass jede Linux-Distribution mit einer älteren libc als 2.35 das neue AppImage ab heute nicht mehr starten kann. Das sollte die meisten Benutzer nicht betreffen, die Distributionen verwenden, die 2021 oder neuer aktualisiert wurden. Ubuntu 20.04 und andere LTS/alte stabile Distributionen (Debian stable) könnten betroffen sein.
Wenn Sie von Darktable kommen, sind Sie vielleicht an dies im Dunkelkammer-Modus gewöhnt:
während Ansel Ihnen dies bietet:
Dies ist kein Unfall, und es ist an der Zeit zu erklären warum, und warum dies nicht mit Anpassungsoptionen erweitert wird.
Ich habe zufällig entdeckt, dass das Linux-Build-Skript eine „Paket“-Build verwendet, was bedeutet, dass die CPU-Optimierungen auf allgemeine beschränkt sind, um portable Binärdateien zu produzieren, die auf jeder x86-64-Plattform installiert werden können. Mit “Verwendung” meine ich, dass die Paket-Build-Option nicht explizit deaktiviert war, sodass sie standardmäßig aktiviert war.
Wie dem auch sei, dies ist nun standardmäßig deaktiviert, da die tatsächlichen Pakete (.exe und .appimage) nicht durch dieses Skript erstellt werden, das in erster Linie für Endbenutzer gedacht ist. Um das vorherige Verhalten wiederherzustellen, müssen Sie Folgendes ausführen:
2022 war in Bezug auf Junk-Emails und Lärm so schlecht, dass ich Virtual Secretary gestartet habe, ein Python-Framework, um intelligente E-Mail-Filter zu schreiben, indem Informationen aus mehreren Quellen kombiniert werden, um herauszufinden, was eingehende E-Mails sind und ob sie wichtig/dringend sind oder nicht. Wenn ich von Junk-Mails spreche, sind das auch Github-Benachrichtigungen, Pings auf pixls.us (Gott sei Dank habe ich mein Konto in diesem dummen Forum geschlossen), YouTube und direkte E-Mails von Menschen, die hoffen, privat Hilfe zu bekommen.
Es sind ungefähr 3 Monate her, dass ich “R&Darktable” (was niemand richtig zu verstehen schien) in “Ansel” umbenannt habe, dann den Domainnamen gekauft und die Website von Grund auf mit Hugo erstellt habe (ich hatte zuvor nie in Golang programmiert, aber es ist hauptsächlich Template-Code).
Dann habe ich insgesamt 70 Stunden darauf verwendet, die nächtlichen Paketbuilds für Windows und Linux für kontinuierliche Lieferung vorzunehmen, etwas, was Darktable nie richtig gemacht hat (“Sie können selbst bauen, es ist nicht schwer”), nur um zu sehen, wie der Bug-Tracker nach Veröffentlichung explodiert (nichts besseres als den Vorveröffentlichungs-Spurt mit einem Nachveröffentlichungs-Spurt zu verkürzen, um Ihre Lebenserwartung zu reduzieren).
Was passiert, wenn eine Gruppe von Amateurfotografen, die zu Amateurentwicklern wurden, zusammen mit einer Reihe von Back-End-Entwicklern, die Bibliotheken für Entwickler entwickeln, entscheiden, ohne Methode oder Struktur an einer Industriessoftware für Endbenutzer zu arbeiten, deren Kernkompetenz (Kolorimetrie und Psychophysik) irgendwo zwischen einem College-Abschluss in Fotografie und einem Master-Abschluss in angewandten Wissenschaften liegt, während sie versprechen, zwei Veröffentlichungen pro Jahr ohne Projektmanagement zu liefern? Ganz zu schweigen davon, dass die Gründer und die erste Generation von Entwicklern weitergezogen und geflüchtet sind?
You can also ask Chantal, the AI search engine.
(section) •(summary)