In my view shadow and highlights actually works better than tone equalizer for doing the job. In any case it is not a one for one replacement. Different approach and different result. Also a combination of both often works best because each defines shadows differently.
3 Likes
You seem to have misunderstood a lot about my OP. Probably because I didnāt communicate well.
Let me try again 
It has been said (not by me) that darktable has too many modules, that this makes it confusing, and that for this reason the current offering of potential new modules is concerning.
I argued that it is not the number of modules that matter, but how easy it is to understand which role they play in a workflow. Two modules that are used for different things fit more easily in a userās mental model than two models that do the same thing but slightly differently. Also, modules that do one thing in a focused way can offer similarly focused and aptly designed UIs, which further reduce confusion.
I concluded that adding new modules should not be a problem, as long as they implement well scoped, clearly limited functionalities which make these modules not confusable with the ones that already exist.
5 Likes
I see color harmonizer as enhanced replacement of the old split toning module - so if this is merged then the old module might be deprecated ā¦
4 Likes
Let us start over. I will forget everything and focus on your conclusion:
Is the list the following:
- well scoped
- clearly limited functionality
Or
- well scoped
- clearly limited functionality
- not confusable with existing modules
2 > 1
I am of the opinion that Darktable in its current state is the best version of Darktable ever. The performance and tools are incredible, and for me it keeps going from strength to strength.
However, from a conceptual perspective, I actually preferred āoldā (display-referred) Darktable where there were more specialized modules. With the shift to scene-referred, there was also a shift to more generalized modules that could perform multiple functions. Many of these were created by the same developer, and they include Color Calibration, Color Balance RGB, Diffuse or Sharpenā¦
We were told that certain modules were no longer recommended, such as Vibrance, Vignette, Shadows/Highlights, Monochrome, and instead it was recommended to use the new sliders or modules (or e.g. a mask in the Exposure module instead of Vignette).
While this advice was absolutely correct in terms of the underlying math in the scene-referred workflow, I feel that usability went downhill, at least for me personally. I much preferred the concept of using a dedicated Monochrome module, a dedicated Vignette module, a dedicated sharpening module, etc. (there was probably no need for a dedicated Vibrance module, however).
For me, Color Calibration was the worst offender, as it incorporates white balance, channel mixing, RGB primary calibration and monochrome editing. Thatās arguably four very separate functions. On top of that, if you want multiple instances of the module, you then have the issue of needing to bypass the white balance part (now done automatically, but still, the red warning puts off a lot of new users).
To clarify, this is all just a comment on the concept of the interface and module organization, nothing to do with module performance. I use Color Calibration and Color Balance RGB all the time, but I dislike their UIs and wish they could be split up.
So, to sum up, I agree that itās not the quantity of the modules that is the problem but rather the discoverability of functions and clear separation of tasks. For this reason, I welcome proposals like the Color Harmonizer, which has a clear role, simple interface and does not duplicate existing functionality unnecessarily.
I also recognize that we all have different ways of working, so this merely my opinion. And if changes to the interface, tools and organization of Darktable doesnāt go anywhere, I will happily accept the decision and happily keep using it. Ultimately, I still love it despite its quirks.
10 Likes
I used to think the same thing about Color Cal. I still think the grey tab is kind of a weird addition but I guess even black and white stuff can benefit from operations within CAT spaces? The other functionality actually is super helpful with IR. At least on Sony bodies.
I was talking to a guy who has amazing IR work. I asked about this thing where sometimes I would get color and intensity changes in shadows that didnt make sense. He asked if I shot Sony, and proceeded to give me a long technical jargon filled (to me) answer about how Sonyās signal processing and white balance can generate artifacts when doing faux color IR. His fix was to have me open up the image in photoshop (he just assumed thats what everyone uses) and make some tweaks using the channel mixer. I have no idea if the explanation was legit or not, but I no longer get weird colors and intensities in shadowy vegetation. shrug
For me, being able to āwhite balanceā and perform corrections in the CAT space at the same point in the pipe is a win-win. Even if I donāt need to touch most of the modules functionality for the majority of my images.
2 Likes
This is so true and excellent modules such as shadow and highlights we were told were rubbish and we shouldnāt use. A strong bias was generated against display referred modules based purely upon mathematics.
Again so true. How can anyone expect to work out the sliders in diffuse or sharpen who hasnāt got a PhD in mathematics. Color balance RGB is a fantastic module, but it is like a Swiss army knife with so many capabilities in a single module. Probably not so hard to master the basics though.
I agree strongly as a humble user and teacher of DT with what you have written here. More modules in DT will actually make it easier for the user if these modules are well defined and clear in the task they are meant to be used for.
6 Likes
Iām working on it hahahaha. Maybe something will come of it one day.
2 Likes
What I miss from these discussions is not about adding new modules, but removing them.
In software development, it is understood that occasionally one needs to refactor and streamline to keep a codebase manageable. This inevitably means removing functionality.
Darktable has a policy of supporting everything that was ever in it at some point. The implication is that the space of modules is treated as a scarce resource, which seemingly raises the bar for addition.
But writing photo processing modules is a very experimental undertaking: while math is helpful, in practice what matters is how photos look. This is very hard to get right without looking at a ton of photos and processing them.
Whenever new functionality is introduced to fill an important gap in functionality, users are impressed and there is a pressure for including it ASAP. This is understandable, but there is a tension between getting it right, testing it thoroughly, and having the new toys as soon as possible.
The transition to scene-referred workflow included many modules that, ostensibly, superseded previous functionality, but in many cases this did not work out as expected. In some cases, this was because the implementation cut corners, in some other cases, the functionality of previous modules may not have been fully understood, and a lot of times the math (or the or talking about math 
) simply looked too impressive to question.
I think that at some point, Darktable will have to constrain backward compatibility. This does not have to mean that old photos become impossible to render, but may mean that the pipeline will run on a slower legacy code path that is not updated, or that when encountering very old modules, the user is offered an upgrade option with parameters transformed into a new module, comparing them visually.
If this is not done, changes will have to be met with more and more resistance.
9 Likes
Darktableās way to do that is deprecating modules.
I do agree with a lot of the other stuff being said, e.g. color calibration doing a lot of things and thus having many tabs and many sliders, some of which people donāt routinely use, but they still clutter the interface. It is true that at the heart of color calibration is a channel mixer ā but thatās also the case for the rgb primaries module. Itās one thing to have shared maths, and another to have shared interface. More, but simpler (specialised) modules could make darktable easier to use (like the already mentioned black and white vs a tab in color calibration, or even a channel mixer, that does not expose CAT options, instead of color calibration having a simple channel mixer preset to turn that off).
1 Like
I do have a PhD in signal processing, but these sliders are still baffling. 
(Iām kidding. But only a little.)
9 Likes
I am not sure we are talking about the same thing. My understanding is that deprecated modules still remain in the codebase, and each refactor must deal with them too.
This means that whatever is added now will have to be supported forever (in principle), and each extension to a module interface has to keep the older parameters around too.
3 Likes
I agree with you 100%.
In theory, itās a nice idea to be able to open and edit your 10-year-old photos in the latest version of DT.
However, over time, this creates more and more problems. We know from the developers that there are no plans to change this; it is one of the cornerstones of DT.
At this point, it would be important to know how users feel about this. Who absolutely wants to continue using the legacy module, and who can do without it for the benefit of DT and the developers?
Furthermore, there is always the option of using an older version of DT.
2 Likes
It only creates problems for the developers, and it is the developers who have chosen this model.
It doesnāt matter what āusersā think about this. It really isnāt our problem at all. I donāt know, but maybe I started with dt at v4-point-something. Even older versions may have had modules, now deprecated, that I have not and never will, even hear of (iirc deprecated modules do not show in the tabs unless one is re-editing a picture that uses them).
That availability does not bother me one bit. I donāt even need to think about it. But if I do, then I think that it is an admirable intention. If or when it becomes an impractical intention is entirely for the devs to decide.
It doesnāt even make dt a huge download! Itās Modest Megabytes for the power that it delivers.
I agree with this statement. However, for myself I see that in ten years time DT will have better modules and I would have improved my editing skills so I wonāt be depending upon the ability to recreate a ten year old edit.
1 Like
Modules are pretty much self-contained units, and ādeprecatedā modules can be further isolated by making private copies of the occasional bit of shared code to protect them from unwanted regressions. What I am trying to say is that a module that is not actively used is (or can be made) into a very low maintenance unit.
(The GTK4 migration being a bit of an exception, but generally there are not many such large-scale migrations during the life cycle of a software)
4 Likes
Maybe having a macro or patch system would help with some of these cases. Itās pretty common in music production. You build a chain of base processing modules connected together, and expose a few high-level macro controls that can drive several parameters at once. A patch is basically a saved graph of those modules and mappings, so one knob or slider can control multiple underlying adjustments across the chain while hiding the complexity.
E.g. a B&W patch could be a single slider that control the saturation of a base module.
That said maybe quick access panel is already that, kinda.
2 Likes
I do care about the developers. If it makes their lives easier, then I can do without certain things.
The final decision always rests with the developers, but I get the impression that they are always open to feedback from their users.
1 Like
I returned to dt after a few years away. I bought into the new scene referred modules but found the new modules difficult and complicated to use
. I certainly missed the monotone, highlights & shadows, the pre colour equaliser modules etc. but as time has gone on Iāve reintroduced many of the display modules I missed that are mostly more focused on one task.
And Iāve enjoyed DT more. I have given up on D&S and avoid colour RGB. Life is too short to worry if Iām using the correct type of module.
I keep just two tabs of modules; favourites and nearly favourites. The list of modules is very fluid with display and scene referred mixed in. It works for me. It also allows me to introduce new modules.
Iām very much in favour of new modules if they bring something special to me but I do appreciate that more modules increase the workload of the developers , whose work is very much appreciated by me.
New modules also bring new life into DT.
3 Likes