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.
1 Like
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.
1 Like
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
1 Like
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.
1 Like
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.
2 Likes
Again x2
More info about macOS monitor profile issues here:
1 Like
Hi there.
I have been posting on another forum of dt.
And i interestingly run into this:
https://darktable.fr/forum/showthread.php?tid=2366
Resuming the thread:
To me it seems that dt DOES distinguish between sRGB and RGB. I did a test with this image:
If you see a smiling face, you monitor is RGB or close, if you don’t it’s sRGB.
Now, within dt, I imported this image; when switching between color display profiles I do see the difference. Even when I export the RGB image into a JPG sRGB it makes sense, as the output is without the smiling face (just a red square).
Now, if all that things on API and Cairo and sRGB and the like was correct (and I certainly don’t have the tools to disprove that at all…), then why would I see the difference between the same image with the 2 profiles?
Hi,
This might be true, but not as stated. I suppose what you meant is that “if you see a smiling face and you have the color profile for your monitor properly set, then your monitor is AdobeRGB or close” (saying “RGB” means nothing, as several people already wrote).
But the italics part in the above is crucial. My monitor (properly calibrated and profiled) is farily close to sRGB in terms of coverage. And indeed, I can see no smiley if I use the proper color profile. But I can easily see the smiley if I just turn off the color profile, or if I set an incorrect one. Here’s what happens if I set “ACES” as a screen profile (in RT, but in darktable it would be the same):
I hope the above gives a hint about (one of) the possible explanations…
1 Like
Matteo,
I opened the Roug255 image in rawproc, with my calibrated display profile in place, and got a red square, no face. The icc profile embedded in the image file was titled “Adobe RGB (compatible)”. To make it clear, the color transform to display was from the embedded profile to the display profile, no working profile in between. And, my display is a cheap 8-bit LCD, close to the sRGB gamut.
So, suspecting rendering intents, I tried both relative and absolute colorimetric, no change.
Then, began to suspect a mis-assigned profile, so I assigned a sRGB profile to the image data, which per @Elle’s semantics doesn’t change the image data. Voila, a face.
So, I’d contend that the embedded profile in Roug255.jpg does not represent the actual color gamut of the Roug255.jpg image data. It is sRGB-gamut data, and needs a corresponding embedded profile to properly represent it in a color-managed workflow. Here’s Roug255-sRGB.jpg, same image data, which contains a sRGB profile, one of @Elle’s:
I’d venture to assert here that Darktable is converting the image data to sRGB for the output, but that conversion is invalid because the input color profile doesn’t properly represent the data.
All this image tells me is that, given invalid input, color management is confused…
1 Like
Wow.
Color management is a real puzzle, indeed.
I sent via whataspp the same link to a friend with an iPhone, and with that device he can see the face.
Me myself have an iPhone too, and I DO NOT see the face.
At this point I think I can give up.
I still don’t understand why, then, darktable shows differences between sRGB and AdobeRGB. It should all be displayed as sRGB, from all the above.
Very much.
I should probably apologize for maybe coming off a little rude, I forgot how not clear this stuff can be. But, it is really pretty simple once you can see what’s going on. You’re clearly trying to do that.
The single most essential thing I’ve come to realize about color management is that the profile represents the gamut of the data to which it is assigned. If you lose that association, all becomes very confusing. So, it generally goes like this:
-
The raw image from the camera needs a profile that accurately describes it’s gamut. Most of the raw developers seem to have a bunch of camera-specific profiles for that purpose, so, for example, when a Nikon D7000 NEF is opened, that profile is found and assigned to the data. Why the camera manufacturers don’t put that in their raw files to begin with is a bit beyond me, except to consider the possible variation between individual cameras, in which case it is good to make your own calibrated camera profile.
-
Cameras generally can “see” colors we can’t, so their profiles don’t make for good editing. So, most processing software converts the data to a working profile that has a gamut confined to the visible colors. AdobeRGB is a common one; I currently use a Rec2020 profile. It seems a lot of raw processors just pick that for you.
-
All along the way in editing, you’ve got to see your image, but the working color space doesn’t represent your display’s particular gamut. So, the working image is converted to the display profile before it is displayed. I think this is where you’re getting hung up, in that displaying “RGB” (which I think you mean as AdobeRGB) or sRGB is not accurately displaying the image colors, it has to be converted to the display profile’s gamut to do that. That sRGB is close to a lot of displays (and AdobeRGB seems to be close to some of the newer wide-gamut displays), confuses things. At work, I have three “sRGB-approximate” displays, and they vary widely in both tone and color, so you really need to be displaying with a calibrated profile for that particular display.
-
Depending on where/how the image will be viewed, sometimes it is prudent to convert it to an output colorspace. sRGB is good for JPEGs to be viewed on monitors, as most who don’t use color management will just be looking at the raw pixels without benefit of the attached profile, so the pixels better be close to the display’s gamut.
So, the important part of all that is the profile associated with an image needs to properly represent its gamut, or the mechanisms of color management will just mess things up.
A second important thing is to recognize the difference between “assign” and “convert” with respect to profiles and the associated images. “assign” is to just put a profile with some image data. That’s what happens up front with the camera profile. After that, most colorspace work is “convert”, that is, convert the image data from the attached colorspace to a new one AND attach the new one to the data. That way, the data holds on to a profile that accurately represents its gamut. The Roug255.jpg image clearly doesn’t contain a profile that represents it’s gamut, and that just confuses things.
The above is a synopsis of the general flow of color management; different tools have different interfaces for this, but the concept is the same.
So, the key thing here is darktable should be displaying with the display profile, and the working image should have been converted to (not assigned) it’s working profile. Then, the image should look the same.
Addendum: I need to credit @Elle Stone for my understanding of all this head-hurt called color management. Her articles at https://ninedegreesbelow.com/ have been essential to my learning journey. Also, any errors above are mine, not hers… 
3 Likes
Hmm, I didn’t mean to reply just to @ggbutcher. I meant to reply to the thread. Sigh.
Hmm, no, if I understand how the Roug255 test image is supposed to work, the correct profile to assign is AdobeRGB. This assignment drives all but the smiley face outside the sRGB color gamut.
But the test isn’t very good because many of us have monitors with profiles that show “more than sRGB” but still “less than all of AdobeRGB”. So the test fails if the monitor profile shows more intense reds than sRGB’s reddest red, even if the monitor doesn’t show all of the AdobeRGB color gamut, or even all of sRGB. For example, my own monitor shows a swath of red, yellow, green, cyan, blue-green that exceeds sRGB, but sRGB exceeds my monitor’s profile in violet-blues and magentas.
Try this: open the Roug255 test image with GIMP or other color-managed editing application that allows you to change monitor profile without restarting the application. On Mac, I don’t know if there is any such application. But on Linux or Windows, you can use GIMP. On Mac, GIMP is a GTK app, so don’t try the experiment using GIMP on Mac. Make sure AdobeRGB1998 is assigned to the image, and make sure “use system monitor profile” is unchecked.
Now instead of your regular monitor profile, select sRGB as your monitor profile (of course this is wrong for most people with properly calibrated and profiled monitors). The Roug255 image will look solid red because you just told your editing application that “sRGB red” is the reddest red your monitor can display.
Now select AdobeRGB1998 as the monitor profile, and the smiley face will appear because you just told your editing application that your monitor’s color gamut is exactly equal to the AdobeRGB1998 color gamut.
Now select your regular monitor profile. If you can still see the smiley face, then your monitor’s reddest red is more intense than sRGB’s reddest red.
Hmm, well, in a V4 CMM, which is what dt/RT/PF/GIMP/Krita/etc use, if you ask for absolute colorimetric intent, if the destination profile is a display class profile, what you actually get is relative colorimetric. This is because today all our commonly-used RGB ICC matrix working space profiles (sRGB, AdobeRGB, ProPhotoRGB, etc) are in fact “display class” ICC profiles. If you use exiftool to look at the ICC profile, all these profiles have the following line:
Profile Class : Display Device Profile
In V2 CMMs, you can use absolute colorimetric intent with display class profiles, but this only makes a difference if the two profiles have different white points. AdobeRGB1998 and sRGB both have the same D65 white point. See https://ninedegreesbelow.com/photography/srgb-profile-comparison.html#whitepoint
for an example of what happened in V2 CMMs when making a conversion between two RGB matrix profiles with different white points.
Apparently the ICC changed this behavior for V4 specs because they didn’t want to confuse people who didn’t understand color management. So are we all less confused now? Before some of us were confused when white turned yellow or blue. And now some of us are confused to find out that absolute colorimetric doesn’t do anything different than relative colorimetric, except when it does (try with a printer profile).
Assigning any profile to an image doesn’t change the image RGB channel data, which is what I think you mean. But it does change the interpretation (corresponding location in XYZ space) of the image channel data, meaning (in the case of matrix RGB profiles) it changes the matrix that is used to convert from RGB to XYZ. sRGB isn’t any different from any other RGB color space in this regard.
@Matteo_Bertolino - if you use exiftool to look at any RGB matrix working space profile, you’ll also see a line that says this:
Color Space Data : RGB
So saying “RGB profile” is entirely undefined. You really must specify which particular RGB profile you mean.
What model Eizo are you using? If your Eizo is only supposed to cover roughly 100% of AdobeRGB, then the profile you attached isn’t likely to be the right profile for your monitor.
As you have a color measuring device, if it’s supported by ArgyllCMS (Operation of particular instruments), maybe you could try actually profiling your Eizo monitor yourself using ArgyllCMS.
Can you unplug the second monitor entirely? Color management is difficult enough without adding in the complications of dealing with multiple monitors.
Also, I don’t have any clue what you mean by “it has its own color profile embedded” - embedded in what? Are you talking about an “EDID” profile pulled from the monitor?
As far as darktable is concerned, first put your actual monitor profile where @gwgill said:
And then in darktable choose “system monitor profile”, which I’m fairly sure (if I understand what the darktable devs have been saying) that for Macs, darktable will use sRGB as a workaround to the “cairo/Mac api” problem. As an aside, this isn’t just a darktable problem. It also affects GIMP, I’m guessing also RawTherapee, and probably all GTK applications that have been ported to Mac, except maybe PhotoFlow as @Carmelo_DrRaw seems to be using a temporary workaround until the underlying problem is fixed.