I’ve been playing around with Darktable 3.0 to check out the promising new Filmic RGB module and the associated RGB workflow for a while. When I threw the attached test image at it, I discovered black artefacts within highly saturated blue areas. This happens only if “preserve chrominance” is set to “no” or “Luminance Y”. The RAW file shows no signs of clipping in the affected areas, so I suspect a numerical problem. Or maybe I’m doing something completely wrong.
The black artefacts are in the upper right part of the image. Only whitebalance (set manually) and Filmic RGB with default settings except preserve chrominance is used.
No artefacts are created when “preserve chrominance” is set to “max RGB”
What you are dealing with is a gamut clipping that is not directly related to filmic. Your dark saturated blue-purple is completely out of gamut. You need to either desaturate it or brighten it, to make it fit into the available gamut.
Thanks for your quick response. I’ll try your suggestions tomorrow.
Is there a specific reason why the out of gamut color is rendered as black instead clipping it to the closest possible color or using any other method of mapping it into the available space?
Filmic has a basic internal gamut mapping feature, that can use several strategies inspired by how film deals with colour. It will noticeably enforce a zero saturation at 0% of the norm you chose (assumed to be black). That is why, depending on the norm you chose (max RGB, luminance Y, etc.) what is assumed to be black is not exactly the same, so the desaturation doesn’t exactly behave the same.
What remains certain is you should have a very low saturation in shadows, or a bright-enough luminance in saturated areas, if you wish to stay reasonably in-gamut.
I’ve played around more and found that the black aretfacts disappear when white balance is disabled and replaced by adjusting the RGB curves. It also seems that the white balance module causes loss of tonality in the problematic dark blue area. Here are some samples:
Only white balance enabled, manually set by targetting the white wall in the background.
Replaced white balance by linear RGB curves. Adjusted R/G/B slopes by hand until the background has the same RGB value as when using the white balance. Note the improved tonality in the dark blue area.
Agree that the blue area is out of gamut. This is even the case when just loading the image with all modules disabled.
I’m wondering why the white balance module pushes the blue so much further out of gamut while the RGB curves don’t? Aren’t similar results to be expected? Why not?
If you set your white balance so that the colour gets “colder”, then you push the blues even more out of the range.
RGB curves doesn’t work the same at all. The white balance adjustment only multiplies the RGB components of all the pixels by a constant (linked to the color of the illuminant) defined for each channel. The RGB curves do a custom adjustment based on the original value of the pixel, linked to nothing meaningful (it’s user arbitrary).
The white balance adjustment only multiplies the RGB components of all the pixels by a constant (linked to the color of the illuminant) defined for each channel.
So we get a diagonal matrix for white balance which looks like this one (from wikipedia):
The diagonal elements are the scaling factors for the red, green and blue channels which I suppose to be the numbers next to the red, green and blue sliders of the white balance module.
I guess that the channel mixer is a matrix multiplication with all 9 elements settable. If I enter the factors from the WB RGB sliders into the channel mixer parameters which correspond to the diagonal elements, then the result should be the same or am I wrong here?
Example
Manual white balance targeting the white wall in the background yields factors of 1.214 / 1.000 / 1.971 and the RGB value of the white wall becomes (155,156,158).
If I enter the same factors into the channel mixer, the white wall has an RBG value of (161,168,153). Furthermore, the problematic blue area is much less oversaturated and shows more tonal nuances.
With the RBG curves I did adjust the RGB slopes (i.e. the diagonal elements of the matrix) until the white wall RGB value becomes (155,156,158). While the wall looks the same as when using the white balance, the blue area is significantly different.
From the above I conclude that the white balance calculation isn’t just a matrix multiplication but does something nonlinear.
I may be wrong, but maybe it has to do with white balance being applied BEFORE demosaic? Both white balance and RGB curves are linear, but the first is applied in camera space and the second in working space (in particular, there is a black level subtraction in the middle).
Be careful, channel mixers clip everything outside of [0 ; 100]% at the output. Indeed, it’s a 3×3 matrix multiplication. WB is exactly the same where you only set the diagonal of the matrix, and everything else is 0.
Do you know why WB is applied before black level subtraction? Does this make sense from a physical perspective? I don’t think so because the scaling will also shift the black point.
The 2N3055 is a silicon NPN power transistor intended for general purpose applications. It was introduced in the early 1960s by RCA using a hometaxial power transistor process, transitioned to an epitaxial base in the mid-1970s. It is a transistor type of enduring popularity.
(Wikipedia)
![eft[{egin{array}{c}RGBnd{array}}ight]=eft[{egin{array}{ccc}255/R'{w}&0&00&255/G'{w}&00&0&255/B'_{w}nd{array}}ight]eft[{egin{array}{c}R'G'B'nd{array}}ight]](https://d2x313g9lpht1q.cloudfront.net/original/3X/3/c/3c77100a3f0b3320db9d2410742eeb15eeb6a9b6.svg)