I use to think, for a very long time, that there was some kill-switch mechanism on the pixel pipeline. The use case is the following :you are changing a module parameter,the previews (the central darkroom one and the thumbnail in left panel, also used for histogram and color pickers) recompute their pipeline to account for that change,one of the previews finishes rendering before the other, and the result is obviously what you wanted,you change again the module parameter, without waiting for the recomputation to finish.In that case, you want to kill all active pipelines because their output will not be used, and start recomputing everything immediately with new parameters.Except Darktable do

If you come from Darktable, you may be used to this in the darkroom:while Ansel offers you this:This is no accident, and tt's time to explain why, and why this will not be extended with customization options.Images are born from pipelinesA pixel pipeline is a sequence of filters in which pixels are processed to end on a medium. Photoshop calls those filters layers, abiding by a methaphor inherited from paper and matte painting. Da Vinci Resolve, Blender, Natron, etc. calls them nodes, abiding by a methaphor grounded in directed graphs and flowcharts, best known to engineers. Both have a way of showing how those filters are organized, either with a layer stack or with the node graph (aka flow

I accidentally discovered that the Linux build script used a "package" build, meaning the CPU optimizations are limited to generic ones in order to produce portable binaries that can be installed on any x86-64 platform. By "using", I mean the package build was not explicitely disabled, so it was enabled by default.Anyway, this is now disabled by default, since the actual packages (.exe and .appimage) are not built through that script, which is primarily meant to help end-users. To get the previous behaviour back, you would need to run:$ sh build.sh --build-package --install --sudo Not using the package build option may increase performance on CPU by 20 to 30 % depending on your hardware, tha

2022 was so bad in terms of junk emails and noise that I started the Virtual Secretary, a Python framework to write intelligent email filters by crossing information between several sources to guess what incoming emails are and whether they are important/urgent or not. When I'm talking about junk emails, it's also Github notifications, pings on pixls.us (thank God I closed my account on that stupid forum), YouTube, and direct emails from people hoping to get some help in private.Having become "the face" of darktable, mostly because I'm one of the few to bother providing user education and training instead of just pissing code, I didn't see that coming, and I wasn't prepared. A lot of people

It's been roughly 3 months that I rebranded "R&Darktable" (that nobody seemed to get right), into "Ansel", then bought the domain name and created the website from scratch with Hugo (I had never programmed in Golang before, but it's mostly template code).Then I spent a total 70 h on making the nightly packages builds for Windows and Linux work for continuous delivery, something that Darktable never got right ("you can build yourself, it's not difficult"), only to see the bug tracker blow up after release (nothing better than chaining the pre-release sprint with a post-release one to reduce your life expectancy).People keep asking for a Mac build because they have no notion of the amount