Development

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.

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:

1. Sie ändern einen Modulparameter,
2. die Vorschaubilder (die zentrale Dunkelraumvorschau und das Thumbnail im linken Bereich, das auch für Histogramm und Farbwähler verwendet wird) rechnen ihre Pipeline neu, um diese Änderung zu berücksichtigen,
3. eines der Vorschaubilder endet mit dem Rendern vor dem anderen, und das Ergebnis ist offensichtlich nicht das, was Sie wollten,
4. Sie ändern erneut den Modulparameter, ohne darauf zu warten, dass die Neuberechnung abgeschlossen ist.

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.

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).