New Sigmoid Scene to Display mapping

The focus of the post was how to handle color. I thus deprioritized finding a perfect shape for the curve. Maybe it isn’t enough with my word and I can redo them in that case but fiddling with the look parameters should only have a minor impact on the results as the main driver of the look is the method of mapping: per-channel (preserve colors == None) vs rgb-ratio (preserve color == “On”).

I can recommend playing with my curve explorer tool: https://share.streamlit.io/jandren/tone-curve-explorer
If you want to compare the shape of the curves. It’s also easier to understand in that tool why filmic has a tendency to crush shadows when comparing the methods there.

1 Like

@jandren , hi, yes I did have a sigmoid module, it seemed to be working ok on a very quick test.
Would you say the following are the correct git commands, and in the right sequence (I’ve guessed to put the “fetch all tags” straight after the clone) -

git clone https://github.com/darktable-org/darktable.git <folder>
git fetch --all --tags
git fetch origin pull/7820/head:sigmoid_tone_mapping
git checkout sigmoid_tone_mapping
git config submodule.src/tests/integration.update none AND SO ON

P.S. The easier you make it to build this, the more people will have a go?!

That does look correct to me. I’m not that much of a git guru so I think you would just need to resort to youtube tutorials or googling if that still doesn’t work. But you should be fine trying out the module even though you do not manage to get it with the other latest and greatest stuff!

I’ve been following his work to the point where I’m thinking of ways to potentially implement it as an option in RT’s tone curve module. (Side note, that has always had a variety of hue preservation modes - and I definitely want to dig in and compare both “filmlike” and “perceptual” to @jandren 's hue preservation implementation.)

Similarly sigmoid might be better for some applications than the dual-stacked-curve approach I’ve sometimes used in RT. The problem with doing this is that I SUCK at UI/UX coding and the UI/UX would be significantly different than the current options of the module…

3 Likes

Oh okay well I was just going from memory I think on another thread or back in this one he had saide he was going to or had updated his code base…

@jandren , thanks, I just tried those commands. They all seemed to work ok, however it’s still building against 3.7. The module’s not called sigmoid_tone_mapping though, in case that sheds light on anything.
sigmoid

Edit - ?? is the 7820 still correct ??

Thanks for clarifying. I was just trying to confirm if your choice was a mode that would be most equivalent to your hue preservation or it was set to none which it didn’t look like. Personally I often use one of the other modes than power norm even though it is the default. I don’t fully understand the math behind each mode but I know that they often give quite different results and this would be very noticeable on skin tone so I was just curious… In recent work on Filmic v6 AP seemed to have the default set on Max RGB…not sure if it was just the way it was left at that stage of his work or a conscious decision??

1 Like

I think he meant the branch of the code…that is named that way the module should be sigmoid…

That is an old sigmoid version as well so no not correct.

Didn’t catch that you cloned the wrong repo. You need to clone my repository if you want to do a fresh clone:

git clone https://github.com/jandren/darktable.git
git fetch --all --tags

Then fetch and checkout the branch

git fetch origin sigmoid_tone_mapping
git checkout sigmoid_tone_mapping

I know realize that it looks like you checkouted the old PR which probably is old.
Sorry about not catching it directly.

I think this approach might work also…this is how I did it originally working with another user…

chhil.pdf (114.5 KB)

@jandren ----PHEW!---- Finally got there!
Now getting 3.9.0+577~g78f301c14 including blurs and sigmoid and 2 colour options, per channel and rgb ratio. I will have a play over the coming days.
One thing to note straight away - it’s usual for a double click to restore the default value for a setting, but it’s not doing that.

If anyone else wants to build, these commands just worked -

mkdir -p ~/DT-top/sigmoid4
git clone https://github.com/jandren/darktable.git ~/DT-top/sigmoid4/darktable-code
cd ~/DT-top/sigmoid4/darktable-code
git fetch --all --tags
git fetch origin sigmoid_tone_mapping
git checkout sigmoid_tone_mapping
git config submodule.src/tests/integration.update none
git submodule init
git submodule update
./build.sh --prefix $HOME/DT-top/sigmoid4 --build-type Release --jobs 5
cmake --build "/home/<your username>/DT-top/sigmoid4/darktable-code/build" --target install -- -j5
$HOME/DT-top/sigmoid4/bin/darktable --cachedir $HOME/.cache/sigmoid-4 --configdir $HOME/.config/sigmoid-4

DT-top is just an over-arching folder for all my dt builds. The above starts dt with a clean slate, so you don’t have your preferences, styles, or I imagine personal presets etc.

2 Likes

A few years ago that was hardcoded/you didn’t have a choice.

The rationale I’ve seen is that it’s the only approach that does not have a risk of causing a color channel to go outside of the display’s maximum.

However the side effect is that it causes luminance to shift significantly with hue - and while hue is preserved, the perception of that hue changes due to the luminance shifts. Using max(RGB) as the norm on a sunset, for example, is a great way to make your image look like the aftermath of a nuclear war.

@elstoc @Jiyone Feel free to make your own comparisons. :wink: I am sure @jandren would welcome more representative examples of filmic. Since this thread is on the long side, it may be wise to start a new thread for that purpose.

2 Likes

I had wondered if it was in conjunction with the new model that he was using that was not doing the same desaturation … in any case the norms can certainly impact things often quite strongly and need to be considered in the discussion as they might be a major source of any observed differences when doing these types of image comparisons

Just make sure…I am think it will still be an issue…work on a copy of your images as normal versions of DT don’t know about the sigmoid module and it is possible to corrupt a database or xmp files with references to the sigmoid module by accident so be sure to keep things separate when using this version…

Awesome! :sunny:

Just to be sure: what I said was NOT in regards to the existing UI/UX in RT! It was about the complexity of designing a UI/UX for a CAM-display-transform in general as the complexity is so much higher for a CAM than for a ‘simple’-display-transform.

It’s really hard to accurately describe but easy to see. To my eyes it doesn’t look accurate or real. There’s a sort of pastel matte look with contrast that is as if it’s detached from the image. I’ve always preferred soft tones and low saturation in photographs but it’s some other aspect that’s being handled in a way that looks odd to me.

The effect is most obvious with white t-shirt man.

1 Like

This is absolutely meaningless. And its been discussed before, you’re expected to use Color Balance RGB (the preset works really well) to get the colors where they’re supposed to be. So judging colors after only applying filmic is pretty useless.

1 Like

I wasn’t assuming that - the main thing is that the current UI is pretty heavily biased towards a curve with editable nodes. But for something fully parametric like this… well I have no idea how I would shoehorn that into the UI!

1 Like

Oh, you meant the last two images on every row. I thought you meant the last two rows. I agree with your your way of describing the look. I’ve grown to accept it, but it is a rather strange type of desaturation that immediately catches my eye as a difficult starting point. It was more complicated to me when I started using darktable. Now I’ve sort of found some ways around it, but they’re not elegant.