Since you’re a programmer, I think this analogy should resonate:
Many of the complaints about darktable are as if a Python programmer complained that Rust is too annoying and complicated, and should ditch the borrow checker because it only gets in the way and life is so much nicer when variables don’t care if they’re a string or an int.
The reality is that neither language is strictly better than the other, but rather target different needs with different requirements.
Thank you for providing your insights as well-argued comments, and thank you for staying friendly and civil. As we all know, neither of these are common in internet fora (although this one is generally an exceptionally friendly place).
I can relate to your comments. Darktable is a genuinely complex tool, and nowhere near as streamlined as Capture One (C1) or Lightroom (Lr). So much so, in fact, that I’ve “given up” on Darktable more than once, and used these other apps for multiple years. But as you can see, I did come back each time.
And that’s because, as it turns out, most of Darktable’s modules actually solve real issues. Sigmoid and Filmic are undoubtedly more complex than the fixed built-in tone mappers of Lr and C1. But then again, they do offer a solution to the whitening highlights of Lr and the hue shifted highlights of C1. These look good in some circumstances, but were the bane of my existence in others. With Sigmoid, I can easily control highlight hue and saturation. It’s brilliant!
The Tone Equalizer is more complex than the Whites/Highlights/Shadows/Blacks sliders in Lr/C1, but also offers more control, and can mitigate those halos on horizons that so plague them. The Contrast Equalizer is equally more powerful than Clarity/Contrast. And let’s not even get started on scene referred vs. display referred editing.
And still, I do find Darktable’s UI a but clunky. Which is why I recently started my own experimental raw developer based on Darktable’s algorithms. But just laser-focused on the exact features I want. As a software developer yourself, I’m sure you understand the allure of such a project. One if the more surprising realizations from this endeavor, however, is how many little things actually do turn out to be necessary to my workflow. I thought I could boil it down to a Lr/C1-like complexity, but I could not. There simply are too many genuinely useful things in Darktable to simplify too much. And worse yet, I learned about the internals of a some rarely-used modules while re-implementing them, and that made them indispensable to me. I just simply hadn’t understood them properly before!
Which is all to say, discussions such as these are absolutely useful. It’s how we as a community find out what works and doesn’t in terms if UI, and sometimes discover new ways of doing things.
Due to how the pixelpipe works, I don’t believe it’s possible to make pseudo-modules that are separate from the main DorS instance. I have been thinking about how a “simple” tab could work, but there are some not insignificant UX implications with the design I have in mind that will have to be dealt with somehow.
I’ve only browsed quickly through this video, and what caught my eyes was that the vignetting module is used in the video. As the vignette module is broken[TM], this video counts among the outdated ones. Of course, if somebody wants the look of the vignetting module, they can go for it, but for the kind of vignetting that is typically expected by most photographers the exposure module in combination with a suitable drawn mask is the better choice.
That’s for me really an open point, to have a version 2 math for the vignette module that implements the vignette in terms of exposure change rather than the “interesting” idea behind its current algorithm, because new users will likely rather try the dedicated vignette module to get a vignette rather than using the exposure module, without knowing the reason for the crazy look of the vignettes you get. And the mask controls of the vignette module are anyhow better suited to, em, vignettes than the drawn masks, especially if you want your vignette to be exactly in the center of the picture.
Thanks, Nis @Donatzsky, for reflecting over my thought!
I’m not very surprised by your remarks, though. I’ve realized that my idea would mean to introduce something completely new into the basic/core system, and that is of course something that necessitates a lot of serious stuff to consider, and anyhow very unlikely would be trivial to implement.
But then, what about, as I think somebody else touched upon:
Good practice is anyhow to create new instances for fairly distinct applications of a module’s functions. So what about, e,g, rather creating two versions, D and S, of DorS, where relevant ranges are correspondingly limited, but most importantly where sliders perhaps could be given more specific, and hopefully better understandable labels? Could that possibly bring us a little step in the direction of making this part of the system easier to comprehend?
Is this the kind of thing?
This FR could be a good example of why it might not be so simple. For example the first and second order and the 3rd and 4th order are completely the same initially and so additive if you move them the same direction or subtractive if you oppose them. Its only when you alter the direction slider for one or both of them that each will introduce a refinement and have different impact …you can see this by setting the blend mode to difference and say setting 100% for the 1st order and -100 for the second or the other way around…they cancel each other until you change direction sliders. So its a complex dance of all these together that will determine the final output… I am not saying that maybe there are not possibly better labels but proposing a direct functional label like the one in the FR would not really be accurate at all…
Yeah, I’m not sure the proposals in the FR are great, and my vote would be more of an overhaul anyway. But I wanted to show that there already is an open issue for relabelling the sliders. Perhaps other ideas can be added to this FR if someone has any good ones?
There is another lengthy thread with suggestions, but i think most are just wrong. This is a complex mathematical approach that I don’t think you can just simplify.
Wrll, if you look at the current presets, you’ll notice that you have some where all speed sliders are >= 0 (diffusion), others where they are all <= 0 (sharpening), and some where you have a mix (dehaze, lens deblur)… So adding two modules as you propose limits the possibilities (you lose the “mixed” modes)
Of course, it also means adding two new modules, and we still have to retain the original…
As for better names for the sliders: I have looked fairly deep into DorS, and couldn’t come up with better names (not even better names for personal use), in part because some of the effects depend on interactions between the different sliders.
Thanks, @rvietor, yeah, I’m aware that this is complex. I remember the thread What does diffuse or sharpen really do? , and am for my own part at this stage completely satisfied to use the presets – and then if time allows, perhaps I will try to dig deeper.
I’m not sure what could be right about this. Done by programmers that’s true (some people need to code the app) but for programmers certainly not. I’m also a photographer, not a pro but doing quite a lot of pictures and I’m using darktable and developing it to help me develop my pictures.
I’m paraphrasing something I saw in a YouTube video at least a month ago, so don’t put too much stock in it. The general sentiment about darktable from a lot of people seems to be “it’s complicated”. And in some ways it is, but for someone like me that’s actually a good thing.
Thanks for all your work on darktable!
I may have used dt too long, but I don’t think it’s that complicated (certain modules are, but so are certain operations in e.g. GIMP).
It is different, especially in the way you approach editing with the scene-referred workflow.
And because it’s different, old reflexes learned with e.g. GIMP (to avoid mentioning the other well-known editors :p) don’t work. That’s confusing when you start using dt…
I also think that a lot of people who migrate from commercial software presume that Darktable wants to eventually compete with the big guns, as if that’s its ultimate goal. When they see that there’s a small group of enthusiasts who enjoy its complexity and don’t want it to be a Lightroom clone, they then try to enlighten these “nerds” by arguing that it will never conquer the mass market because its too quirky and complicated, and the devs need to understand that.
But while the devs and community are happy for it to be embraced by as many people as possible, it’s not necessarily their motivation. I don’t want to speak for all the devs’ motivations, but I bet many of them just enjoy working on it and building something that they themselves want to use (as @pascal_obry said). If others enjoy it, that’s a bonus.
That’s maybe selling them a bit short, because I know that they also want to add features and help the users as much as possible, even if it doesn’t directly benefit them. But my main point is that being a Lightroom or Capture One competitor is not the ultimate goal, and new users need to understand that.
Which sounds pretty condescending, given that darktable exists since about 15 years (going by copyright dates in the code)… One might think even devs could have noticed a lack of mass market uptake in that time… 
Competition in terms of processing quality is not the same as competition in terms of market share.
The first is obviously a goal and above all the driver for the constant effort spent for better solutions.
Yes absolutely, and I’ve seen that attitude, as if this group of programmers haven’t realized what “real” users want.
Great point. And I would definitely argue that Darktable does compete very well in terms of processing quality.
Darktable is much harder to learn if you already know Lightroom. Essentially, you need to unlearn Lightroom before you can get to grips with Darktable. It’s genuinely hard.
It reminds me of teaching my students about revision control software. I could usually get them comfortable with the program git within a week or two. Unless, that is, if they already had prior experiences with svn. In that case, I knew I was in for several one-on-ones throughout the entire semester. The way the two programs use the same names to refer to entirely different concepts completely wreaks havoc with their intuitions.
It is similar with transitioning from/to Lightroom and Darktable. I’ve been on both sides of this process. It’s just a perfect setup for having misunderstandings with your own psyche. It’s kind of hilarious actually. You’ll pull on a slider and expect one thing, and another thing happens. But because of that preconceived notion, and your eyes will deceive you to kinda-sorta still see what you expect, just off, somehow. It takes real effort to retrain your eyes that way (and much more time than the one-month trial period of these commercial apps).
Did you get the feeling that any of those people (assuming it was more than one) actually put in a little bit of effort to try and learn the way darktable works?