True, and my reply could be seen as a generalization itself, although I did preface that by saying “mostly.” But whether pro photographers use it or not, it’s still true a lot of commercial software, including lightroom, targets mass consumption, and simplifies some things to achieve their aim. Not all pro photographers are pro editors or have the time to be, so they rely on this simplification.
1 Like
Thats done - If Lightroom is satisfying the demand of a professional photographer then there’s no need to change the tools. There’s no ambition for darktable to take over as much users from Lightroom etc. as possible.
darktable scope is to provide the options Lightroom doesn’t give to you.
If you’re demanding just a free Lightroom clone then darktable is simply the wrong place to search for it.
It’s like the green rectangle on your camera - there‘re plenty of user for this but at least ambitious users prefers to customize their tools. darktable is focused on the M mode
6 Likes
OK thanks for trying! I found the same, that RT or ART gave a much more pleasant look in the highlights (gentle roll off, no sudden changes in colour) but this was difficult to achieve in darktable which either desaturated the sky or generated strange oversaturated colours, depending on which chroma preservation mode you chose in filmic. It may be user error on my part, but I tried lots of things including increasing the white point value in filmic as advised.
2 Likes
That was a nice example of how much better highlight reconstruction can be! But remember that the best is to protect your highlights at shooting time, any reconstruction has to make assumptions in the end!
As a developer 
As for your comment about Lightroom. I think speed due to fever options is a big reason for its popularity. I’m pretty sure few developers want a Lightroom clone as @MStraeten puts it but I also think we should pay close attention to the speed of the darktable workflow. From import, sorting, and tagging to reducing the number of clicks and parameter iterations when doing the edit.
Time is probably the number one constraint for many photographers so it’s nice to hear that the sigmoid module gets you good or better results in less time!
3 Likes
Modules/tools may not be aplenty, but, for being so fast to work with, I think Lightroom packs a lot of power (and polish). Take this little detail at 10m20s, the fact that you can move a masked gradient around and the position of the mask is kept in place. It’s a great example of what I’m trying to pin down.
I demand nothing from these fantastic tools I get to use for free. However, I wish more professional photographers (and retouchers) would use them. That’s why I’m interested in why darktable has trouble reaching outside the world of FOSS. It can’t only be a matter of marketing resources and lazy/uneducated users (which is somtimes mentioned as a reason around here)? darktable doesn’t have to be FreeLightroom™️, but that doesn’t mean there’s nothing to learn from LR.
I don’t know if I’m fine with the green rectangle metaphor. Yes, there’s an Auto Tone feature, but you don’t have to use it. I dare to say most people don’t. Lightroom has become quite sophisticated considering its ease of use. Selection tools are fine now that range (parametric) masks are available.
If it helps, I can tell you I’m not having a lot luck either. 
I would approximate I’ve spent at least 60 hours learning darktable (probably more) and I just can’t get highlight reconstruction right.
Of course. Highlights are more easily protected in genres of photography where time is plenty (compare still life studio work to photo journalism or street photography).
That’s the answer I was expecting 
I read this article yesterday and had a hard time not thinking about darktable and Lightroom:
Complexity is like energy. It cannot be created or destroyed, only moved somewhere else. When a product or service becomes simpler for users, engineers and designers have to work harder. Norman writes, “With technology, simplifications at the level of usage invariably result in added complexity of the underlying mechanism.”
But also:
Norman writes, “Whether something is complicated is in the mind of the beholder. ” Looking at a workbench of tools or a digital photo editing program, a novice sees complexity. A professional sees a range of different tools, each of which is simple to use. They know when to use each to make a process easier. Having fewer options would make their life more complex, not simpler, because they wouldn’t be able to break what they need to do down into individually simple steps. A professional’s experience-honed conceptual model helps them navigate a wide range of tools.
Yes, this. It’s one of the reasons I use Lightroom for work. Another one being that the rest of the studio is on the Adobe suite, so I can send DNG with embedded XMP from Lightroom and they can continue the work in ACR when needed. Lightroom is boring but works, darktable/RT truly excites me! 
4 Likes
After I had posted the long read, the lingering question was - why do we have to put so much effort into revising one raw processor or the other or choosing between them?
Is it not possible to take the best bits of each, without having to, re-write the code and merge them into a single darktable module.
My other side is musical, and in that world, the digital and analog processing there does not think only in terms of this processor or that processor, when you can have a bit of this and a bit of that. You could plug any digital processor anywhere in the chain, In series, in parallel, like Shakespeare said - as you like it… For example, you can have several equalisers in the chain, each doing what its best known for. Top end (high frequency) enhancing, another processor for the bottom end. (bass). By the time we listen to most music, its been through several equalisers. And in that world, its normal.
In that world, plugins are the norm, taken for granted, and it all works together, from different developers, seamlessly without any committees to decide. I am not the first on this thread to publicly express a wish that darktable would be plugin enabled. Who knows, one day, one day…anything is possible…
We are familiar with HDR, Focus stacking, Panorama composites, combining images.
What’s stopping us, as end users, when we do not have the interest, responsibility or ability to code digital light benders(e.g. modules), from taking the output of one image processor and combining it with the output of another raw processor, in our own custom ways, in series, in parallel or both, not bound to whatever each processor design is capable of. And this can happen outside of darktable, or inside darktable.
So that’s how I have used sigmoid since my prior post, in combination with other raw processors, and each is chosen, by experience/testing, for their strengths on different areas of the same image. Colour rendition, highlight control, contrast definition, etc.
With this revised compositing approach, I’m 100% satisfied with sigmoid, just as it is, for my current use case, and appreciate the aspects in which it excels, moreso since I no longer have to choose one way or another, with only one image processor(or module), for all of the scene to display referred transform.
I’m now familiar with the sigmoid controls, so for me, no longer an issue.
Here is an image composited from s-t-d referred processing with sigmoid, and the s-t-d referred processing from another raw processor.
Some of my previous efforts on the same image here :
The raw file is in the other thread.
The article might have benefited from distinguishing between “simple” and “easy”. “simple” is the opposite of “complex”, while “easy” is the opposite of “complicated”. (to its credit, the article stays firmly within “simple”/“complex” , and does not mix metaphors)
I find this distinction particularly useful in the discussion of photo editing tools:
Luminar, for example, is trying very hard to be “easy”. Few sliders, much magic, very “artistic” names. There’s a slider called “drama”, and another for “punch”. It actually is quite usable that way. But the hard part then becomes predicting how that slider might behave and when it would be useful.
Darktable, to my mind anyway, is striving for a “simple” interface. One where every slider has a single function that can be easily understood. The hard part is more in how to effectively combine these tools, and less in understanding them individually.
The thing is that there probably is a particular combination of settings in Darktable that is a reasonable approximation of “drama”. But not vice versa. Filmic can not be emulated by adding “drama” to “punch”. On the other hand, it probably takes a bit of an analytic mind to enjoy the technical nature of Darktable.
To bring this back to the sigmoid module, it seems to reduce complexity without losing relevant functionality, thus making things easier and simpler. Perhaps the key word here is “relevant”. What I might consider irrelevant might be relevant to someone else. More importantly, I might consider something irrelevant only because I haven’t understood it yet
I don’t have answers. All I know is that the color preservation modes in filmic confuse the heck out of me, and sigmoid’s hue preservation looks like the rational (easy?) solution to that problem. Which I highly appreciate.
4 Likes
I don’t think it works like this. You’d need to re-code and maintain that code after.
This is essentially what darktable has with the pixelpipe, but since darktable is written in C, you must compile it all together, so we can’t just distribute plugins ad-hoc.
There is merit in the idea of plugins and there are several good examples where user-maintained plugins work seamlessly with the core software. Take Blender with add-ons, video NLE’s like PremierePro and DaVinci Resolve with e.g. Boris FX plugins and indeed the whole professional music industry with VST samplers, synthesizers, effects and libraries.
I can imagine @OK1’s idea quite well, where you would perhaps load a custom DLL, and then another module shows up at a designated spot in the pipeline of darktable. The biggest downside of such a model is of course compatibility.
2 Likes
I didn’t say it was a bad idea, rather that we basically have a plugin system already.
2 Likes
“plugin architecture” goes to the foundations of a particular software, rather hard to implement it retroactively.
That said, doing such to my hack raw processor may be the next thing I take on. It’s already organized to use such a mechanism (arbitrary workflow), and a plugin interface would let others do what they will, without by-your-leave from me. Every tool a plugin…
1 Like
I’m guessing the majority of OpenFX plugins will happily operate if you feed them only a single video frame.
Or: There’s already a fairly well established image processing plugin standard used by both FOSS and proprietary software.
That would handle most potential compatibility issues.
That’s a very personal wish.
I respect that, still, a very personal one.
Trouble to whom?
Again, a very personal opinion, clearly not shared by developers and those from the community closer to the development process.
With all due respect, I understand that newbies (in dt, in the community) may have these thoughts at start. What I don’t understand is why they insist and invest so much time on this discussion, even when all evidences show them it’s a void discussion. Why not spending that time learning more the tool, even sharing what they learn by producing tutorials, for example?
5 Likes
Just want remind everyone that this thread isn’t the place to discuss everything about darktable. Try to stay on topic with feedback on the sigmoid module, especially true for everyone trying to defend darktable. Just ignore or remind off topic comments about the topic of the thread rather than bringing in all the armor and weapons. I have no problem with lengthy discussions on the nitty picky details on the current sigmoid module but we have to stay on topic for this thread to be usable.
Examples that are off topic: plug in architecture, general darktable ease of use, any comparison to other softwares that isn’t focusing on their tone curve, Foss comments etc.
Rule of thumb: will this comment help Jakob improve his code such that the module gets good enough for a merge? Does this comment make Jakob smile such that he will spend more time on developing? Criticism about the module?
Yes? Please post here!
Uhh or no? You should probably post in a different thread or not at all.
Thank you 
19 Likes
Your ignoring the pipeline and the role in DT correctly processing images…adding plug-ins not written for DT is not as easy as just making them available and sigmoid is not a plug-in
An example with only sigmoid + tone-eq (which is what I now use instead of shadows and highlights module, to remain true to the scene referred workflow) + sharpening(input sharpening with raw denoise, output sharpening with sharpen and contrast eq) + local contrast. + exposure + white balance adjustments.
With really well exposed images, sigmoid delivers a good result, with its characteristic added “shimmer” in the highlights(of all the comparable modules in dt), works well for images like this taken in bright sunlight.
Ignore the funky green blocks on the left and top of the image in darkroom, which I think is something with how this dev version displays the edge of images. This only shows up in the editing window, not in the final exported image.
.jpg.
1 Like
If I may add, explicitly. For “poorly exposed” images, typically images taken in environments with very bright highlights, such as backlit images, where the shadows are dark in the raw image, and one would ordinarily have used the shadows and highlights module, a key challenge with scene referred was learning to apply the tone eq module to achieve a similar role, to lift exposure only in the shadows.
This approach has been key to solving some of my key challenges with sigmoid, and filmic.
I do hope there is a scene referred version of the shadows and highlight module, in the works. Cos while it is possible to achieve something suitable with the tone-eq module, having a dedicated module for this similar to the current shadows and highlight module, with fewer sliders, would be more effective.
I tend to view the tone-eq as a module for localised broad contrast shaping, but not a tool to be used for the broader kind of xposure changes, across the entire image, which the shadows and highlight module (scene referred version when it arrives), would be more apt for.
Relevance to this thread. I can imagine many may struggle at first with filmic and sigmoid, if they continue to use the current shadows and highlights module, as I once did, with less successful results. Th authors of sigmoid and filmic may wish to include this tip in the documentation, and in their demonstration videos/ comments on forums, as I have found this use of the tone-eq, to be a lifesaver, in the interim period, where we do not have a suitable scene referred compatible shadows and highlights module.
In an ideal world, we would have had all the scene referred versions of the modules we have been familiar with, delivered with filmic/sigmoid, to avoid us breaking the scene referred new rules.
Some would think that exposure alone would do the trick, but it does not, cos it applies to the whole image, when as stated above, what you really want is only the shadows lifted. Sure some clever workarounds like using a mask to lift xposure in only shadows is thinkable, but a scene-referred shadows and highlights module - highly anticipated if I may add, is key to the efficient use of filmic and sigmoid (hopefully sometime soon, this will not be a issue any longer)
We already talk about using Tone Eq instead of Shadows and Highlights here: https://www.darktable.org/usermanual/en/overview/workflow/edit-scene-referred/
I don’t think we’ll get a scene referred Shadows and Highlights module because, as you mention, Tone Eq can do what S&H did and a lot more.
You might also want to look at the rgb color balance module. You can modify shadows and highlights there both luma and color and you can now define the shadow, highlight and midtone areas of images and display the mask of each tonal range…
The “recent” modules, sigmoid and filmic, achieve something beyond simply transforming from scene to display referred. Once well understood, they encourage me to get out there and take photos, with the knowledge that I have a fairer opportunity of coming back to the computer, with much more control than was possible with the base curve.
I am uncomfortable with comparing sigmoid and filmic, but its difficult to describe one without referring to the other, like if everything were blue, it would be difficult to describe. White only makes sense if there is something else to compare it with.
Because these two modules have different controls, its also impossible to actually compare them, cos if you had all the time in the world, maybe you could come up with settings that would make an image almost indistinguishable from the other. So any statements of a trend, are based on how each module “pushes” me to use them, and make adjustments with them, and the result thereof. Your mileage may vary, from mine. These opinions are not based on the default settings, but on how I have tended to make changes from the defaults.
From recent images, my opinions, from trends that have developed in my use of them are :
-
sigmoid tends to deliver images which pushes aspects of the image more into the extremes - dark and bright, leaving less information in the mid-range. So you get more contrast broadly speaking.
-
sigmoid also tends to deliver images where there is less separation between colours, pushing shades of yellow and orange nearer to each other, and in greens you get less of a separation between the various greens. It is the same with other colours, but in the examples I have posted here, the predominant colours are the yellows and greens.
If there was one wish for sigmoid, it would be one more control (ideally three or four), so one could control the contrast globally, with another set of three controls to manage this contrast with more control, in the shadows, midtones and highlights. Maybe we are now stepping on the toes of other modules in dt. But I did check and to the best of my knowledge there is no other module which gives you control over contrast in shadows, midtones and highlights distinctly. I make the layman’s assumption, as I am only an end user in this case, not a physics professional, that the chroma observation, which I mentioned in 2 above, will also be adjusted by these controls, so you can have more or less separation of colours, globally or in shadows, midtones, and highlights when the luma contrast is adjusted.
Then there will be introduced another challenge, adding controls to adjust the crossover between the shadows and midtones, and between midtones and highlights.
Then one more wish, 3 controls more controls to adjust the luma (darker or brighter) in the shadows, midtones and highlights. Note, I have not asked for a global control of luma, as this is already included in the exposure module, and ideally should not be duplicated, elsewhere.
To the casual observer, unless you had the images side-by-side, you may not be able to tell any difference. Broadly speaking this gives the current sigmoid images a bolder, more vivid look, more binary, monochromatic, which lends itself well to certain kinds of images, where the colours look more like the result of reducing luminance via the “color balance rgb” module. Greens are darker, yellows are darker. Somewhat like the effect of having used the local contrast module.
Sigmoid–
Filmic–
I thought it good to express this via curves, cos some of this could be simulated via curves also.
If you had two fixed points for the transition between shadows and mids, and between mid tones and highlights, its possible to then use three other points on the curve to modify the dynamic range of each of the three regions. I’ve used curves only to hopefully make it easier for you to understand what I had written earlier. I do not have the mathematics skills to fully describe the additional controls which you may wish to consider. Curves may make it easier to convey what I mean.
Curve example. compressing dynamic range in each region.
Curve example, lifting the shadows only. all other regions have no change.
Curve example lifting only the mid-tones.
Of course in an ideal implementation these mid points will not remain on the linear line, but will have some “latitude” to move up or down, with changes made in each region, leading to two other possible controls. So that’s 8 controls in total described below.
This introduces the potential for what I call a super highlights region a 4th. Typically the brightest whites or light/bright colours
- to set the transition point between shadows and mid tones.
- To set the transition point between mid-tones and highlights.
- To set the transition point between highlights and super highlights.
- Adjust gradient up or down, in shadows (i.e lift shadows, or crush blacks more)
- Adjust gradient up or down in midtones ( less contrast - brighter, or more contrast - )
- Adjust gradient up or down in highlights.
- Adjust gradient up or down in superhighlights up or down.
- Adjust gradient globally, to make it more or less contrasty.
- Adjust latitude of transition points, i.e how far up or down they are allowed to deviate from the set position, when local adjustments of gradient in the 4 regions are modified.
I can imaging this sound really like a lot. But I have come to accept - this is the mindset of darktable and the darktable developers - more control not less. So rather than me try to simplify things, why not fully explore it to create something that is quite flexible, even though novices may find it difficult to comprehend, at first.