+1 here, as many other modules.
The look has nothing to do with the sigmoid curve (it’s applied as a separate step), and the dynamic range should also not be used to ‘shape the curve’, as it’s only important for the parameterization of the shared log mapping. The only parameters the curve has are those you can adjust here: Power(P) Sigmoid | Desmos : shoulder / toe length and power, and the slope of the linear section (plus the pivot point, but we don’t want to move that, it should take mid-grey to mid-grey; and the black and white output (‘display target’ black/white), but those are 0 and 1 for the polynomial, respectively).
I can try to reach out to the guy who fitted the polynomial for the params, there’s no need to guess.
The two curves should be indiscernible (see the plot here: Minimal AgX Implementation | IOLITE).
I’ll double-check the implementation sometime this week, but not now.
Don’t you want to give a lightning talk at LGM about darktable AgX?
@Tatica @eylul and me will be there and someone from this community named Simon as well (I don’t remember his nickname). Looks like the meeting and the community is coming back slowly but finally.
Maybe you could even still send them a proposal for a longer talk, so you could get back the traveling costs.
1 Like
@s7habo Hi! I have been experimenting with the agx module myself and tried a couple of playraws. I really love using the module so far, it produces beautiful results fast!
I had only one problem. Sometimes in the waveform I can see that some colors shoot out of bounds and if I try to squeeze them in the range the overall contrast suffers.
Especially difficult case is this one: "Analogue Style" in Digital
If I use agx I find it difficult to manage the reds. Whatever I do the red coat of the child will burn a whole into my screen.
20230824_0182_03.RW2.xmp (14.1 KB)
I found that this problem is common for many images but it’s especially bad with this one.
Sigmoid and filmic keeps colors from clipping automatically. How can I keep the colors from clipping using agx?
My settings for refrence (can be found in the xmp too)
Your photo is oversaturated.
Reduce the saturation in AgX…
…and increase it in Color Balance RGB practically before the data comes to the tone mapper. Make sure to increase the saturation in shadows and mid-gray and not too much in highlights:
3 Likes
The gamut protection (‘guard rails’) will come later. Please bear with me.
4 Likes
Thanks for posting this, now it is much more clear, even though I have not reverse-engineered all the algebra yet.
Compared to sigmoid, I see three extra features:
- Moveable pivot point (the part that maps to the “middle gray”. This is great because the pivot is the region of highest contrast, and it is great that one can move it up and down.
- A customizable linear region below and above the pivot (toe-shoulder).
- Toe and shoulder limits (y = 1 and 0). Of these, the shoulder limit can be approximated with sigmoid (target white) but it is much more difficult to control how blacks go to zero there.
- Polynomial starting point. Polynomials have much better behaved slopes than exponentials, which are all over the place, and sigmoid is a double exponential (because of transforming \mathbb{R} to \mathbb{R}_+).
What I find tricky about this function:
- the slope of the “shoulder” part hitting 1 seems accidental, sometimes it goes smoothly to 1, sometimes there is a kink. This is an outcome of other parameters and hard to predict (without having the curve to look at).
- the toe limit seems to have a maximum that does not coincide with what I think the curve could do visually.
You are waaaay ahead of me on the algebra. I don’t work with maths, at all, and it shows. I don’t think I’ll ever dig down to the bottom of it.
The author of the curve, Jed Smith, has several posts in this topic:
I did not expose the pivot, but you’re right, it may be useful to move it from mid-grey. Next time.
The shoulder limit I don’t see as important: people have been complaining about loss of detail with the sigmoid module; the result of the logistic function approaching 1 smoothly. They used the target display white as a workaround. With this sigmoidal function, the toe and shoulder allow one to hit 0 and 1 at an angle (controlled by the power), so I’d argue those sliders are really not needed.
It used to be exposed in filmic, but was hidden at some point with the reasoning that it should be set with exposure.
Don’t have any particular opinion on the matter myself, but not exposing it would be consistent with filmic and sigmoid, at least.
1 Like
The trouble is, that would require placing the subject at mid-grey, even if it is brighter or darker.
I have no strong opinions, either. color balance rgb provides a customisable contrast pivot, but it’s supposed to be masked; an alternative is tone equalizer. On the one hand, I’d say let’s not overload a tone mapper with too much functionality; on the other, if it helps many ‘simple’ edits, without additional modules and masks, why not.
The contrast algorithm gives natural results that mimic the central part of the contrast curve of analog film. However, it will also increase the image’s dynamic range, which may void filmic settings in the pipe. For global contrast adjustments, you should normally use the tone equalizer module – the color balance RGB contrast slider is best used with masks, e.g. for selective corrections over the foreground or background.
(darktable user manual - color balance rgb)
This is still CPU-only, right? I think there should be an opencl version. Seems a bit slow with a 4k screen.
Yes, see:
The reason is:
It’s easier to optimise working code than to get optimised code to work.
Plus, since we don’t even know if it will be a module of its own, or simply sigmoid can be beefed up (it has all the nice gamut protection features and can transform primaries, maybe all it needs is a drop-down to choose between the curves and and expose log-mapping params to set the dynamic range).
Even if it remains an independent module, currently all the internals are in motion, it would be wasteful to optimise now.
Finally, I don’t know OpenCL (and also don’t know OpenMP). I’m not a C developer, and have never been (not since university).
7 Likes
Exactly, this is a major assumption in both tone mappers without a good reason. Why should the highest slope be at mid-gray? Yes, generally it makes sense, but should be customizable if the image requires it.
I also find the results interesting, especially that I dont need many other modules for the photo to look good. I will test the speed on my normal screen too. If speed is ok on normal screens, it might be worth including it in dt 5.2, even if there is no opencl.
When could this land in the master branch?
I think it is too early for 5.2 or even master. Kofa is doing an excellent work to get a proof of concept first, before it even becomes a PR.
3 Likes
Once it’s ready. 
There is not even a PR, functionality is not complete. I have not even asked the others if they’d be interested. Primarily, it started a learning experience for me. Since others seem to like it, I hope it will be incorporated in some way (not necessarily as a new module, maybe just as inspiration for some others). I intend to add that desaturation/gamut protection thing, and then we can start taking it to pieces in a PR, and cleaning up. Right now, it’s a mess, with code not aligned at all to how darktable’s modules work – I did whatever was easiest to port over from the Python scripts, much of it using LLMs (yes, I know). That’s why it’s a proof of concept.
6 Likes
I thin that a generic tone mapper could work like this for luminance:
- map [0, t] to 0, [s, \infty) to 1 (“toe”, “shoulder”),
- map [a, b] to [A, B], which implicitly determines the linear region and its slope,
- connect with a monotone, smoothly diffentiable mapping that matches slopes at endpoints for [t, a] and [b, s]. Whether this needs to be parametrizable is an open question. It should be fast, so a polynomial is ideal.
This has 6+ parameters, with the constraints t \le a \le b \le s and 0 \le A \le B \le 1. I think this is what filmic does, minus one degree of freedom (midtones).
But the luminance is the trivial part. The key part is not monotone mappings, but color. It is unclear how much effort should be made to preserve hues at extreme values etc.
1 Like
You can read about the design of such a tone mapper here: Filmic Tonemapping with Piecewise Power Curves – Filmic Worlds
But for this module / topic, let’s not design a new one, just use what someone else has already created.
1 Like
Sorry, that was not my intention, bit I failed to explain it clearly. I wanted to make this point:
- The description above nests the AgX tonemapper (if I understood correctly), except for the smooth differentiability.
- I don’t think it matters much though, the key part is in the color handling.
My intuition is that if you get the color handling right, the nitty-gritty details of the luminance mapper don’t matter much. In other words, these mappers differ mostly because of that.
Oh I have the feeling @Pascal_Obry would be very interested in having this as a new tool asap in master.
Apparently darktable is not so young any more but still very fertile…
1 Like