Nieuws

Jiyoné (Guillaume Stutin) heeft sinds oktober 2025 het beheer van Ansel overgenomen. Het huidige doel is om Ansel om te vormen tot een coöperatie  waarin gebruikers lid kunnen worden en op democratische wijze de richting en prioriteiten van het project kunnen bepalen, maar die ook een eerlijke vergoeding en een veilige werkomgeving garandeert voor wie zijn arbeid aan het project besteedt. Ik heb de beschrijving van het probleem en de voorgestelde oplossing uiteengezet op de democracy-pagina.

Tussen januari 2022 en maart 2026 landde Ansel 297 niet-merge commits met betrekking tot het lichttafel-raster, de miniaturen daarvan en hun renderpipeline en caching. Ik heb geprobeerd het zo lang mogelijk uit te houden met de sjofele Darktable-lichttafelcode, alleen ontvet, maar helaas was het pure technische schuld en het was pijnlijk traag.

Darktable „beheert" namelijk de belabberdheid van zijn lichttafel door de omvang ervan te verkleinen: de linker- en rechterzijpanelen nemen veel weergaveoppervlak in beslag, waardoor er nog minder ruimte overblijft voor de lichttafel om opnieuw te tekenen. Sinds Ansel het rechterzijpaneel verwijderde en de inhoud daarvan samenvoegde met het linkerpaneel en het globale menu, was er meer oppervlak om te tekenen, meer CPU-werk te doen, en werd het verschrikkelijke ontwerp van de lichttafel des te schadelijker.

Sinds ik Darktable begon te gebruiken, rond 2012, was ik altijd verbaasd over hoe weinig RAM het gebruikte. Mensen denken dat het goed is dat een applicatie zuinig omgaat met het geheugen, en dat is zeker waar als we het over je desktopomgeving hebben. Maar als we het hebben over productiesoftware die zware pixelberekeningen uitvoert op afbeeldingen van 12 tot 54 Mpixels, dan betekent dit dat dezelfde zware berekeningen keer op keer worden uitgevoerd in plaats van te worden bewaard om later hergebruikt te worden. Daar dient een cache voor: het vermijden van dure berekeningen. En hij zou daarvoor alle beschikbare RAM moeten gebruiken, want rekenen is energie verspillen, en dat heeft een concrete impact als je op batterij werkt. Bovendien heb je voor die RAM betaald en het gebruiken ervan maakt je batterij niet leeg. De CPU/GPU daarentegen…

Memoires van een kerel die te veel tijd besteedde aan het opruimen van andermans stront en het betalen voor hun slechte beslissingen, aflevering #te veel.

Bewerkingsgeschiedenis kopiëren/plakken en stijlen zijn kernfuncties in Ansel, en degene die het zijn titel „workflow-app" doet verdienen (of niet). Maar het is ook een van de moeilijkste om intern goed te krijgen. Gebruikers zien een lijst met bewerkingen, maar onder de motorkap zijn die bewerkingen afhankelijk van de pipeline-volgorde, de module-instanties en de maskers. Als twee afbeeldingen verschillende pipeline-topologieën hebben, kan het naïef kopiëren van bewerkingen tot inconsistenties leiden.

In mijn stellingnemende bericht, Darktable: crashing into the wall in slow-motion, presenteerde ik de treinramp die de nieuwe „Great MIDI turducken" was. Het doel van deze turducken¹ was om het sneltoetsensysteem te herschrijven om het uit te breiden voor MIDI-apparaten.

Tot op de dag van vandaag ben ik nog steeds boos over deze onderneming van massavernietiging, hier is een samenvatting van de redenen:

1. het verving in 2021 een sneltoetsensysteem dat behoorlijk goed was, functioneel compleet, goed getest, stabiel en gecodeerd in minder dan 1500 regels (commentaar inbegrepen),
2. …om ondersteuning toe te voegen voor MIDI-apparaten en PlayStation-gamepads (!?!)…
3. …maar in mijn Darktable-enquête van 2022, één jaar na deze nieuwe functie, van de meer dan 1251 gebruikers die deelnamen:
   • had 81% van de gebruikers geen MIDI-apparaat en was niet van plan er een aan te schaffen,
   • wist 2% niet eens wat een MIDI-apparaat was.
   • had 8% van de gebruikers een MIDI-apparaat maar gebruikte het niet met Darktable,
   • overwoog 6% misschien in de toekomst een MIDI-apparaat aan te schaffen,
   • had 2% van de gebruikers een MIDI-apparaat dat ze daadwerkelijk in Darktable gebruikten,
4. de code was absoluut verschrikkelijk, wat betreft:
   • codekwaliteit: onleesbare if/switch-case-statements genest op 4 niveaus, midden in functies van 1000 regels (ik plaatste voorbeeldfragmenten in mijn artikel),
   • codevolume:
     • 3546 regels code voor Darktable 4.0,
     • 4397 regels code voor Darktable 5.0,
     • de toename in volume is een direct gevolg van het proberen te repareren van bugs in een architectuur die niet gerepareerd kan worden omdat de complexiteit ervan meer complexiteit bevordert. Dat komt allemaal voort uit het ontwerp, maar problemen die door complexiteit veroorzaakt worden oplossen met het toevoegen van meer complexiteit is geen oplossing.
   • codecomplexiteit:
     • cyclomatische complexiteit :
       • 1088 voor Darktable 4.0,
       • 1245 voor Darktable 5.0 (details ),
     • cognitieve complexiteit :
       • 1885 voor Darktable 4.0,
       • 2098 voor Darktable 5.0 (details ).
     • het is verreweg de meest complexe functie van de software, ook al werkt het niet op afbeeldingen. Ter vergelijking: de op één na meest complexe functie is de EXIF-metadata-decodering, die een cognitieve complexiteit van 1348 heeft.
5. het decodeert door ontwerp geen toetsmodificatoren, maar behandelt alleen hardware-toetsaanslagen, wat betekent:
   • „1"-invoer van het numerieke toetsenblok wordt gedecodeerd als Keypad End,
   • „1"-invoer van een Frans AZERTY-toetsenbord wordt gedecodeerd als Shift+&, of Shift+" op BÉPO,
   • je moet daarom al je op cijfers gebaseerde sneltoetsen dupliceren voor elke manier om een cijfer in te voeren, en erop voorbereid zijn dat het sneltoetsinstellingenvenster geen enkel echt cijfer in de toetscombinaties bevat.
6. het ontwerp aan de gebruikerskant is absoluut verschrikkelijk, met veel te veel te configureren acties en emulaties („effecten"), die zelfs 4 jaar later niet volledig gedocumenteerd zijn (wat is „ctrl-toggle"? „right-activate"?), en de sneltoetsconfiguratie gebruikt een raar gesplitst venster dat nergens op slaat,
7. de implementatie is ook verschrikkelijk: de functie is op de hoogte van de hele software-GUI, en de software-GUI is op de hoogte van de sneltoetscode. Er is hier geen modulariteit, en iets veranderen in de sneltoetscode kan overal in de software onverwachte en ongewenste effecten hebben.² Kijk maar naar de afhankelijkheidsgraaf hieronder,
8. meerdere „sneltoetsen" (of MIDI-bindingen) kunnen aan dezelfde actie gekoppeld worden, wat betekent dat elke gebruikersinteractie de hele lijst met beschikbare acties moet doorzoeken, wat zeer inefficiënte sneltoetsafhandeling veroorzaakt, GUI-vertragingen in sommige gevallen en „onbekende toetscombinatie"-fout-positieven in bijzondere gevallen.

Nadat ik eindelijk de hele website en documentatie had gekoppeld aan een waterdichte vertaalworkflow (met po4a bovenop Hugo), die toevallig exact dezelfde toolset en logica gebruikt als de Ansel-applicatie, kreeg ik het idee om lege vertalingen te automatiseren, eerst vanuit de vertaalbestanden van de software, daarna via de ChatGPT API, die Markdown-syntaxis behoorlijk goed vertaalt.

Als je alleen werkt, kun je niet rekenen op sociaal lijntrekken , dus moet je slim zijn. Je kunt de lijst met dingen die ik al geautomatiseerd heb op de achtergrond voor Ansel bekijken.

In december 2019 vroeg ik of iemand ervoor wilde zorgen dat er AppImage-pakketten werden aangeboden  voor Darktable. Het voor de hand liggende voordeel zou zijn geweest dat vroeg testen mogelijk werd, vóór de uitgave, door mensen die de broncode niet zelf kunnen bouwen, om zo hopelijk vroege feedback te geven en te helpen met debuggen voordat er werd uitgegeven. Dit is nooit een prioriteit geweest, wat betekende dat het prima was om zowel vóór de uitgave als na de uitgave in een stormloop bugs te moeten fixen.

Ansel erft van Darktable de ruggengraat van zijn database: de niet-destructieve bewerkingsgeschiedenissen worden per foto opgeslagen in een SQLite-database, samen met metadata en andere door de gebruiker gedefinieerde gegevens. De database bewust maken van nieuwe foto’s gebeurt door foto’s te „importeren" van een schijf of een geheugenkaart. Daar komt de importtool in beeld.

Helaas is de Darktable-importeur nog zoiets dat rond 2020 werd verminkt en omgevormd tot iets diep verontrustends, want het is een bestandsverkenner die op geen enkele eerder bekende bestandsverkenner lijkt, en die erin slaagt om basisfuncties te missen (zoals Ctrl+F of EXIF-voorbeeld) terwijl hij tegelijk overladen is met nutteloze (zie hieronder). Hier verliezen we menig toekomstig gebruiker, en het is nog maar stap 0 van de workflow. Wat een geweldig visitekaartje van wat een „workflow-app" kan doen!

Ik heb heel lang gedacht dat er een of ander noodstopmechanisme op de pixelpipeline zat. Het gebruiksscenario is het volgende:

1. je verandert een moduleparameter,
2. de voorbeeldweergaven (die in het midden van de donkere kamer en de miniatuur in het linkerpaneel, ook gebruikt voor het histogram en de kleurenkiezers) herberekenen hun pipeline om rekening te houden met die verandering,
3. een van de voorbeeldweergaven is klaar met renderen vóór de andere, en het resultaat is duidelijk niet wat je wilde,
4. je verandert de moduleparameter opnieuw, zonder te wachten tot de herberekening klaar is.

In dat geval wil je alle actieve pipelines afbreken, omdat hun uitvoer toch niet gebruikt zal worden, en meteen alles opnieuw beginnen te berekenen met de nieuwe parameters. Alleen doet Darktable dat niet, het laat de pipeline eerst afronden voordat die opnieuw wordt gestart, en gezien de commentaren in de broncode lijkt het een vrij recente regressie te zijn en niet het oorspronkelijk bedoelde gedrag.

Darktable heeft zijn eigen GUI-widgetbibliotheek, voor schuifregelaars en comboboxen (ook wel keuzelijsten of selectievakken genoemd), genaamd Bauhaus (in de broncode staat die in src/bauhaus/bauhaus.c). Hoewel ze Gtk als backend gebruiken, zijn Bauhaus-objecten aangepaste objecten. En zoals veel dingen in Darktable geldt: aangepast staat gelijk aan rot.

In 2022 ‍merkte ik parasitaire hertekeningen en vertragingen  op bij het gebruik ervan, wat tot een frustrerende gebruikerservaring leidde: het hertekenen van de widget leek te wachten tot de herberekeningen van de pipeline waren voltooid, wat betekende dat gebruikers niet echt zeker wisten of hun waardewijziging was geregistreerd, waardoor ze het opnieuw konden proberen en zo een nieuwe cyclus van dure herberekening startten, en hun computer effectief enkele zeer frustrerende minuten bevroren met nutteloze tussentijdse herberekeningen van de pipeline.

Rawspeed (de bibliotheek die de decoders voor camera-raw-bestanden levert) heeft de ondersteuning voor GCC < 12 afgeschaft. Als gevolg daarvan kan ik de AppImage niet langer bouwen op Ubuntu 20.04 (met Github-runners), maar moet ik hem bouwen op 22.04.

Dit betekent dat elke Linux-distributie met een libc ouder dan 2.35 vanaf vandaag de nieuwe AppImages niet meer kan starten. Dat zou de meeste gebruikers die distributies draaien die in 2021 of recenter zijn bijgewerkt niet moeten treffen. Ubuntu 20.04 en andere LTS-/oude stabiele distributies (Debian stable) kunnen wel getroffen worden.

Als je van Darktable komt, ben je in de donkere kamer misschien dit gewend:

terwijl Ansel je dit biedt:

Dat is geen toeval, en het is tijd om uit te leggen waarom, en waarom dit niet zal worden uitgebreid met aanpassingsmogelijkheden.

Ik ontdekte per ongeluk dat het Linux-buildscript een „package"-build gebruikte, wat betekent dat de CPU-optimalisaties beperkt zijn tot generieke optimalisaties om portable binaries te produceren die op elk x86-64-platform geïnstalleerd kunnen worden. Met „gebruikte" bedoel ik dat de package-build niet expliciet was uitgeschakeld, dus was hij standaard ingeschakeld.

Hoe dan ook, dit is nu standaard uitgeschakeld, aangezien de eigenlijke packages (.exe en .appimage) niet via dat script gebouwd worden, dat in de eerste plaats bedoeld is om eindgebruikers te helpen. Om het vorige gedrag terug te krijgen, zou je het volgende moeten uitvoeren:

2022 was zo slecht wat betreft rommelmails en ruis dat ik ben begonnen met de Virtual Secretary , een Python-framework om intelligente e-mailfilters te schrijven door informatie tussen verschillende bronnen te combineren om te raden wat inkomende e-mails zijn en of ze belangrijk/urgent zijn of niet. Als ik het over rommelmails heb, gaat het ook over Github-meldingen, pings op pixls.us (goddank heb ik mijn account op dat stomme forum opgeheven), YouTube, en directe e-mails van mensen die hopen in het privé wat hulp te krijgen.

Het is ongeveer 3 maanden geleden dat ik „R&Darktable" (wat niemand goed leek te snappen) omdoopte tot „Ansel", vervolgens de domeinnaam kocht en de website vanaf nul opbouwde met Hugo (ik had nog nooit in Golang geprogrammeerd, maar het is grotendeels templatecode).

Daarna besteedde ik in totaal 70 uur om de nightly-pakketbuilds voor Windows en Linux werkend te krijgen voor continuous delivery, iets wat Darktable nooit goed voor elkaar kreeg („je kunt zelf builden, het is niet moeilijk"), om vervolgens de bugtracker te zien ontploffen na de release (niets beter dan de pre-release-sprint aaneenrijgen met een post-release-sprint om je levensverwachting te verkorten).

Wat gebeurt er wanneer een bende amateurfotografen, die amateurontwikkelaars zijn geworden, vergezeld door een stel back-endontwikkelaars die bibliotheken voor ontwikkelaars ontwikkelen, besluit om zonder methode of structuur te werken aan industriële software voor eindgebruikers, waarvan de kerncompetentie (colorimetrie en psychofysica) zich ergens tussen een bacheloropleiding fotografie en een masteropleiding toegepaste wetenschappen bevindt, terwijl ze beloven om elk jaar 2 versies te leveren zonder projectmanagement? Dat alles, natuurlijk, in een project waar de oprichters en de eerste generatie ontwikkelaars verder zijn getrokken en gevlucht?