I begin to like darktable, so I upgraded from the Debian-provided version 3.2 to a self-compiled backport of 3.4. I enabled “modern” color processing and had a look at some of my test images. In most cases my impression is that the new colors are an improvement. That is particularly visible in a high-iso shot with rather extreme low K lighting where previously some wood colors were really off.
But in one case I noticed a strange effect of the new pipeline. I post two JPEGs as rendered by darktable 3.4 (with my kid’s faces masked). The first one is darktable’s 3.2 default processing (scene-referred), with no changes whatsoever (other than enabling hotpixel removal and automatic lens corrections). The second one is the same RAW file, but with the new modern color processing applied. The colors of the sofa portion that is seen between the heads of the kids are particularly bizarre
I read the change log of 3.4 and searched the web, but did not find anything useful. Has anyone encountered similar problems? (I would be happy to provide the RAW file if there was some way to mask the faces.)
Thanks for the reply. Tomorrow, I will try to create an example of the problem without the kids.
The problem is unrelated to filmic, it appears also with filmic disabled and already at the stage of the white balance module when white balance is set to “camera reference”. The problematic colors appear in areas that are heavily overexposed (RGB 255, 255, 255 in the OOC JPEG).
If I set white balance to “as shot” or use the color picker, and disable the color calibration module (i.e. I revert to the darktable 3.2 workflow), the problem disappears.
Perhaps darktable’s white balance reference profile for my camera (Olympus OM-D E-M5 III) is the culprit?
OK, here is a very artistic RAW file that demonstrates the problem, together with its darktable 3.4.1 xmp file. That’s just default “modern” processing. I disabled filmic to show that it’s not the culprit.
Yes, saturated highlights. When the white balance multipliers are applied, the data piled up at the top of the histogram is separated by-channel, making the hideous color. You can either apply the highlight reconstruction, or set the white point at the lowest pile.
However, when using the legacy color workflow, the highlight reconstruction module (even with default settings) manages to create a result without any obviously wrong colors (white balance set to “as shot”, color calibration disabled):
While the modern color workflow produces by default the horrible result shown above. I tried different settings of the highlight reconstruction module, but I can’t find a setting that avoids false colors.
Does this mean that the price for the more accurate modern color workflow is that it does not reliably produce acceptable results when highlights are blown in the RAW file?
P2141585.ORF.xmp (15.6 KB)
In case it won’t open (I use the master branch):
highlight reconstruction set to LCh or colour (the latter is prone to artefacts, but works fine here):
highlight recovery in filmic:
However, here there are no details (structure or colour) worth recovering on the wall, so I could just let them blur and discard the colours.
In darktable, it’s crucial not to overexpose; darktable is not good at recovering pixels blown in the raw file. Underexpose (-2/3 or -1EV is a good starting point; experiment), and the exposure module can automatically compensate for that. Noise is easier to deal with than blown highlights.
Thank you very much @kofa. Using the technique that you suggest (enabling color reconstruction in the highlight reconstruction module, and then using filmic’s highlight reconstruction to hide the resulting artifacts I arrive at better results than with the legacy workflow for the example image of my kids against a bright background.
It’s only a bit of a pity that the default result can be so horrible with the modern color workflow.
There’s no “accuracy” in the act of highlight reconstruction. It’s a contrivance that re-paints the offending color encoding of whitebalance-shifted false data into something more “pleasing”.
I just recently enabled the RT-derived highlight reconstruction function in my software, but I don’t intend to use it much. I’d rather underexpose from what the camera wants to do with middle gray to keep high-key areas within resolution and pull up the shadows, than to have to use the contrivance.
Now, in-scene light sources are still problematic, but in a lot of cases @kofa’s advice is useful - set the white point such that it pushes the offending data into white-ness. Not much to see staring into light bulbs…
Hi all,
Can I somehow get rid of the purple color on his head? I have tried different highlight reconstruction modes, reconstruction and presevre chrominance modes in filmic to no avail.
I understand now that the horrible default result is caused by the combination of
the “modern” white balance workflow,
highlight reconstruction defaulting to “clip highlights”,
and the white point in filmic rgb being effectively 5.5 EV above what the camera thought should be middle gray.
That 5.5 EV is simply not there and as such the ugly colors of the saturated sensor pixels appear. This problem was less visible with the legacy white balance workflow (before darktable 3.4) because there the highlights were clipped to white already very early in the pipeline.
Here is how I arrive at an effective white point of 5.5 EV:
The exposure module compensates the deliberate over-exposure of this image by under-exposing it 0.7 EV.
For my camera, exposure needs to be set to 1.5 EV in the exposure module, and not to the default of 0.5 EV. This amounts to a further underexposure of 1.0 EV.
filmic rgb defaulting to a white point at 3.84 EV in this case.
I created a preset that applies 1.5 EV exposure by default instead of 0.5 EV, and this already solves the problem. The suggestions of @kofa above allows to increase the white point further when necessary.
A couple of observations…I just looked at your exif data…you have a color creator setting in there that may have boosted the blue and dropped the green somewhat. Not sure if this affects only a jpg in the end or in some way the WB settings so that they don’t end up giving good values for D65 in DT. So your as shot is okay because it includes the matching big blue boost in the wb coefficient but not the color calibration that depends on good values D65…when I used the numbers in your exif and use RGB coefficients of like 2.07 1 and 1.95 roughly what your exif has for for 6600K…its better but still not a match. Maybe try to disable that setting and see if you get better results??. You also have some autoWB setting that says keep warm color off again maybe why the blue boost?? It may not be any of this but it seems like you will need to get accurate D65 numbers to be able to mimic or come close to the legacy wb.using the modern one. I know that some cameras have been identified that don’t give accurate or expected D65 values…others likely know better than me…
I just did it by opening your edit an changing that on my system…I will double check…the data are blown for sure according to the raw clipping so it might be tough to get any sharp detail which would be nice in that spot…
