As a matter of fact, I had started exploring this idea a couple of days ago, because I find it a bit annoying and wasteful that I have to distribute a whole executable binary just to let people try out a new module.
It is actually fairly simple to implement a plugin system for darktable. We just need to extend the module api with a way to specify a module’s position in the pipeline. For example, each module can declare after which “official” module it should go.
So, this is a viable option, which would take the burden away from the core dev team.
If there is interest, I can explore this in more detail.
Maybe adding some kind of reference to the darktable version would also be helpful / necessary? And a way to exclude unavailable modules from the history stack? (I don’t have module X, or module Y has not been updated to darktable 6.2, it now breaks, and I had to remove it – I’d still want to be able to load PlayRaws or my own previous edits.)
It would also accelerate development. I, for example, am not very good at programming, and compiling a project the size of darktable just to try out a novel idea for a visual effect would stop me before I even started.
However, I can help myself by cobbling together some rough code for a proof of concept using simple tools like Processing, Pure Data, Arduino, or some simple scripts. It’s not good, not stable, and not performant, but it helps communicate a visual concept.
And I hope that a proof-of-concept plugin could become a proper module faster if you can share and show it more easily.
To clarify, with “plugin” here I am talking about a piece of C code built with the current darktable API. Basically, a module built against darktable at master, but instead of building the whole shebang you would just build one module and distribute a .so or a .dll.
This requires minimal refactoring, on the order of magnitude of a few hundred lines of code. Anything else would require much more work.
To try an effect, you can already invoke external tools via Lua. So, you could create a processing chain using Python or G’MIC or whatever, export from darktable to that tool with a click of a button, and reimport automatically. Not ideal, but it should be OK to test an algorithm. It wouldn’t have sliders etc. inside darktable, though.
A simple, dirty prototype in C is not hard, either, especially with a good LLM. You don’t need tiling and OpenCL from the first minute, and setting up a few sliders (no fancy notebook etc) is quite simple. Once you built darktable (which needs the one-time installation of some dependencies and running a script to build), you can change the code, then build in a few seconds, and test again.
You’d still have an issue with module ordering: if you really want such a structure, you could think of replacing the demosaic module with one using a different algorithm. Then you would need a way to say “use only one of these”… And what about the order of plugged-in modules relative to one another?
Sure, these are all things to consider. I didn’t outline an executive plan But they seem all solvable issues that do not require huge engineering efforts.
No, it too early to say if this has happened. What’s happening at the moment is the resurrection of a very old misunderstanding, namely that
\text{programmer producivity} \equiv \frac{\text{lines of code}}{\text{hours of work}}
This is the kind of thinking that got us MS-DOS.
In about 5, we will be in a position for a preliminary evaluation to see how it turns out. Did we improve productivity? Or just shifted costs to the future (technical debt), users (subtle bugs), or coworkers (who have to deal with the slop)?
Again, it is perfectly fine to wait this out a bit. Or restrict the usage, as a refactoring tool or similar.
I beg to disagree. I am not talking about programming, I am talking about the whole life cycle of software engineering work, from design, to implementation, testing, documentation, evolution and dissemination. Over the last month the way that my whole organization (company, actually) works has been turned upside down. It’s not the same job anymore. Lines of code are not even part of the equation. The actual software artifacts are becoming kind of a necessary byproduct. It’s a bit scary , it feels very… different.
Anyways, perspectives may differ, and time will tell.
[Clarification: I am not saying that this is good or bad. I don’t know yet. I am just testifying a tectonic shift that is happening as we speak]
I think we are past the slop phase when it comes to code. I mean, in the hands of a teenager with a lot of spare time yes, you can use these things to produce slop. But on the workplace people use them when needed. We do not generate code for fun. And the code that they produce is by and large better than the code that any of us would write. It may be the case that the upper management asks us to produce more features / products, just because we can, thus creating an overwhelming amount of code that will have to be maintained. But then again, the problem is not the LLM, the problem is execs asking engineers to use LLMs in an irresponsible way that (maybe) will not scale.
This is really strange as from personal experience at work, using mostly Sonnet 4.6 at the moment, its code is almost always not better than what I would write.
It does nail boiler plate code, or following existing patterns, but when writing new things even with a good spec it takes shortcuts and doesn’t really write properly. Often misses very basic things that for me and others are just simple basic intuition. But of course, this may not be the fault of the model, or our skills as programmers, but the different domains from which you and I operate, which from what you’ve said previously couldn’t be more dissimilar.
Frankly, I find this the most annoying part. The rest I can live with, but people making PRs that “relax” the tests just because some LLM told them to do it is so annoying that I am often lost for words when reviewing a PR.
I am sure there is a way to customize all LLMS to avoid doing this.
Let me correct the aim. It is not better of the code that I could possibly write. But it is better than the code that I would generally write And I can write pretty good code if I want to, at least compared to the average human being.
Anyways, yes, they don’t always get it right, that’s why one needs to stay on top of them, as we have already stated above.
Yes, well, try Opus 4.6. Really. Try Claude Code, if you can, as an agent. Write specs. Tell it to go in “red/green” mode (first, write tests; check that they fail; then write the code; check that the tests pass). Adapt these instructions to your use case, for example: Rust AGENTS.md (2026-02-23) · GitHub
Thanks for the info. I use it in copilot, integrated into vscode, and Opus uses 3x the tokens compared to Sonnet. But I will give it a try for more challenging tasks, as I never spend all my monthly budget, thanks.
Hello,
Sorry for my response to your post, I wrote too quickly and, as they say, I got up on the wrong side of the bed.
I read your article, it’s very impressive.
Greetings from Luberon,
Christian
You can still try adding instructions, even if you use Sonnet, to see if it improves the output. We also have copilot at work, have you tried the new Codex models? I think those don’t have such a high penalty.
But they seem all solvable issues that do not require huge engineering efforts.