Thanks, but if you check that topic, you’ll see it’s mostly me stumbling. 
Maybe there will be something coming out of it, I don’t know.
For now, you may want to drag an instance of color balance rgb above sigmoid, and use its lift/power/gain controls to post-process the tone-mapped result. In the AgX code, that is done before applying the outset matrix and the linearisation, so the effect would not be the same, but maybe it’s worth an experiment.
2 Likes
Boris, your “stairway to heaven”-edit leaves me thinking, you can make a piece of art out of almost every photo 
Thanks for the last great videos - again very usable hints and repetition of valuable tipps from your other lessons.
We learn so much from watching your mousepointer and listening to your thoughts - but your masters eye of seeing what a photo needs to “wow” - is probably a lifetime’s experience. Being able to learn the techniques behind your mouse moves is already a lot for us to do.
Keep on! (please)
4 Likes
Now you can, there’s an AppImage in the topic. 
3 Likes
I agree from a theoretical perspective, but the tonemapper has the difficult job of mapping to both the output tonal range and the gamut, so it has to make a compromise somewhere: how much to compress, how much to shift, etc.
The key revelations in @s7habo’s recent videos for me was the restriction to sRGB and learning to like the smooth transition desaturated highlights. Now that I am applying them in my own edits I find them appealing. In practice I am viewing on sRGB devices anyway (or printing, even more limited gamut) so it makes sense that I use sigmoid accordingly.
1 Like
Just checked and I have the same low 720 setting! I can now see the module names clearly. That tip has made my day.
3 Likes
Yes, that’s a good point (my own Java experiments also combined gamut compression with tone mapping). However, that may not be enough: modules that come after the tone mapper (local contrast, an rgb or tube curve or any other display-referred module, which still run in the wide-gamut working space) may break that again.
It may make sense to switch to the output profile right after the tone mapper, and actually encode data using the output primaries. That way, an RGB curve limited to 0…1 will have no possibility to push ‘sRGB colours in Rec2020’ back out of the sRGB gamut.
2 Likes
Certainly, but I think that the long-term design goal is to make the scene-referred workflow a complete solution so that you can do everything before the tone mapper. Personally I find that I can always do this.
2 Likes
That would be a nice goal indeed. You could select the output color profile directly in the tone mapper like you do now with Sigmoid.
This would eliminate the endless display-referred scene-referred dilemma and darktable would have a clear processing strategy that would be much easier to explain to new users.
I also realize that this would not be smart at the moment, but as a long-term goal I would welcome it.
Me too. I don’t miss anything that will force me to use any module from the display-referred area.
1 Like
I completely agree. A great goal to work towards, but we’re not quite ready for it yet. I’m surprised how much I still use display-referred modules actually. If they were to disappear overnight, I could still get by without too many problems, but some of them I just find really useful and/or user friendly.
As an example, Color Equalizer has mainly replaced Color Zones for me, but not completely. Sometimes I like to use the “Select by” feature of Color Zones and select by chroma or lightness. Color Equalizer only selects by hue, so I would need to use parametric masks to get close to the same functionality. And I still use the Local Contrast module a lot. But I generally use display-referred modules just as a preference rather than as a necessity.
In general, I would be in favour of moving 100% to scene-referred and making this Darktable’s only workflow. Some people would not be happy about this, but I think it would clear up a lot of confusion and ultimately remove some of the complaints.
1 Like
That may be difficult for some of the “effect” modules like watermark and framing, where you do not want changes in colour and contrast, so you don’t want them to pass through the tone mapper…
But for me such modules are not really part of “editing the image” anyway
1 Like
Thank you @s7habo great video and very illustrating explanations. It is worth watching It twice. At least
1 Like
I think it does not make sense moving totally into working with modules before the tone mapper. If you want to color grade fully, especially the lightest highlights to something other than white, you should do it after sigmoid/filmic.
Thus it does not make sense to include gamut compression in the tone mapper (at least only).
2 Likes
Hey glad I could help someone at least! I quickly realized I was in over my head on that thread, like Donny in The Big Lebowski - out of my element. Interesting to read the discussion though.
1 Like
Based on the latest (excellent) tutorial in this channel, I am experimenting with color look up table to replace those.
I think that Lab is scene-referred (someone please correct me if I am wrong), and the module uses radial basis functions to interpolate, which solves the spline monotonicity problem for me.
I know it is not a drop-in replacement, but I consider working in 3D space instead 3 x 1D space an advantage, it is much easier to isolate a specific “color”. I rarely want to do something to “all greens”, I usually want to tweak a specific area, and in color equalizer this is not feasible.
1 Like
It’s not, at least L is perceptual, so more or less proportional to log(intensity). And on hover, the module tells you it’s display-referred. But that shouldn’t mean it’s unusable, just that you have to keep an eye out for problems at larger corrections.
1 Like
I looked it up and for large values, L = Y^{1/3} but the XYZ to Lab conversion code in Darktable does not enforce bounds (if I interpret it correctly) so it can function just fine in the scene-referred part, it’s just that luminance adjustments are not on a physical scale, but they are consistent.
I wonder if reimplementation in some other color space, eg XYZ, would make sense. As long the UI enforces that replacement colors are valid, it should work fine since XYZ is a convex space and the interpolation uses a convex combination.
And BTW, you have this information into the module’s tooltip (if it is scene or display referred).
1 Like
This is not my area of expertise, so excuse my ignorance. Are you talking about Color Lookup Table here? What would be the advantage of reimplementing it in XYZ? Would it work exactly the same but just not using LAB?
I love this module but it’s only good for micro adjustments. If it could somehow be made to be more robust (being able to push sliders further without introducing halos, etc.) for the scene-referred workflow (for manipulating a linear input), I would love it. I submitted a feature request for it to be in unbounded RGB, but apparently it was too complex. But because I don’t really understand all these colour space complexities, maybe my feature request was just not good enough.
Closed Github issue for those interested: Convert Color Lookup Table to unbounded RGB and/or a scene-referred friendly colour adjustment module · Issue #15295 · darktable-org/darktable · GitHub
1 Like
I am not an expert about color theory either, but I don’t see why handling unbounded spaces should be very difficult. Sure, it would require a rewrite, but that’s just the kernel that does the actual adjustment.
Perhaps the thin plate spline interpolation would need to be replaced by one that does nothing in the limit. Ie when the control points are x_i \mapsto y_i in some space, the mapping should have the property
\|f(x) - x\| \to 0
as \max_i \| x - x_i \| \to \infty.
(Here x and y are generic coordinates in some colorspace, not the xy channels of xyY. Also, this is only relevant for the unbounded coordinates, all 3 for RGB or Y for XYZ).
Doing the mapping in RGB could have some undesired interim values, but I am not sure if that’s an issue here. If yes, it should be converted to an LCH-style color space.
(Sorry for going off-topic here. If this gets more replies, I ask the admins to kindly split this into its own topic.)
Possibly, but your original remark to which I replied was