Keep in mind that reflected light of the red couch might add an additional color cast on the cat. So it’s you might need two instances to correct for standard illumination and reflected light.
2 Likes
Some camera profiles are problematic. By setting input (device) profile = working profile, you exclude the camera profile from the processing (even though the camera’s primaries are not the same as those of the working profile, so you get colour distortion, it is less than that caused by the broken profile).
It can also be that by having lots of red in the illuminant (very warm light, low green and blue values from the sensor with high respective WB multipliers), combining with the high red, low green + blue reflectivity of the (red) sofa results in some very ‘unbalanced’ reflected light, and that’s causing the issue. I agree with @Donatzsky: it would be great to have this submitted as a bug report, so the developers can check in detail if there’s something to be fixed / improved.
I often find ‘ColorThink’ useful but it’s not FOSS - maybe there is an equivalent app? … but sometimes simply just saying “sRGB” is not quite enough!
For example, here is a virtual X-rite 24-patch color checker, courtesy of Norman Koren:
Here is a 2D CIELAB plot of the patch colors against two sRGB profiles:
The profiles are obviously different in a*b* space and notice that the cyan patch is out of gamut in the one profile but not the other! See also the gamut-clipping of the two yellow patches in the one but not the other.
I took a look at the first two posted cat shots.
Neither one has an embedded profile.
Still, here are the 2D CIELAB plots
It should be obvious which is which …
… and an LCh Hue shift of that much is pretty bad!
Is this because of using the perceptual intent, which involves compression?
Neither of the posted images has an embedded color profile, so I don’t know what is meant by “using the perceptual intent” because I am not familiar with dt.
I was responding to 2D CIELAB plot of the virtual X-rite 24-patch color checker patch colors against two sRGB profiles. There is an arrow at the top of the post pointing to the yours:
As for perceptual intent, I meant the rendering intent: Color management - Wikipedia
I do know what ‘rendering intent’ is. I’ll check. It may take a while to find them and report back.
But still, the gamut boundaries should be the same, no? The rendering intent only deals with gamut mapping, but the gamut itself is defined by the primaries (as I understand).
Found a difference between the two sRGBs on my hard disk, see the black point:
That would explain the difference BUT the one in ColorThink has a different name to the one on my HD, so I’m not there yet - and I’m in danger of getting jumped for mentioning a non-FOSS app too much.
You might also want to check if you have the pre or post 2015 version of this profile you are testings… as it sounds like it includes modifications to BP that may or may not be in other profiles.
Might be getting off topic here…
Thanks for the tip. Right now I struggling to extract the one from the app. so I can compare it with the ones on my HD using the Profile Inspector
… true but it does bring out my point that, for some discussions, just saying "sRGB profile"is not quite enough.
I clearly could have missed somthing but I didn’t see people talking about srgb/gamut…I think what is related to the OP topic wrt colorspaces is the fact that in DT if you remove the conversion from the camera colorspace to the working space for this DNG by setting the input profile to the same as the working profile then the image seems better behaved and so hinting that maybe the matrix/profile used by the camera is a bit strange or at least maybe not correctly interpreted or used properly in DT when the CAT is used in the CC module to WB the image. But maybe I missed something.
Phone images that produce DNG files have displayed some strange characteristics in the past as I think they often introduce custom tags or other not standard elements in the DNG and these can lead to mishandling… I think that is why as a few have mentioned a submission of that file and a report might lead to finding the source of this behaviour…
This sort of thing is what I am referring to…
1 Like
I still think you are missing the point a bit here at least as I see it…I went back up and I see where you have started to talk about color profiles and gamut etc…
This came following the discovery that setting the input profile to a wide linear space instead of using the camera matrix and one that matches the working space might have revealed a bad or at least misinterpreted camera profile by essentially bypassing that step…
All of these steps are well explained here…
There is a section on the matrices in the DNG file and it may be that these are not correctly used for some reason when CC us used to WB the image…in any case the point was not about color profiles and gamut as the cause or cure but simply a way to avoid using the embedded camera profile to see what would happen and if that could be the source of the issue… Analysing a sample image is likley the only way to source out why DT doesn’t correctly evaluate this DNG with the embedded profile of the image.
1 Like
OK. Never liked DNG anyway 
For further evaluation, is it needed that I send a sample image where I didn’t remove all the exif data?
That’s usually a good idea, as there could be something useful removed.
1 Like
Okay here is the .dng file with only the gps info removed (with exiftool).
LRM_20230228_194436_GPS-REMOVED.dng (30.6 MB)
For those checking this out, the cat should be fairly black and white and the sofa should be red. When using the CC module in rightroom and the embedded color matrix (or standard color matrix), it does not seem to be possible to get the colors to look ‘‘correct’’.
RawTherapee 5.8 + Auto Levels (no other adjustments) looks red, Win 7, NEC 242 multisync:
I don’t use dt, so only posted for comparison. The sofa is almost pure red (HSV hue 353 degrees). The white fur is showing a slight reddish cast - about 25 degrees. In the bottom two corners, the hue is about 345 degrees, tending towards magenta.
In case you are puzzled by all this talk of degrees:
The DNG was very underexposed, about -2 EV.
1 Like
Standard WB is working in DT as well I believe it’s just the Chromatic Adaptation Transform that seems to have an issue