Have a look in the sony full frame forum at dpreview.com. There are a few threads about bad colour, profiles etc. E.g.
Correcting orangey or yellowish skin-tones. Best way in Lightroom?: Sony Alpha Full Frame E-mount Talk Forum: Digital Photography Review
Forum is searchable.
I don’t see a correlation between people trying to get a skintone-result they want with Lightroom, and the difference results between Darktable’s legacy or modern color workflows.
I don’t have a problem getting good skin tone. I have a problem where ‘color calibration’ modern color workflow seems to produce results quite a bit of :).
Do you have access to a colorchecker?? If so you could use it in color calibration to tweak your colors and save it as a preset…
I think when you just use the ‘legacy’ white balance, darktable reads the RGB multipliers from the exif data, which have been recorded by the camera and vary from image to image.
With the new method, a fixed set of multipliers from Adobe is used to white balance the image to the 6502 K reference value, and if those are wrong, you have problems. color calibration then reads the multipliers from the exif, but by that time, due to the wrong reference values applied in the white balance step, those won’t work well. That is why the docs say you should measure your own set of reference values, and apply those in white balance.
While you mention this, if you used the legacy WB settings for daylight shade etc…should they match what you see in the exif data. I took a look for this file and they are similar but not the same… so I guess what I was wondering if the answer is yes then what is DT reading or maybe there is a step that I just have not thought of at the moment… even the recorded WB is slightly different then what DT shows for as shot legacy…
Though now kofa has explained the workings, there may well be a correlation!
The thing is that the modern color workflow (whitebalance set to reference, colorbalance set to something) produces quite different results than just whitebalance set to something.
This can be worked around, by choosing a different ‘reference’ whitebalance, just as @kofa and others (and the manual) said.
Thing is, it’s not constant. For some pictures the reference is correct, for some it’s not.
I have a DCP profile (not from Adobe) for my camera, that according to dcp2icc is dual-illuminant, for 2850k and for 6500k.
Trying both icc’s in ‘input profile’ doesn’t yield results that are clearly better (they have the same issue I would say, but look a bit different).
what @Thomas_Do discovered (although I have to set a linear rec2020 as input space) seems to indicate that there indeed is a problem with the Sony profiles. Both the darktable included one, and the external one I have (didn’t try those from Adobe yet, they often aren’t better or are even the source of the Darktable included-one I’m guessing).
Setting the input profile to linear rec2020 makes the reference-6502k-reference white balance work fine with color calibration (although colors aren’t perfect of course, but closer than I imagined they would be).
Scanning your file in libraw would list these WB coefficients…
D65 here is quite different from what DT used… I would have to see …does this change every file??
I can imagine your frustration. I’m no expert but here are a few things you could try (if you haven’t already) -
1 Edit the post title to include the camera model, this may get further contributions
2 Your photo was at iso 6400, could this be iso related? Maybe repeat the pic at iso 100 or 200 (baby asleep, long exp!) and see how that goes. And iso 15k or whatever.
3 Repeat pic with different type of artificial light. (Daylight pics ok?)
4 Long shot, but maybe check dt is using correct raw white and black points. Could check against rawtherapee, it is driven by a file camconst.json which has these values for all cams and ISOs, see how dt compares. You could download the source and find it, or someone here could post it.
Good idea, just changed it.
Hmm, I have the feeling that the pictures that ‘go wrong’ are the ones in low light and/or tungsten lighting.
Didn’t compare them straight on with RT’s camconst, but they seem familiar, and I already tried messing a bit with them to see if something changes… but no effect.
The thing is that this ‘halts’ my workflow and my trust in using Darktable. If I don’t know if a picture requires a different color setting, I need to test it… every time.
If it turns out I just need to accept that my camera may require two different reference-white-balance points, depending on… ‘something’… then I guess I just have to use the legacy color workflow, because otherwise I would have to edit each picture twice and compare the results to see which I like.
How was the scene illuminated? Flash? Daylight? Some who-knows-what interior lighting? White balance should first be about that, then about what the light is doing to the rendered colors.
Then, what’s the pedigree of your camera profile? In spite of all the SSF stuff I do, i still start with a ColorChecker-referenced matrix profile to establish some notion of a color baseline as a point of departure.
See-sawing all the other tools before you get a handle on the above is just blind-man-elephant- feeling…
Hi,
CAT is an approximation of the real chromatic adaptation that humans can perform. In fact, different methods exist, that give different performance on different test sets. Sometimes doing the adaptation in camera space (i.e. the “legacy mode” in the terminology of dt) just works better, particularly when the two illuminants are very far apart. More info at Color conversion matrices in digital cameras: a tutorial, or Yuhao Zhu (section 5.4) for TL;DR people.
HTH (with the usual disclaimer about this not being really my area of expertise)
I think the higher iso and extreme lighting might exaggerate things in this image but even when I downloaded a colorchecker for the a7II from imaging resources at 100 200 and 3200 iso …leaving all things the same and comparing a snap shot you can see the reds and other colors are paler with the modern workflow and the modern workflow seems like it gets brighter…this sort of difference would be exaggerated in strong incandescent light…
I think the D65 coefficients come from adobe which are often cited as giving muted colors for sony…many prefer the icc files from capture one I feel like is what I have read.
If the legacy uses camera information from the exif and modern uses Adobe coefficients that could explain some of it maybe?? Really just guessing and not certain on that…
Running a7ii raw’s through libraw gives a list of coefficients…
One set in the table labelled d65 and one set at the end labelled derived d65…neither of those match what is used by darktable…again I really have no idea what that means and which ones are the correct ones to use… I suspect there can be some variability given AP’s video about finding your own by shooting your an image of your monitor…
But the issue is not ‘getting a good white balance’. The issue is 'getting the white balance ok with the modern color-calibration module '.
That’s the whole point. I get good color with using just the white balance module. But if i try to use color calibration for this file , sampling the same part in the picture yields quite different skin tones .
In this case , color-calibration module seems to only get good results if the white balance is close enough already. But what’s the point then ?
With all your disclaimers , you might just be the most right and to the point.
What i get from your message is that the CAT in color-calibration module isn’t supposed to work ok, if the starting point is too far off.
And setting the white balance module to reference (which is around daylight for my camera at least , 6502k) while the shot was made in tungsten conditions (+/- 2600k) is just too much to ask for the CAT model.
But that means that you don’t need to set your starting point to ‘reference’/daylight , you must set it to 'somewhat real correct situation ’ and then massage your colors and gamut from there with color-calibration module.
From the manual i seem to read that the white balance must be set to some camera neutral starting point to make demosaicing not produce artifacts. But it seems you also just need ‘a somewhat reasonable’ starting point .
But that means this problem or mine should be reproducible with other camera’s as well ?
Shoot a scene with low light / tungsten lighting so what the auto WB of your camera picks something around 2700k (or at least under 3000k or so ). And then do the steps i do to get this ‘problem’
It might not even be a Sony thing , but just a limitation of the color calibration module ?
I got the same list from exiftool. I haven’t checked other files to see if they change.
The thing is that for other files (yes, sunny daylight or flash shots ) color calibration seems to work fine.
So it seems the camera profile (that sits after the white balance module ) does some thing on Sony camera’s , that trips up the color calibration module if the white balance was set too far off in the white balance module .
Because using linear rec2020 as input profile , seems to make color calibration behave better.
But using another Sony a7m2 dcp profile found on the web doesn’t change things that much.
It just be that Sony camera’s have a quite strong change in the camera profile , that ‘destroys’ the input to color calibration.
(And the documentation mentions Olympus as well, who mainly uses Sony sensors … But then again, there are compact Canons with Sony sensors and Nikon DSLRs with Sony sensors where you might expect the same issue ?)
Well, that mostly means that I don’t really know why/in which conditions the CAT fails, other than the generic “when the white points are very far apart” that is reported in the article I linked. But far apart is not just about the temperature that you see reported, which is a coarse approximation at best anyway. I suspect that how far your illuminant is from a blackbody also plays a role. Anyway, I used to have a Sony alpha camera and I’ve taken many shots under indoor artificial light, and the CAT (as implemented in art, but I suppose with dt would be the same) works just fine and gives nicer results than applying wb in camera space. In general, I’d say that it works most of the time, but there are some corner cases in which it fails, and sometimes badly so. But I’m not sure what triggers that…
If you’re see-sawing white balance against color calibration, you have no idea what the baseline colors should be. White balance is the adjustment of the camera’s spectral response to accommodate the spectral power distribution of the scene’s illumination, that’s it. If color calibration doesn’t work with it in some case, mucking with white balance to fix it is like using the accelerator to open the car’s door - you might find a way to do it, but likely will total the car in the process…
Have you highlight reconstruction module on? I had one image with a similar issue, and the reason was D65 coefficients pushed one channel over one and then the highlight reconstruct clipped that.
No highlight reconstruction was off , to get a very simple clear pipeline.
But next to the skin tone shift , it seems the whole picture is brighter. Maybe I am clipping a single channel somewhere that makes the colors look weird, haven’t looked at that.
