Here’s the plot:
and, the input XYZs in exiftool output format:
RedMatrixColumn: 0.62322998 0.27453613 0.00166321
GreenMatrixColumn: 0.19964600 0.68313599 0.06350708
BlueMatrixColumn: 0.14131165 0.04232788 0.75971985
FileName: ezio
RedMatrixColumn: 0.60974121 0.31111145 0.01947021
GreenMatrixColumn: 0.20527649 0.62567139 0.06086731
BlueMatrixColumn: 0.14918518 0.06321716 0.74456787
FileName: adobeRGB
That was fun… 
Hi @ggbutcher - Nice plots!
That Eizo monitor profile seems to include all of AdobeRGB and then a fair bit more.
Hey!
Interesting indeed. But does that mean my Eizo has more gamut than Adobe RGB?? Sounds weird. It should, at best, be equal.
Now, either I find where to put my .icc color profile so that darktable can find it (anyone??), or I am better off choosing directly Adobe RGB from the given options.
Do you agree?
Thanks.
Reading here and there I found this, where the profiles should be places:
~/.config/darktable/color/in
the problem is having a Mac; I cannot find such folder with darktable icc profiles! The only darktable folders I found (thanks to this forum!) are the ones I attach.
Now, I even tried creating a new folder inside, called “color”, and another, called “in”, I places the .icc profile inside but, obviously, nothing, darktable does not see it.
Thanks.
You are on the right path and you have to create the folders if they do not exist. But the manual as link by @houz says you need to place profiles for the monitor into the folder out not in.
So it should be:
~/.config/darktable/color/out
Hi,
Not really. If I understand correctly the info given at the link above, and if darktable works like RawTherapee in this respect, then you should use “system display profile”, and tell the OS to use your icc profile (I don’t know how to do that on a mac, sorry).
You will not benefit from the wide gamut of your display unfortunately (the output will be clipped to sRGB), but at least you should see the “proper” colors (proper meaning as specified by your display profile).
I hope this is right, but I’m confident someone will correct me otherwise 
In a way, and given the above insights given by others, if darktable automatically converts everything to sRGB then any attempt of mine to install my .icc profile is useless.
If it was really so, welcome to another huge deficiency of the software. I feel.
I mean, come on, how can you not allow the software (a supposedly professional retouching program) to read a RGB profile?
This throws huge shadows on my ideas of switching from other software.
I really hope I am missing something…
Thanks.
I created the folder named “out”.
Still nothing… 
It’s a limitation of cairo on OSX and nothing darktable can fix on its own, the root cause being Apple having broken API.
Fine. Accepted.
But then, does that stick also if you have a second monitor plugged in, as in my case? I mean, it has its own color profile embedded. I don’t use at all the iMac monitor (broken).
And finally, why do I see the difference in darktable when switching from sRGB to RGB? From what I understand that difference should not be visible.
Thanks.
I’m just the messenger here, a hack programmer who figured out how to plot data he’s just beginning to understand…
That said, what you don’t see on these plots is the luminance range of the two profiles. I’ll leave it to @Elle to tell us what significance that might have.
From what I understand OSX does use the color profiles set in the system to map from the intermediate sRGB colors to your display space. So if everything works as intended you should have correct colors, even with more than one monitor, but they are restricted to the sRGB gamut.
That being said, I never had a computer running OSX, never really used OSX and surely have no idea about the things going on in the back there. So I might be totally wrong.
Again, what do you mean with RGB? Those are all RGB profiles, and none of them is labeled just “RGB”.
I actually managed to make darktable read my own .icc profile.
I created the folder and placed a copy of the profile inside.
Now, my profile is supposed to be an Adobe RGB profile, so I do not understand now the whole thing anymore, given that I see a clear difference now between my RGB profile and the sRGB.
Maybe Apple has changed?
So now I should work, I think, with my own .icc profile chosen among the different “display profile” options, then export with sRGB profile for web and similar. Am I ok?
Thanks
Ciao Alberto.
Look, I managed DT read my own .icc profile. As said, it is a AdobeRGB profile coming from Eizo calibrated wide gamut monitor.
Yet, even if my profile is AdobeRGB, it looks very different (especially on red saturation) than the AdobeRGB given by the program. Should it?
So, now I should choose my profile from the “display profile” options I guess, then export as sRGB for web and the like.
Thanks.
@Matteo_Bertolino It could be problematic if you use Eizo’s profile or your custom one and then have Cairo (or whatever it is) still clamp to sRGB space. You need to verify your colors. Just stating the obvious. The devs and color gurus probably have more to say on that.
It is very clearly not an AdobeRGB profile. Look at the plot @ggbutcher made, the profiles are different. So it’s to be expected that the colors look different.
Yes, you see a difference. That doesn’t mean that your profile used inside darktable will create correct colors on the screen though.
As I understand the situation, OSX is taking the pixel values darktable sends to the screen, interprets them as sRGB data, converts them to your system display profile and outputs the image on the monitor. If you select something else than sRGB (or the system profile) inside darktable then darktable will send colors matching that profile to OSX which will then misinterpret the values. So your only chance of getting correct colors is using sRGB inside darktable as the display profile.
Should that have changed then I would be interested to hear about it. Not sure how best to test that though. One way would be to use a known-broken profile as your system’s display profile. The specific steps would require some knowledge about color management on OSX that I don’t have.
Very interesting point indeed. Thanks a lot for your key contributions.
I hope some guru runs into this topic, I really would like to know how to
set up an optimal color workflow, given my variables and the program’s
ones.
escribió:
Let’s say I understand
Conclusion is that I cannot take advantage of my Eizo wider gamut (let’s not call it RGB then…), and be happy with sRGB, plus proper colours, correct brightness, white point, and other values deriving from proper calibration.
Sadly so.
If I had Ubuntu would be would be probably different.
Thanks
Mac displays aren’t limited to anything in particular, just like any other display isn’t limited.
In general displays are whatever they are, and the whole point of setting a system/display profile is to tell the system how the actual display behaves. With a correct profile, the system and/or application can then make allowances for that display when displaying colors, so that they are displayed as intended.
In some cases a manufacturer may try and make their display sRGB like or AdobeRGB like in its color response, or high end displays like an EIZO may have emulation modes that make it respond according to a standard colorspace such as sRGB or AdobeRGB etc. This may limit the gamut to less than the display is actually capable of.
So the aim of setting a display profile is to use one that most accurately represents the display response. Best would be a custom profile made using a measurement instrument and appropriate software. Second best would be a display manufacturer provided profile for that display. Third best would be a standard profile like sRGB/AdobeRGB if the display is set to a matching emulation mode or has a native response that resembles a standard colorspace.
On a MAC ICC profiles can be stored in a number of places, depending on what the scope is (i.e. just the user, system wide, network wide). For a user they should be in /Users/$USER/Library/ColorSync/Profiles where $USER is the user name.
That is right, and I never said otherwise. What IS limited is cairo on OSX, or rather the Apple API it uses.
This is how I understand the situation from what I was told and from looking at some code samples:
On OSX all rendering surfaces are color managed and have to be tagged with a color profile so that the system can then do its magic. So cairo tries to get the system’s display profile to tag its surface accordingly. However, contrary to what the API docs say, the profile returned is sRGB and not the actual display profile.
https://cgit.freedesktop.org/cairo/tree/src/cairo-quartz-surface.c#n2348
As I said, all of that is hearsay and what dt’s OSX maintainer puzzled together, I don’t have a Mac to test any of that. I would like to see someone to write test code that gets the display profile using CGColorSpaceCreateDeviceRGB() and figure out how to store that as an ICC profile to disk so it can be compared to sRGB and the real display profile.
PS: Please excuse me explaining things you know better than me, I just want everyone else to be able to follow, too.
