I am not sure : correct me if i’m wrong but I think Filmic and Sigmoid have two very different approach :
Sigmoid seems to act like the base curve : meaning you can not directly choose the input dynamic range of Sigmoid (you can expand or reduce the input dynamic range with the contrast slider but it will impact the contrast of the picture). I think the default input dynamic is something like 8-12 EV (I don’t know, I will take 12 EV as example for the following).
So, you use other tools (Tonal Equalizor, Balance color RGB, etc) to make the dynamic range of the picture fitting the input dynamic range of Sigmoid. If you have a 3 EV picture or a 32 EV picture (HDR merging), you end up using other tools to expand 3 EV to 12 EV or compressing 32 EV to 12 EV. And then it’s done, you work on colors, details and local contrast on a 12 EV picture.
Example with a 18 EV picture (HDR merge) :
18 EV HDR => Tone equalizer, contrast (balance rgb), etc => 12EV => colors, details, etc => Sigmoid => 8 bit JPEG.
With Filmic, you choose your white and black input points. So Filmic take anything as input, and you work on that. You can work on a 3 EV picture or on a 32 EV picture, and directly edit colors, details, local contrast. You don’t need to expand or compress the dynamic range : it’s filmic which will do that. The Tone equalizer is used to bring back parts of the image independantly of others, but not to compress the whole range.
18 EV HDR => Colors, details, contrast local, etc… => Filmic => 8 bit jpeg.
it’s different in term of reasoning.
Am i right or false ?
Filmic : I know it can take anything (-16 EV ; +16 EV) as input. It can compress up to 32 EV pictures (if the neutral grey is at 0 EV).
What are the limits of Sigmoid ? Can it compress pictures having more than 16 EV ? (actual medium format camera).
Both filmic and sigmoid can take any dynamic range as input. Basecurve expects input in the range 0…1
With sigmoid, you can use skew and contrast to adjust the “white point” and the “black point”. Sigmoid doesn’t have a white reference in the sense of filmic, of a specific point mapped to 1.0 in the output; sigmoid’s mapping function never reaches 1 (or zero, for that matter).
While you can control the dynamic range that’s mapped, sigmoid still has less controls than filmic. That automatically means that you have less independent variables to play with, so more will have to be done outside sigmoid, compared to filmic. E.g. if you give sigmoid a very large dynamic range as input, you will have to lower the contrast a lot, giving a flat image. So you’ll need another tool to get at least local contrast back… Then again, with filmic also you run into cases where youhave to modify contrast elsewhere.
Is that simplicity of sigmoid an advantage or a disadvantage? Some like to do as much as possible with one tool, others prefer specific tools for specific jobs… And, we did manage to tame large(ish) dynamic ranges before filmic.
(I know there are differences in the handling of colour between sigmoid and filmic, I just wanted to limit it here to the dynamic range aspects)
Oh, and keep in mind that for both filmic and sigmoid “middle gray” is by definition at zero EV.You’re supposed to set that first (with “exposure”) as several other modules use that value as a pivot. (I know, you could change the “middle gray” pivot in filmic to something else than 0.1845 …).
Yeah, that’s exactly what my mind was trying to explain, but you did it far better than me and with better words !
Sigmoid needs more work on tonal adjustements outside of Sigmoid.
But Filmic needs more work on color adjustements outside of Filmic (Balance color RGB)… not because Filmic needs it, but because people are (unfortunately) familiar with the fact that the base curve (and Sigmoid) have big effects on colors (both saturation and hue) whereas Filmic just try to preserve as much as possible the input color.
Incidentally, I am still confused about where that is and how one would visualize it during processing.
For simplicity, consider a monochrome image, in the scene referred part it is a bunch of positive numbers. Is 0 EV 2^0? Or \exp(0)? How and where would I visualize the range of pixels that belong there, either in the preview or the histogram?
(This is just me being curious, of course I adjust exposure by eyeballing the output).
Let’s stick to grayscale and floating point, as used by dt.
Middle gray (for filmic as default) is at a grayscale value of 0.1845 (no logs or exponentials, please). This is declared to be at 0EV.
Just do a short search for “middle gray darktable” in a search engine.At least one other thread discusses this.
Note that a lot of discussions predate the scene-referred workflow (eg the one you linked is mostly about answering this question with display-referred modules).
Same for sigmoid. But the actual value is less important than the ways to visualize it. All ways I found are a bit cumbersome.
Is all the talk about middle grey really that relevant for users?
It seems it just confuses people when they are instructed to “set middle grey” and such things. All you really need to do is adjust your exposure to what looks good?
I’d like to propose creating a new forum category, maybe called “Technical”, where algorithms/math/code can be discussed without distracting or confusing people who are not interested in these details.
My impression is that whenever the conversation turns to code and math, many forum participants feel that the discussion is inappropriate, confusing or off-topic. I think this is quite understandable, since the forum’s main focus is on the art of photograpy, and the use of OSS to achieve that art.
Having said that, many of us are also interested in the underlying math, the algorithms, and the implementations that form the basis of OS processors. So it seems natural to me to carve out a space for those discussions, out of sight of forum members who are not interested.
Is adding a category a big burden on the moderators? I’d be glad to moderate that category if that would reduce the workload.
The Welcome page of the forum states at its mission statement " To provide tutorials, workflows and a showcase for high-quality photography and cinematography using Free/Open Source Software."
This discussion, (where much of it lies above my own non-technical/non-math incompetency level, but which I anyhow as a user find interesting as there is a lot to be learned from it), I most importantly think forms a basis for future tutorials as it obviously clarify matters of importance for processing methods that many have been wondering about.
Scrolling the thread it’s not immediately apparent what is “algorithms/math/code” …
The burden would be in splitting threads and/or moving them once a discussion gets “too technical”. Most start innocent enough, but end up needing a technical explaination for the why.
Here, I tried to avoid the technical details. But that wasn’t enough explanation.
And now we should move all technical discussions to a specialised place… Most discussions don’t start being technical, they become that way.
I’d say either Software or Processing should suffice as a category, no?
You can tag the topic as “algorithm” or “math” as well to provide additional context for users.
I think if it’s sufficiently tagged, then caveat emptor if they enter the topic and find it too technical.
Please keep in mind that according to the latest survey, about 40% of Darktable users have a master’s or PhD degree (which, of course, may not be in a math-intensive field).
You may not find these discussions interesting, but many participants do. I can’t speak for everyone else, but I have gained a lot from understanding the math behind some DT modules, that resulted in improved images. We all understand things differently.
Also, for this particular discussion, note that the tone mapping part of both sigmoid and filmic can be understood only high school math.
FWIW, I have no degree whatsoever and very little tertiary education, (and I know it shows!) yet I have nothing against the technical discussions. I can usually follow the discussion at least partly, and sometimes I’m intrigued enough to chase down a few rabbit holes until I understand it better.
It’s all fair play and one of the good things about this forum IMO.
What are you trying to visualise exactly? If you just want to highlight the regions of the image that are at that middle grey value you can create your own false colour LUT here: LUTCalc
