Maybe something like this?
The camera seems to bump up the color a lot. I think it gives a good look in this case, specially in the out of focus pole, it looks very ‘chrome-y’.
Great shot!
P1039009.RW2.xmp (13.8 KB)
P1039009.RW2.xmp (13.8 KB)
Starting from my default settings, I’m getting near to hatsnp.
P1039009.RW2.xmp (8.0 KB)
Regarding the green tint:
With my Nikon, everything has a tint when I use color calibration set to D (daylight), which seems to be the factory default.
I’ve learnd to set it to as shot in camera and never ever touch it again.
This has always worked for me.
1 Like
Factory default of what? darktable? Because there the default behaviour should be reading the white balance from the camera (which you can also request by switching to as shot in camera, and should also be able to trigger by resetting the module). You may want to raise a bug if darktable does not behave that way. D (daylight) does not mean ‘standard daylight’ (e.g. at noon, with a cloudless sky), it’s just a type of illuminant. When you set as shot in camera (2nd screenshot), you can see that it displayed invalid (which simply means that the illuminant is not close to D - daylight or Planckian black body:
- When the CCT is followed by “(daylight)”, this means that the current illuminant is close to an ideal daylight spectrum ± 0.5 %, and the CCT figure is therefore meaningful. In this case, you are advised to use the “D (daylight)” illuminant.
- When the CCT is followed by “(black body)”, this means that the current illuminant is close to an ideal black body (Planckian) spectrum ± 0.5 %, and the CCT figure is therfore meaningful. In this case, you are advised to use the “Planckian (black body)” illuminant.
- When the CCT is followed by “(invalid)”, this means that the CCT figure is meaningless and wrong, because we are too far from either a daylight or a black body light spectrum. In this case, you are advised to use the custom illuminant. The chromatic adaptation will still perform as expected (see the note below), so the “(invalid)” tag only means that the current illuminant color is not accurately tied to the displayed CCT. This tag is nothing to be concerned about – it is merely there to tell you to stay away from the daylight and planckian illuminants because they will not behave as you might expect.
So, if by default it always comes up for you as ‘daylight’, but switching to as shot in camera fixes your colour, you should file a bug report, and attach an image that produces that effect. But before you do that, make sure you don’t have a forgotten, auto-applied preset for color calibration that forces the wrong value.
Sometimes, very rarely though, I also get weird colours; resetting the module fixes that.
2 Likes
Thanks for your remarks and correction. I did not consider that the “real” default is chromatic adaptation: legacy (I wonder why). I should have written “default of CC”. I’ve just done a little complete reset to see what the actual behavior is.
Then I get this:
With just setting chromatic adaptation: modern:
Or if CCT is followed by daylight:
(Maybe that’s why I thought it was default)
And in fact, custom equals as shot in camera for me and for my eyes, the colors are better. Looks like I remembered wrong.
Its funny though as @kofa says every so often it misfires out of the gate and resetting it is all it needs…not sure if its camera specific or what the reason is…just a misfire on the pipeline but it can happen so it never hurts to check in case it is off…
Sure, reset or reboot is often a solution. In my case I just didn’t correctly remember or misinterpreted the default settings since I’ve never used them (or rather some minutes). For me, D (daylight) is still considerably inferior to as shot in camera, albeit not automatically applied to all photos, so I will stick with my custom preset.
As Kofa said there is no daylight setting only illuminants that a considered valid daylight so a range will be called this…It should read the camera data and really present as shot by “default” and as long as your reference values for D65 are good it should be a virtual match for legacy as shot …
What is your custom preset? It really shouldn’t be needed.
I see, thanks.
So we have…
legacy as shot (fine with that)
modern default (“auto”) (not fine with that)
modern as shot (fine with that)
My preset is #3, setting CC to alway as shot.
Could you please share a raw?
Here’s my example: Another happy little doggy without crazy lightning
Here are more with other cameras:
DSC01460.ARW (23.8 MB)
IMG_1450.CR2 (24.4 MB)
These files are licensed Creative Commons, By-Attribution, Share-Alike .
I think that what happens is that darktable reads the camera white balance values, finds that they are ‘close enough’ to a D (daylight) illuminant, and switches to that to provide a simpler editor interface (with just the colour temperature). Maybe the check is too relaxed. You can switch to as shot in camera, but then you cannot edit it; alternatively, you can switch to custom, which allows you to edit the illuminant in detail.
Maybe the camera’s input matrix is wrong? Have you tried to create your own?
https://docs.darktable.org/usermanual/3.8/en/module-reference/processing-modules/color-calibration/#caveats
If that fixes the problem, I think you should share the values with the developers.
@anon41087856, what do you think? There is, indeed, a rather large shift when switching between as shot in camera and resetting to module (which causes it to switch to daylight):
Yes. I prefer adding some warmness to sunny daylight photos, so I had to look for a solution for this. I ended up using color balance rgb, and I think it does an excellent job while giving me even way more control than a simple temperature slider. I’ve never needed any other edit on WB - of course as long as the camera gets its correct WB.
No. Since I got used to the modern stuff and found my workflow as written above, I’ve never felt to need it. Also I’m experiencing this with different cameras from different manufacturers (sometimes more or less, depending on the photos), so I have not considered a camera profile problem.
I also want to say that there isn’t really a problem for me personally. I’m pretty happy with my “as shot” stuff and I think the results are great. I’ve never got that authentic colors in any commercial raw processor (I’ve propably tested them all).
The rule is:
if illuminant chromaticity has delta E < 0.005 with blackbody or daylight locus, use the correlated color temperature with the blackbody or daylight model
The delta E is computed in CIE 1960 color space - Wikipedia, which is not the greatest but is suitable for illuminants.
But there is another problem. The daylight model stops at 4000 K (daylight is not defined below), so we use the black body model below 4000 K no matter what. When you are sitting straight at the boundary between boths models, a small change in CCT can result in a switch between models and therefore in a large visual change.
You can force the use of “custom” illuminant anytime, which lets you input direct chromaticity coordinates that will not be further interpreted and don’t rely on any intermediate assumption. The “as shot in camera” option uses direct chromaticity as well.
1 Like
Thanks for the explanation. However, the problem mentioned above (with the dog pictures) is that the module does not start in as shot in camera mode; at least, it switches to Daylight for those pictures that are ‘close enough’. As you can see, sometimes that needs manual intervention (by switching back to as shot in camera or by switching to custom). Wouldn’t it make sense to stay in as shot in camera until the user manually switches to some other mode?
The point of defaulting to CCT is to allow quick and easy WB settings when possible. I think there are more cases where it works than edge cases like this one where it does not. In any case, controls are there because defaults are not expected to work all the time…
