That said exactly what I considered saying, earlier. I occasionally use Sigmoid, when I’m in a hurry or the image at hand doesn’t seem to need a lot of tone mapping work. But I almost always use Filmic, because I feel much more in control of what I get.
1 Like
Ansel Adams defined the middle zone of his system as ‘dark skin; grey stone; weathered wood; middle grey’; many subjects are also around that point (‘average Caucasian skin’ and ‘clear north sky’ are just one zone above, ‘average dark foliage’ and ‘dark stone’ one zone below). Of course your subject could be a black cat, or a brightly lit white bird, but getting some reference ‘average’ object in the middle of the tonal range helps establish exactly that (‘the leaves on that tree look like this, so you can see the bird must be white’), even though your output (on the display, or on paper) will often have a have a much lower dynamic range than original the scene.
1 Like
Sure, not for the exposure module, but for filmic (or sigmoid) something has to be pinned down somewhere. This is an arbitrary constant C, in the sense that you could make it C´ and just adjust everything in the pipeline before by C/C'.
I am not arguing that it isn’t a good choice, just making a point that the choice is more or less arbitrary, in the sense that it is about picking a floating point number.
You are right, I should have been more precise. The point that I am trying to make here is that filmic rgb
- does too many things that overlap in functionality with other modules,
- leading to a lot of complexity which is hard to document in detail,
- and because of this complexity, is hard to design well.
I will elaborate below.
First, if photos were monochrome, the job of scene-to-display-referred modules would be very simple: just a function f: \mathbb{R}_{+} \to [0,1]. A convention would determine “middle gray” m such that f(m) = 0.18, and various sliders would control the shape of this function. What I am arguing here is that some control about the slope and tail behavior of this function is nice, excessive control is probably redundant. That’s what we have other fine modules for, eg the tone equalizer and to some extent color balance rgb.
But of course most photos have color, and gamut causes a problem. A lot of the development of filmic v5 and v6 centered around solving this, arguably in an unsatisfactory way, since v7 got rid of the whole idea of choosing a norm for this mapping. What I am arguing here that it is better to come up with a simpler, straightforward mapping solution for this, and if necessary, fix gamut problems in other modules, eg color balance rgb.
I view filmic as an interesting experiment that played an essential role in transitioning to scene referred. It is hard to overemphasize the importance of this, and I thank all the developers who put a lot of effort into making it better. But at the same time I think it has been superseded by sigmoid. I am very happy to see it offered as a default option now. (Just to clarify: I don’t think that sigmoid does a perfect job for all photos out of the box, quite the contrary. It’s just that it gives me a reasonable starting point and I can start correcting from there. My goal here is fast workflow and reusable presets).
I understand that experienced users want fine-grained control, it’s just that I don’t think that filmic rgb is the right place for that. Personally, I have invested a lot into learning the ways of filmic rgb (thanks again to people who made excellent tutorials, in particular @s7habo), only to find find that I can do pretty much everything in other modules when I use sigmoid. The advantage of this is of course modularity: I can save my presets and apply multiple instances of these modules.
1 Like
I think the final gamut mapping should be done in output color profile, or just before (after?) it.
The reason is that you only know what colours are in/out of gamut once you know what the output gamut is. You should not need to re-edit an image just to export an AdobeRGB image instead of sRGB, or one optimised for a specific printer.
The reason I wrote it could be done after output color profile is that if that module meerly applies a linear conversion (without clipping), out-of-gamut colours will show up as some component(s) being outside the range [0, 1]. One could then apply some compression that takes all colours inside the gamut (see sRGB gamut clipping for some examples).
2 Likes
18.45 in filmic is an arbitrary value in relation to the captured data.
It’s used to define the unchanged middle range not to be changed during tonemapping.
The user must use the exposure module to define which captured data represents this middle value.
Then in filmic you can define how to map the darkesr/brighter tones into the output colorspace.
Of course you can use tone equalizer or colorbalancergb to do the tonemapping - but then you don’t need filmicrgb. A tonemapper at the end of the scene referred pipe just ensures a well efined mappign if you don’t bother about the output color space earlier in the pipe.
So you can use it as your “green rectangle” for tonemapping but also adapt it to your demands …
1 Like
That sounds very reasonable; if you have the time please write up an issue on Github.
I feel like there have been some discussions around gamut and sorting that out. I think this also needs to tie in to the various profile settings as well. I know AP has modified it a bit in his fork to try and simplify this issue. For example now if you use the gamut indicator in DT to display gamut it uses the softproof profile and if you use the overexposure set to full gamut it uses the settings you have for your histogram profile so different gamut data for the warnings…this is okay if you know that but I think many don’t … Also having your data run through a display profile that is wedged in between working profile and the histogram profile has in the past proven an issue for some profiles. It may have been addressed at least in a limited way but in the past the only real what to show true gamut issues was to setup the profiles to all be something like linear rec2020 and so your image would look terrible on the display but then you could accurately show gamut issues…
There was this one, but it didn’t go anywhere:
I’m on holiday, and only have my phone, so I’m not in the best position to create a detailed issue.
1 Like
Middle grey IS set by the user in the exposure module though. That’s not calculated.
And since there are modules that work with the definition of ‘shadows, mids and highlights’ setting middle grey correctly before all that (so, with the exposure module) is recommended. If you set it in the filmic module (with the hidden slider for middle grey), you fix it only there and all other modules will have a different sense of what are shadows and highlights.
So, assuming your working profile is linear rec2020, whatever is middle grey in linear rec2020 they assume that to be middle grey. If it’s not , fix it with the exposure module.
3 Likes