New Sigmoid Scene to Display mapping

Hi there, first time posting both here and in the darktable github repository.

I spent some time getting familiar with the darktable source code this Christmas and ended up with something actually interesting and figured I might as well share it with the rest of the community.

It’s a tone mapping / look transform / scene to display conversion (or whatever you want to call it) that is based on a sigmoid function instead of a cubic spline like the base curve. I’m not 100% how the filmic module is implemented so I will leave the exact comparison to that out for now. The purpose is the same though.

THIS IS ONLY A TEST BY ME SO FAR. Not endorsed by any other developers yet.

Head over to https://github.com/darktable-org/darktable/pull/7820
if you want to try it out (assuming you know how to compile), read more details or see comparative examples.

I will leave this post simple with some results. All have large exposure corrections and some white balance applied. The rest is specified under. Please add your results if you try the branch!

log-logistic, contrast = 1.4

log-logistic, contrast = 1.67
And that is me if anyone wonders.

weibull, contrast = 1.47

And some pictures from the forum as that gives you the opportunity to compare against other edits:

A study in blue
log-logistic, contrast = 0.89

Landscape by phweyland
tone equalizer, strong preset, log-logistic, contrast = 1.95

Lightning with long exposure
log-logistic, contrast = 3.07

14 Likes

THanks for sharing I will give it a try over the next few days…

How to install? darktable should have a “load simple plugin” function.

You need to compile the code in the pull request.

Too much C code for that.

1 Like

Mica I was going to try it but I am not that skilled at Git. I am set up to build the main dt git and I understand how to checkout a branch but this is posted on a personal dt git repo I believe…Would I clone that and create a separate install or is there a quicker way to work with the proposed code…any tips appreciated. Thanks in advance

Would this help?

1 Like

Way beyond my scope. Will wait for 4.0.0

I started to read something like that…I just wanted to be sure what I did was local and did not mess up my current files…thanks for the reference… Can’t seem to get the syntax right for the first step…

image

$ git fetch origin pull/7820/head:thiscanbeaynthingyouwant should do the trick. The BRANCHNAME is a local thing.

Edit:
The entire build procedure should be something like this

$ git clone git://github.com/darktable-org/darktable darktable-sigmoid # Folder name is optional
$ cd darktable-sigmoid
$ git fetch origin pull/7820/head:sigmoid
$ git checkout sigmoid
$ mkdir build && cd build
$ cmake -DCMAKE_BUILD_TYPE=Release .. # For Unix like
$ cmake -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE=Release .. # For Windows 
$ make -j4 install # Or whatever number of threads you want to use

My very first impressions after getting to know and playing with sigmoid for about an hour and not knowing if this module comes with a certain required workflow:

  • I think that a category of people will like this one; Just one simple slider and not all the complexity and fine-tuning that filmic rgb or the tone curve (in part) offer.
  • I find the slider to be very sensitive, even the smallest change possible (+/-0.01) is noticeable on my good, but not professionally good, monitor.
  • I get the impression that sigmoid (de)saturates too aggressively when changing the default setting. This can get ugly fast (have a go at the Noctilucent clouds image).

The above comments are based on very basic edits (wb + exposure only) and then comparing sigmoid with the filmic rgb and the tone curve. I do not use the base curve so I skipped checking against that one.

Just from my point of view I would most likely not be using this module. Not because it isn’t any good (which my above “tests” will not really show if that would be the case), but because I like/need the finer control that the other modules offer. People that want quick edits/results might be rather happy with this one, though.

Images I used for this session (all found here at Pixls):

3 Likes

I did some very limited testing as well and would agree. Decent results for very little effort. For me I notice the sensitive aspect as well. Also for me it seems to really crush the blacks I had to add exposure and black compensation. I just tried it on a couple of shots. For a first attempt not too bad. With some finer control without adding too much complexity it might have its audience…

If you install github’s command-line tool (https://github.com/cli/cli), it’s even easier:
gh pr checkout 7820

2 Likes

Welcome to the forum!

May I ask what the reasoning is for using a sigmoid function? Is it S-curve enough to just try how it looks?

The results you show look good. What are the differences between log-logistic and weibull? Does it work in a component color-model, if so which one?

Again: welcome!
Cheers

1 Like

Nice idea and prototype, I like the out-of-the box thinking here :slight_smile: Definitely going to give a try! Also love the images in this post.

1 Like

Thank you @PhotoPhysicsGuy!
I wrote a more detailed motivation for the use of these sigmoids over at Github, see the first post. But in short, they model at least the base curve presets surprisingly well and offer a straight forward parameterization that does pretty much exactly what you would expect.

Both work on the separate RGB components of the chosen working profile. The difference is in their shape which is easiest spotted in highlights where Weibull gives more punch. I recommend going back and forth on an image where you expect some highlights to hit pure white.

@Jade_NL and @priort I’m aware of the sensitivity, I left out the soft bounds on purpose, for now, to make it clear how wide range it handles without breaking down. Softbounds will improve the step size and make it less sensitive. I have also been thinking about defining the slope at 0.18 instead of the exponent/base, might give a different feeling to the how sensitive it is.

About black point and crushing shadows, could you post an example? My gut feeling is that you should work some more with the tone equalizer, graduated filter, or masked exposure changes to get that to work

And those are some nice test images, especially the Noctilucent clouds proved challenging!

Noctilucent clouds
sigmoid, log-logistic, contrast = 1.61
graduated density (for lifting the lower part of the image)
tone equalizer, custom
exposure
denoise (profiled), chroma only
white balance, 5413 K, bluer!

[Play Raw] Amulree Kirk
sigmoid, contrast = 2.65

Kingfisher: Softproof failure
sigmoid, contrast = 2.44

The last picture seems to have input color issues with the blue channel, those issues remain sadly so no point in posting the result from that.

3 Likes

Just for the record, RawTherapee also uses a contrast-based sigmoid function for dual-demosaic and CaptureSharpening to blend between the two demosaicers and the before/after of CaptureSharpening…

1 Like

@jandren: I’m about to go off-line for the day but I do have one request: Can you post your sidecars for the Noctilucent clouds, Amulree Kirk and Kingfisher edit?

I’m curious about what else, besides the sigmoid changes, needed to be done to your edits to get the above results. A quick look at the Kingfisher for example makes me wonder why I immediately noticed a (too) saturated background (the reds) when upping the sigmoid slider somewhat, which I do not see in yours.

Anyway, I’m off for now. Thanks for taking the time and effort to put this forward!

Thanks my initial problem was I thought origin was a place holder not the name of the command…thanks for your info…I managed in the end to stumble through it although I should have done it a bit differently I did manage to get it done…

@priort Glad you got it working. We could tell you what to do exactly, but the best learning is done by trial and error. :wink: That and I have an unreliable memory. :blush:

I agree. Sidecars are a good learning tool. It is good practice to include them.

Yes! Thank you and exactly what I was looking for. The ensuing discussion with aurelien as well. Sorry for not immediately checking out that link.

Per-channel math will lead to color shifts as the ratios of primary colors will get messed up…but that is being adressed in the github discussion as well.

There truly is a discussion to be had about the differences of a output look transform, a tone mapping operation (plus a seperate gamut mapping operation) and what control a user might want to have in which case and, more importantly, where in the pipeline. I think/hope that filmic is rather future proof with regards to upcoming (but when?) HDR10 output look-transforms.
Up until then your edits look fantastic on a calibrated sRGB monitor, so there is hope that these curves might somehow find their way into an appropriate module…even if it’s called ‘SDR-output transforms’.

I am looking forward to the ensuing discussions, also with regards to whether a pipeline should be more clear about where scence-referred ends and display referred starts and where certain creative decisions should and can live. (i.e. does one create prints from scene-referred data or from display referred?! both?)

I am sure this will be a hot topic! :smiley:

IDEA: this module acts as initial guess for the filmic module. If the polynomial in filmic is a more general and more flexible tool but can replicate the sigmoid from here… Why not start with a sigmoid, transfer parameters to filmic and open that one up for fine tuning and separation of rendering intent and scene referred adjustment?

1 Like