Strange presets behavior of Darktable white balance module

Software darktable
1

I’m getting the following strange presets behavior with Darktable white balance module.

If a workflow is selected in the processing tab (for example “scene-referred Agx”), the white balance module activates with the rightmost option selected, i. e. “set white balance to as shot and later correct …”, and everything works fine.

But if a workflow is not selected in the processing tab (i. e. “none”), the white balance module activates with the leftmost option selected, i. e. “set white balance to as shot”, that generates a conflict with the color calibration module.

I try to fix it by creating a custom preset with the rightmost option selected, but it applies as “set white balance to user modified” if a raw from a second camera is loaded.

Why this does not occur when a workflow is enabled?

2

Basically I think @kofa is looking at a tweak to the wb processing in Dt…If you use the right most option (the default for the scene workflows) you need to let the camera use as shot wb…no other setting. In DT if you make a preset then you have a fixed value from that preset that will not be autowb in the next image and its going to trigger a warning… At least I believe this is what you are seeing…

1 Like
3

At @priort correctly said, if you create a preset for the white balance module, you’ll save the white balance multipliers, not the mode. Hence, you end up with user modified.

If you select ‘none’ for the workflow, then darktable does not turn on the scene-referred flow, and you have to set your white balance / color calibration modules manually. You told darktable to back off, and it did. Maybe it’s not the best choice from the developer side (coupling the tone mapping strategy with the chromatic adaptation strategy), but that’s what we have (it used to be 2 different options).

If you want the ‘modern’ chromatic adaptation method, but not enable a tone mapper automatically: pick any of the scene-referred workflows instead of none (e.g. sigmoid), and then create a preset for the corresponding module (sigmoid) where the module is disabled, and set it to be applied automatically.

2 Likes
4

My only point to select the “none” workflow is to auto-load a different preset for color calibration.
Specifically, instead of daylight illuminant, I’d like to have “as shot in camera”.

But I understand now that the activation of a scene-referred workflow initialize the processing pipeline in a way that is not possible to do with user presets.

5

I also use such a preset, but with scene-referred workflow. That works fine.

Nope, that’s not true.

1 Like
6

Do you mean I can override the scene-referred default preset with my custom preset?

I mean that with a user preset is not possible to set up the mode of the white balance module. We need to do that with the workflow. Did I get it right?

7

Yes.

Yes. The scene-referred workflow will set the white balance module to as-shot to reference mode, which is correct, and your own auto-applied preset can set color calibration to as shot.

1 Like
8

Thanks a lot :+1:

1 Like
9

In the manual and in Aurelien’s thread where he introduced colour calibration, it says that the white balance should be set to “camera reference.” However, I just noticed that also in my darktable installation (5.0.1 with scene-referred filmic) it says “as shot plus camera reference”.

What is the difference between was is written in the instructions and what is actually set in darktable by default?

10

This is an updated version where by the as-shot WB gets used for some early steps that are better suited to use that and then later in the pipe the transition to performing the CAT using reference values…

11

as-shot to reference is newer and better. I can provide technical details, if needed.

12

I see. Thanks for the link!

1 Like
13

There is no mention of this I don’t think in the current manual. There is not too much info provided in the WB section for any of the modes just a sentence or two… I think we could update for now. I’m not sure of the best wording that is accurate but given your comments you might be able to distill it so it could at least be added for now to inform people about this option…If I have time tonight I will see if I can wordsmith something

1 Like
14

I thought I was going mad trying to correct this. The solution currently is very confusing. So I’ll battle on whilst those who know what they are doing correct this odd behaviour

15

What exactly were you battling?

16

I don’t agree. If you select “workflow=none” you get that: no workflow, so the minimum needed to show an image. That means something has to be selected for the white balance, “As shot” seems a reasonable default in this case.

And honestly, you don’t always need all that fancy stuff. Some images can give good results with just the minimum stack of modules (8) plus tone equaliser (ok, that one is rather fancy)…
(Low contrast image correctly exposed for all the important areas, of course).

All those fancy tone mappers are designed to reduce the camera dynamic range to a screen or paper dynamic range. If your scene is purely diffuse reflective, you are already in about that dynamic range…

17

@aequalis and anyone new-ish to DT, here is some background on workflow and “As shot to reference”.

Several years ago a developer Aurelien Pierre introduced “scene referred” processing to DT. This is where RGB values represent the light energy from the scene in a linear way, i.e. twice the light energy means twice the RGB number. He built the Filmic module and some other important modules and processes. The workflow was designed to work with a D65 white point. I won’t explain that too much, because I can’t! However the 65 is short for 6502 degrees, this being the colour temperature of mid-summer sunlight in a clear sky IIRC. As a result, “Camera Reference” became an important setting in the white balance module because it sets DT up for the D65 whitepoint, using the camera model in the Raw file to make an early conversion of the image data into D65 for subsequent processing. If you chose the scene referred workflow in settings, the white balance was automatically set to Camera Reference and you used the colour calibration module to “fine tune” the image.

This worked VERY well and many people were very happy with the results obtained (and still are). Later it was discovered that sometimes (and pretty infrequently IIRC), slightly better results were obtained from some of the modules if they were fed with image data that was accurately colour balanced, rather than set at D65. Hence a better process was possible: use an accurate balance for some modules (towards the early part of the pipeline) but revert to D65 for other modules (which are later in the pipeline).

This was implemented in a strange way. A new white balance option was added, As shot to reference. The camera’s white balance is used early on, and D65 later. If the camera WB is good, you get the best processing of your image. If you didn’t set the WB when you took the shot, or the camera auto WB isn’t good, then the early processing is sub-optimal.

If you accurately balance the image yourself in the white balance module, the early processing is good but the later modules are sub-optimal (because they are not getting D65 data. Historically the white balance initially set was used all the way through pretty much)

So what could have been implemented is: regardless of white balance choice, use the white balance early on and D65 later. Win-win.
What was implemented: a new unnecessary option (As shot to reference); failure to benefit fully from the potential improvement; two “As shot” choices, surely a bit confusing.

I think Kofa has raised an issue in Github aiming to improve the situation.

Am I bitter? No (Yes) No!

5 Likes
18

This kind background information is very useful at least to me.
Thank you.

19

You will get good context if you review the link I shared above from inception to adoption…

20

I do not see any link in your last post.

Never mind I see it now. was looking at a wrong post.

1 Like