@jandren , I’ve just built Sigmoid and it’s version 3.7.0+392~g3f5fa5f32.
Before I go much further, is that to be expected? I only ask because 3.7 is old and I might have built it wrongly.
If you just did it it should be fairly current…
Look in preferences and see if it has the new performance menu in processing…that is fairly recent…if not maybe you did something with your build or its just a bookeeping thing on Jandren’s end???
Probably you only fetched Jakob’s remote and that doesn’t happen to have the 3.9.0 tag? That’s what could have happened here.
1 Like
Glad you took the hint. 
1 Like
The key steps I did are -
git clone git://github.com/darktable-org/darktable ~/DT-top/DT-Sigmoid-26Feb22/darktable-code
git fetch origin pull/7820/head:sigmoid
git checkout sigmoid
git config submodule.src/tests/integration.update none
git submodule init
git submodule update
./build.sh --prefix $HOME/DT-top/DT-Sigmoid-26Feb22 --build-type Release --jobs 5
I got some of that from higher up this discussion.
Do those commands shed any light?!
Is the hue protection with this constraint the same, or very similar, to doing the per-channel rgb tonemapping and then copy-paste the hue channel from the scene hsi color model?
Interesting as always!
The fault is on me, haven’t paid attention to updating the tags of my remote. Fixed, so it should build with the correct version number! (A bit of a reminder of how long I spent on this!)
You might need
git fetch --tags
@age Yes!
The hue reservation is always done to the percentage you choose! The energy preserving constraints mean that either the min or max channel will have to be altered as well while still maintaining those relationships. The reason for letting the amount of energy preservation fade towards the gamut boundaries as we otherwise can’t reach the full gamut.
1 Like
Hi, I’ve rebuilt, this time with that fetch command (I put it immediately before
git fetch origin pull/7820/head:sigmoid )
It’s the same build as before, 3.7, and I can see it’s not got the latest modules and features.
Is “7820” still correct?
I haven’t used git or built anything in a long time, so my remark may be invalid: Could it be that you have old files or flags that you need to clean before building?
Thanks @jandren
So the blending factor is pratically an inverse saturation mask, what about inverting the saturation channel from hsi or hsv?
Sorry for all the questions
Thanks but I don’t know, I don’t know git. Jakob is helping me offline, hopefully we’ll get it sorted!
So for values that are clipped (not in raw, but due to editing parameters such as boosting exposure), sigmoid will not bring them back in range the way the log aspect of filmic will? Thus sigmoid will need to be combined with other modules to achieve that?
What do you mean by clipped? If data is clipped at any point of the workflow, then it is gone forever. I am guessing what you mean is values end up being outside of output/gamut range. In the case of sigmoid, infinitely small and large values simply approach 0 and the max allowable value. Added features such as colour/hue preservation could do something funny if not handled correctly.
It may be less than elegant but I just cloned the master into a second directory called darktable-sigmoid instead of darktable and then merged the sigmoid branch into that and then followed the regular build instructions to create an install package…
I worked this out during an exchange some time back with another user…
chhil.pdf (114.5 KB)
2 Likes
Yes not the data that is lost forever, but the data that is out of display range but can be retrieved. It will appear White and if we turn on gamut or luminosity clipping indicators they will show clipping. In the filmic workflow, one brings this data back in range with the relative Black and White points, a log operation. I’m wondering what the suggested way to bring them back is in a sigmoid workflow.
My impression is that the entire data set gets mapped to display, fit to curve, so black and white[1] points do not need to be defined explicitly, although integrating reference points could be beneficial. I think @jandren mentioned the possibility of adding a white point control, but I will let him clarify. Good question.
[1] filmic and filmic-like algorithms have a builtin arbitrary high white point according to ACES specs. dt’s implementation adds nuanced controls that either complicate or simplify matters depending on your perspective.
I think the easiest way to understand and feel the difference is to try it out yourself.
And I can definitely recommend trying out my exploration “tool” I made like a year ago:
Tone Curve Explorer https://share.streamlit.io/jandren/tone-curve-explorer
Either as a complement to trying out the actual branch or just by itself.
The log-logistic curve is a different approach than the cubic splines in log space that darktable’s filmic rgb does but the results are similar. You just reduce the contrast if you want more dynamic range. But again the log logistic curve never clips, it converges and you control where you want to put your contrast, i.e. gradients, by spreading it out (lower contrast), compressing (higher contrast), shift towards shadows (negative skew), or shift towards highlights (positive skew).
But remember all the other tools you have at disposal, the tone equalizer, color calibration, masked exposure, and color balance rgb are all tools that can be used to compress dynamic range in scene-referred space before the display transform.
I will see if I can make some more examples but there are already a couple in this thread on the topic so I recommend reading them by sorting out my replies in the thread. Press my username and then press the “#posts in this topic” under the big blue “Message” button to the right!
4 Likes
Nice to see you’re still working on this! Your toughness is really admirable .
Tried your new version today with really nice results.
Imho filmicrgb’s standard settings improved a lot since you started this thread and that it is far better to handle now. Right from scratch the results are often so close that it’s hard to say which module was used.
Sigmoid still shines when it comes to the transition zone in highlighted areas, close to clipped/lost pixels. Or in HDR scenes like this:
(example from polyhaven Spruit Sunrise HDRI • Poly Haven)
sigmoid standard settings, (contrast 1.6, per channel, preserve hue =100%).
filmicrgb standard settings
sigmoid (contrast 1.0, per channel, preserve hue =100%).
spruit_sunrise_4k_01.hdr.xmp (6.3 KB)
filmicrgb, auto tune levels
spruit_sunrise_4k_02.hdr.xmp (6.1 KB)
Hint: Look for the HV pylons in the highlighted area.
7 Likes
This highlights (pun) the importance of discussion and alternatives. I believe that is how our community, software and techniques grow. Thanks for the examples. I am sure it will help our users and devs.
8 Likes
Thanks for doing some tests @pass712!
I made an attempt myself and I can fill in with some of the knowledge I have been acquiring the last 15 months of working on this!
- Contrast = 1.0 makes dark shadows “linear” but not mid-tones and it isn’t a “unity” setting. 1.2 is actually closer to delivering unchanged chroma for mid-tones. I would recommend staying in the ~[1.2 to 2.0] range for the contrast setting when using skew = 0. (Contrast 1.22 and skew = 0.66 is close to linear all the way up to 0.1845 but it will have a harder cut off at the top.)
- Use other tools for compressing high dynamic range pictures like these. I used a combination of tone equalizer with preserve details = no (under the masking tab), @s7habo trick with reducing the blue channel brightness and increasing its colorfulness in color calibration, and a color balance module to add more chroma to highlights.
- Don’t be afraid of blowing out pixels on your display! We edit the image before the display transform for a good reason, the pixels aren’t actually “blown out” before and we can do a lot more without fucking up. I would make this image a tad bit more contrasty if the point wasn’t to show how to apply a lot of compression. Something like this (haha almost the same!):
5 Likes