On module proliferation

Software darktable
1

There are at least three places where module proliferation is being discussed (Worried about LLM-written modules, [New module] [Packages available] Color harmonizer, [New Module] Skin Tone Editor Module). The conversation is a bit sparse, but it is an interesting one (regardless of how the modules are being authored), so I thought it would be nice to have a separate thread.

This is a long post, so here is my TL;DR if you don’t want to bother reading it all:

  • The number of modules is not confusing.
  • What is confusing are modules that cannot be differentiated by the function that they provide.
  • Modules that provide specialized functionalities should be welcome additions as they reduce the average editing complexity and bring clarity to users workflows while allowing them to retain full control.

If you are brave and want the full, unabridged experience, then brew a nice cup of tea or coffee and dive in :slight_smile:

The false problem of “too many modules”

It has been voiced by more than one person that one of darktable’s usability problems is that it has too many modules. In some cases, too many modules to do similar things. The various way to sharpen and add contrast are brought as an example.

The real issue is not that there are too many modules. The issue is that there are some modules that play similar roles in a workflow, but the differences among them are not at all obvious. When and why I should I use contrast equalizer vs. diffuse or sharpen? Sigmoid vs. Filmic vs. AgX? What is the difference between these sets of modules? It is far from obvious. They all deal with contrast or tone mapping, and they all have a lot of controls. Their names do not help understand which one does what.

In some cases, the difference is in the mathematical model that implements a certain function, but this is not the most sensible way to differentiate modules, because visual editing is result driven, not maths driven. Users want beautiful photos, not photos that are mathematically elegant :slightly_smiling_face:. If I want to sharpen a photo, it shouldn’t matter how I do that. What matters is that, at the end, I have a photo sharpened to my taste.

It shouldn’t matter if it’s wavelets or diffusion or whatever, as long as the photo can be sharpened and the process is under control. So, to reiterate, the confusion does not arise from the number of mudules. The confusion arises when multiple modules provide the same functionality and differ only in the implementation details.

Specialized vs. generic modules

At its core, what every module does is shifting pixel values. A single module that allows you to (1) select a bunch of pixels and (2) change their RGB value would in principle serve all editing purposes.

Of course, you wouldn’t be happy with just one module like this, because doing everything would require a lot of time and effort, and the job would be very repetitive.

So, we build abstractions on top of that. We have modules that allow you to change hues, modules that play with saturation, modules that emphasize contrast and so on.

darktable has an excellent collection of relatively low-level, general purpose, fairly complex modules that offer a lot of fine control. The existing modules cover almost any need that you can think of.

However, they are not designed to fulfill specific tasks, and achieving specific results with these modules may be unnecessarily lengthy and cumbersome.

This is exactly where there is the space for specific, targeted modules that implement specialized functionalities with a simple, intuitive UI that does not require too much fiddling.

(I already hear someone saying we should not hide complexity! users have to know what they are doing! we should have full control! don’t dumb it down!. Agreed. Higher-level modules do not hide complexity. They improve usability, reduce the grudge of repetitive tasks and make the editing experience more pleasurable, while leaving you fully in control of the end result.)

darktable already has some of these higher level functionality. The monochrome module is a perfect example. You can achieve similar results with combinations of color calibration, color balance RGB, color equalizer and what not, but the monochrome module packs this functionality into an easy to use, discoverable, non-confusing module. If you want to do monochrome, having a dedicated module to do it is leaps and bounds less confusing than having to fiddle with models that can be used to this end, but are not designed to do that.

Thanks to this one more module, the overall darktable experience is less confusing if you want to do monochrome.

The color harmonizer module that I published a few days ago goes exactly in this direction. With one module instance and 2 or 3 sliders one can achieve effects that, without, would generally require several instances of (possibly masked) lower level modules, each of which has way more sliders than the one instance of color harmonizer.

Such modules increase the size of the module pool AND remove confusion, as functionalities are neatly packed and clearly scoped. They make it possible to achieve the desired results without unnecessary fiddling, while providing the same level of control.

The skin tone editor module (which I have not tried yet because I was too busy writing this post :rofl:) potentially falls in the same category. If implemented properly, a tool that would allow easy retouching of skin tones for portrait shooters has the potential of being extremely useful.

Which leads me the following point.

Differentiation is the key

It has been suggested that skin tone editor and color harmonizer should be merged into a single module because they both deal with hues.

Merging these two modules would be a gross mistake: it would replace two specialized, very separate, clearly scoped functionalities with some kind of generic hue editing tool that is optimized for neither. This, yes, would be redundant and confusing, because we already have generic tools for hue editing.

Which modules should be merged into darktable

All that said, how do we decide which modules should become part of the next darktable release, or, even before that, become a PR?

Well, first and foremost, this decision belongs with the core dev team.

As a rule of thumb, and implementation-quality aside, I suggest that a module should be considered for inclusion if:

  1. It provides a useful technical or artistic functionality
  2. It is more specialized than existing general purpose tools
  3. It is easier to use than the corresponding general purpose tools to achieve the same result. The UI is specifically tailored for a certain task, it is simpler, more straightforward and less overwhelming than the closely related “general purpose” modules
  4. Is well received by the community
  5. The developer has some kind of proven track of contributions to the project, which means that probably they will stick around to maintain it

You made it!

If you read until here, congratulations! I hope that you found it at least not boring and that you will want to contribute to the discussion with your ideas and suggestions. Thanks for reading!

9 Likes
2

I have to say I previously belonged to the group of people that thought there are too many modules, but I agree with most things you say here.
One thing that I recently thought about is, whether it makes sense to have the strict one to one relationship of 1 module in the pipeline → one module in the UI still makes sense. On a technical level, (performance, maintainability, code reuse), it would often make sense do multiple similar operations in one go (say cropping, perspective correction and lens distortion correction). But for the user, these operations are fully independent from each other and belong to different “UI modules”.
So maybe the solution could be “pure UI modules”, that act as an intermediate layer to make very general processing modules easier to use for the user?
E. g. a UI module that only offers only a few sliders to adjust local contrast, but uses Diffuse or sharpen or the contrast equalizer under the hood, or maybe even a combination of the two?

3

What you are discussing, IIUC, is a bit orthogonal, and it seems to go in the direction of “hiding complexity”, which some devs are very passionately against.

On the other hand, if you are after a simplified UI with just some of the sliders all conveniently arranged in a single panel, where the distinction between modules is somewhat less prominent, that is already available and it is called the Quick access panel.

1 Like
4

I didn’t mean to argue for removing/hiding anything, I was just hoping that some of the new modules popping up now don’t need to reinvent the math and algorithms to manipulate pixels, and instead rely on available more general processing modules.

5

Ah, I had misunderstood then. Yes, there is a lot of code that can be reused when higher-level modules are implemented. How much actually depends on how different the feature is. If a module is strictly a subset of an existing module (e.g., it exposes a subset of the sliders and uses exactly the same math) it can reuse everything, but then it arguably does not really add a lot, which makes it redundant.

If the math is similar but slightly different it is also possible to reconcile that to avoid implementing two almost identical transformations in two different places. However, this is not always desirable (there is a tradeoff between the amount of code and its complexity, and for maintenance purposes it may be preferable to keep the modules as self-contained as possible, to prevent unwanted cross-module regressions when changes are done to one of the modules), and anyways is something that would need to be discussed at merge time.

6

FWIW, I think you provided a clear argument and this is a very useful way to discuss expansions to darktable modules, technology- and contributor-independent. Thank you for the write-up. I’ve yet to run the test-case of retroactively applying this decision chain to existing modules, and checking if I like the result :wink:

1 Like
7

Hi Daniele …
as a normal user of the software, I do not care about all the things you are discussing here .
For me personally I want to get the best possible options to turn my raw files into a stunning image …
So i am more than happy, if a new module does help me to find a better or quicker way to get the desired result . Whether the code is man or AI generated and I do not understand the hazzle around it .
What I do understand though , that someone has to make it fit into general DT scheme .
I have no technical understanding of what´s going on in the back of a module , how complicated or time consuming it is to build DT and its structure … and do not care .
I am just a very happy user !!!
And if more options arise … I might be an even happier user .

Not sure if my opinion helps , just wanted to share it

Regards Andreas

2 Likes
8

To new users, the simple fact that there are too many sliders is an issue in and of itself. I’ve seen that argument multiple times.

I’ve also seen many people edit by going through every slider of their program one by one, from top to bottom, and wiggling each until it feels right. With such a workflow, too many sliders are inherently problematic.

That’s not necessarily a problem for darktable. It’s ok to be different. We don’t need to please Lightroombas. But I think it’s also important to understand why they mention these sentiments.

4 Likes
9

I agree, and this goes in support of the argument that more dedicated modules with fewer controls are indeed good to have.

But here we are talking about the number of modules, and whether this is inherently a problem, and how we should decide if and when to include new modules.

I would be happy if we could try to keep the discussion focused. Thanks!

3 Likes
10

other people have suggested a system of plugins which is pretty standard in larger open source packages, as a way for people to write extensions that the main dev team doesn’t have to worry about as much, this seems like a good way for people to write extra modules without causing issues for the project as a whole (arguments about what should be included etc)

2 Likes
11

I just commented on this here :slight_smile::

Even if darktable went down that path, there would still be cases in which we would make sense to bundle a new module with it, so this discussion would be relevant anyways.

2 Likes
12

I think it’s changed now, but for years the dataflow language “pure data” had two packages for download, the core and “pd-extended” which was a bundle with all the plugins currently available

1 Like
13

I would say there are not enough modules, and I see absolutely no harm in having multiple modules doing “the same thing”.

I want both :smiley:

For some “core” functions there should, in the long term, exist a reference implementation that does it “mathematically right”.

But for many artistic effects there is not necessarily a mathematically right way, or the “wrong” way may look better or perform better. In these cases, why not have two modules approaching the same problem differently?

Maybe new users should follow a tutorial at first?
Maybe having a "beginner gui option " like slicer?
I don’t see how or why software should be dumbed down and limited in its capability to please those unwilling to educate themselves.

If i look at Blender for example it’s also not easy to uses if you don’t know what you do… but extremely powerful if you do
And one would try to wiggle every slider in blender :slight_smile:

If they want a one-stop “just make it look nice” solution, there are countless proprietary and “AI” programs that promise to do that.

That said, I also wouldn’t say no to the option of a magical auto-AI enhancement module. :smile: (as a n option!)

14

The blender argument is good. Blender is probably 100x more complex than darktable for a noob, and quite more successful too given its apparent large userbase and corporate sponsors.

Not saying its success is because it’s better than dt of course, this could simply a case of there existing more 3D artists than photographers, or the commercial 3D options being less than good compared to commercial raw developers.

15

I haven’t used Blender in forever, so I maybe wrong. But when I used it last time, it was clear that Blender was developed in a very deliberate way. What I mean to say is that it is a very tightly integrated system, where everything is planned, designed and integrated in great detail. darktable is more “spontaneous” in nature. I don’t mean it as a criticism, don’t get me wrong, I like that darktable is a very open, community oriented effort. But this is one element that allows Blender to deliver another level of polish and integration, which overall makes it appear less complex than it actually is.

3 Likes
16

Did you use an LLM to create this post? It is fine if you did, and would explain a few things, I just want to be clear who/what is generating the “argument”.

1 Like
17

No, I use them only as a coding aid. These are my ideas and my words, including the typos. For the record, I wouldn’t let an LLM put words in my mouth.

It’s kind of funny that if one uses a bit of structure in a post now it’s assumed that it’s generated :rofl:

Anyways, I take it as a compliment, as LLMs are notoriously very eloquent. :slight_smile:

7 Likes
18

As a simple user I like the choice that Darktable provides. One former developer forked Darktable into Ansel and stripped it of ‘redundant’ modules. Redundant in his view. But the lack of these redundant modules caused me to abandon Ansel very quickly.

One module that was removed in Ansel was shadow and highlights because it was stated that tone equalizer achieved this in a ‘better’ way. But photography is about look and the these two modules adjust shadow and highlights in a different way and the look is subtly different.

Color zones and color equalizer is another example of two very similar modules and I use both of these in my editing. The difference is very subtle and possibly I could live with just one option in this case. But if the maintainers of DT are not burdened by keeping both I am happy to have both.

I would agree with this sentiment and I look forward to more good modules appearing in each release of DT.

19

I fear that I will be interpreted as an LLM in the future for similar reasons… :robot:

Anyways I think I mostly agree with your points. In the tutorial I wrote a few months ago I mentioned using color balance rgb for three separate tasks: color saturation, general contrast, and color grading. I can do that in one or three instances. I love color balance rgb but I don’t need a module that can do anything and everything so much as I want a quick way to achieve specific results without having to navigate through many sliders and tabs. The DorS module is similar, 99% of the time I simply choose a preset and draw a mask. The various sliders serve no purpose to me except getting in the way.

Though admittedly these are small annoyances for me. The bulk of my editing for a single photo takes me less than 5 minutes, and I don’t even have auto-applied presets to speed things up.

Having powerful, generalized tools like color balance rgb, tone equalizer, and others, is quite a good thing. You can do a lot of things with them and you can do things in different ways. But for a new user whether they are experienced with other software or not, results in a lot of “how do I…” questions. And “just watch several hours of videos showing you all the options” isn’t necessarily a great answer. For more experienced users, sometimes you know what you want to do and just want the software to get out of the way.

All that said, I kind of don’t care either way. The effort and struggle I’ve put into using darktable over the past year has not just helped me learn how to use darktable better, but has helped me understand way more about photography than I knew prior when using Lightroom.

I do wonder, as others have touched on, how hard it is to reuse functionality from modules and only provide a simpler interface. I love color balance rgb but would love three separate modules for managing the tasks previously mentioned. I also wonder if there’s a way to label / organize modules as “general purpose” or “intended for specific use case”.

Whatever anyone’s feelings on whether there’s too many modules or not, the number of modules is never going to decrease unless the philosophy of backwards compatibility changes. So now it’s just a question of managing the modules we do have and anticipating that number increasing over time.

2 Likes
20

The structure of your post leaves it unclear how you go from your stated problems to the suggested policy guidance wrt to new modules. That does not mean there isnt a well grounded logical connection, you have just left it implied as opposed to explicit. It comes across as very…vibe-y. I will focus on the non-guidance aspect, since I assume it is the part you feel is most important.

Have you seen Photoshop? It is industry standard and has even more options/workflows that achieve the same “goal”. I think your argument premise is really the conclusion to a sub argument, which you need to articulate because it is not uncontroversial (self- evidently true).

But the maths effect the visual result. It may be subtle and it may only become apparent in certain situations, but there is a reason why these different structures exist in the first place. The premise that these different ways of doing things are not really different is, well, false.

Except the monochrome module is explicitly hiding complexity and control. You cannot fine tune things the way you can with the color calibration module. Don’t get me wrong, it is a fine module. I used it myself before I spent time to learn the modules that afforded me more control and options. Again, your argument suffers from false premises.

None of the above should be construed as saying there isnt merit in your overall conclusions. Your argument for those conclusions just needs work to be stronger if you actually care about having reasoned debates with people who disagree.

I think it might be worth keeping in mind that, at least in my area of the US, the majority of people taking photographs think Lightroom is too complicated to be bothered with. Many people are willing to use Instagram/Camera App filters and call it a day. Darktable does not need to compete for those (or any) users, and so its ok if some people find it overwhelming. The universe of discourse is pretty small, all things considered.

EDIT: It was not the structure that made me question authorship. It reads like the LLM essays turned in by undergrads.