"Scene-Referred Default" preset in Filmic RGB

I used to believe that white/black relative exposure in Filmic RGB defaulted to 4/-8EV.

Now I noticed that when I reset the module, it applies the auto-preset Scene-Referred Default.
This seems to contain “new” basic values, depending on the exposure compensation used when capturing the image.

I checked this with several RAWs from different camera models, getting implied dynamic range by adding up both defaults. All values in EV:

Exposure Compensation White relative exposure Black relative exposure “Implied” dynamic range
-5.00 8.56 -5.15 13.71
-4.00 7.76 -5.65 13.41
-3.33 7.23 -5.98 13.21
-2.67 6.68 -6.32 13.00
-2.33 6.43 -6.48 12.91
-1.33 5.63 -6.98 12.61
-1.00 5.36 -7.15 12.51
-0.67 5.09 -7.32 12.41
0.00 4.56 -7.65 12.21
1.00 3.76 -8.15 11.91

So basically, by default, 12.21EV is assumed as a starting value.

Apparently, this was already noticeable as early as July 2023, so I definitely must have missed something:

Two questions:

  • Do you know which version brought this change (if it ever used to be different)?
  • Which source or calculation is used to generate these basic values?
1 Like

I thought it was always calculated

Yes, if you use the color pickers.
And as I am told, you should manually adapt these ‘boundaries’ anyway.
So why have various standard defaults?

I suggest you ask about that over on the Ansel forums, since that’s where you’ll find the dev behind filmic: https://community.ansel.photos/

2 Likes

It’s a calculation…I would have to go to the code to check ….

1 Like

Should I really wanna mess with Aurélien?

That would be great, but don’t worry, it’s not an urgent matter.

1 Like

There are a few tidbits in the code and some comments as the different versions are updated…

White relative is called white point_source

You might be able to confirm your calculation by looking in there for clues…

EDIT
I came across this but I am not sure how to exactly translate that to the value calculated…

It looks like the default is 4 for white relative…

Then from the math above … 0.7 - (-5.0) = 5.7 x 0.8 = 4.56… add this to 4 and you get 8.56… and add 2.85 to -8 and you get -5.15 math seems to hold for the numbers that you presented so this is the adjustment made for exposure compensation it would seem… I do think in very early versions it was just 4 and -8 but that goes back a while I do think… I’m sure others have better math skills and memory than me :slight_smile:

3 Likes

You’re definitely fast. I was at the same spot when I saw you pasting it in.

What you added in the end is a brilliant summary.
The overall concept is a bit confusing, since I believed that once we dealt with EV or “stops”, the logarithmic space was kind of translated into linear values.

So currently in default, the dynamic range is adapted based on the exposure bias from the EXIF data.

Less clear:

“TODO: fetch actual exposure in module, don’t assume 1.”

Does this mean that since this remark 4 yrs ago, this is still open/to do/unfinished? So the actual change value from the exposure module is not being fed into this default value yet?
Because if it were possible, this would answer most of my questions from this other thread, which you will remember:

I cant say but I think if it was one before… then the code line underneath it is now the fix?? As I understand it grabbing the value from the data stored in the image as I think I read it… but again there are many folks here much better at reading and understand the code to help further on that one. There are often a lot of comments and useful information in code actually even if you dont’ understand the code you can often find links to articles etc so its not a bad thing to poke around in there every now and again :slight_smile:

0.7EV happens to be the default shift value automatically applied in the exposure module if you don’t change anything.
So if I interpret this correctly, the default 0.7EV was just fixed in this formula, instead of picking the actual shift value.

Anyway, I’m just a user noob, so whether this is a conceptual error or not is up to others.
But thanks to your great translation, I can paste this into my Excel spreadsheet for my own dynamic range calculation.

This is old but I actually see some updated comments in it here post 2018 referring to modern filmic…

In this article AP suggests that you set the white relative and then subtract your known DNR of the camera for the black and then you could tweak that with the DNR slider…I am not sure how many people bother to do this…

From the above linked article…

If you know beforehand the dynamic range of your camera at the current ISO (for example, from the website dxomark.com or dpreview.com ), you can set the white exposure from the color-picker measurement and then adjust the black exposure from the given dynamic range :

dynamic rangewhite exposureblack exposure(1)

Example: If you have a white exposure of 3.26 EV and your camera has a dynamic range of 14,01 EV. The black exposure should be set to -10.75 EV.

Not sure if you have seen this but its an interesting 5 or 6 part series where the author documents his DNR assessment of I think its a Nikon 5D and then proceeds to create a custom transfer function…

the whole shebang was implemented by someone who reccommended: “trust your eyes”
the initial values are just used to give a good starting point…

2 Likes

I don’t think so…given a recent statement buried in the comments to one of his recent code merges for his rewrite of the scopes in Ansel I would say … no :slight_smile:

That’s interesting. This seems to be the same text I mentioned in the earlier thread, but from a different website.

However, a “correcting” statement in the later manual makes it clear that there is no direct relationship with your “measured dynamic range” - either because these are subjective values often taken from prints and we are now using the direct values from the raw black/white point module, or because of the switch to RGB space. And of course, due to the non-parallel shift of pure black/white you explained above.

Big LOL. I admire his intelligence - and his elegant sarcasm in his Youtube explanations, mixed with ‘le accent’ - but this internal dispute jeopardises the entire Darktable project. Especially when an entire generation of central modules has been mainly conceptualised and implemented by one brilliant but now disgruntled contributor.

Nowadays it’s more written thank spoken, but if it’s elegant… I don’t know :face_with_spiral_eyes:

Ansel | Fixing the pipeline cache and 10 years-old bugs

1 Like

no it doesn’t, darktable is fine and will continue to be fine.

5 Likes

I’m glad to hear that. Should have said “I’m afraid that it could.”

I don’t understand, what are you worried about?

On a tangent I have sigmoid set as my default tone mapper, but when I have filmic expanded and not activated I notice that the relative white and black exposure values change as I move through a set of bracketed images. I am surprised and not worried by this behaviour.