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.
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.
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.
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?
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 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…
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.
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…
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.
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.
Right, but OS X doesn’t limit anything. You can tag a device colorspace with any profile you like, including large gamut ones or even the display profile itself, which turns off color management and gives you the native display response (“null transform trick”). You can have rasters in device independent colorspaces like XYZ or L*a*b*. The color management then transforms from the source colorspace to the display colorspace.
If cairo has colorspace limitations (don’t know, haven’t looked at it), then perhaps they should be removed, or perhaps cairo isn’t a good choice for color sensitive applications ??
I think I may have misunderstood the dialogue; it appeared to me that the reassignment was clouding the understanding of what was being displayed. The raw histogram clearly showed the “smile” tone (218,0,0 on a 0-255 scale) and the background (254,0,0), and replacing the Adobe profile with a sRGB one brought all the colors back into display, through the display profile. I’m still not sure what such an assignment is supposed to illustrate.
Yes, the rendering intents thinking was malaligned.
Yes, that was what I was getting at. I just happened to pick a profile of lesser gamut, and it happened to correspond with putting both reds back in gamut.
Oh, goodness, no need to apologize! I figured you knew what you were saying, just wanted to avert the possibilty that anyone might somehow conclude that sRGB was somehow special, well, it is special because it’s so often used as the “assign this profile if the actual profile is missing” profile. But that’s special by convention rather than special by intrinsic properties.
No worries; I’m acting/writing on newfound realization. I’ve been frustrated with creating profiles for a bit, until I re-read stuff last week and realized LittleCMS takes xyY primaries, not XYZ. Somehow, I’ve lost ‘reading for comprehension’ since grade school…
So, I’ve been inspecting profiles with the xyYPlot tool, and it’s been enlightening. Relevant to the thread topic, I plotted my Surface 3 and desktop dispcal-generated display profiles with one of your sRGB profiles, and got this:
I think this is why a lot of folk (including me, not so long ago) are nonchalant about color management; their images look okay to them un-managed, not realizing it’s coincidental. And, this plot only addresses chromaticity; in my rather limited experience (five displays, including three un-calibrated at work), luminance is probably the source of the greatest variance. Already thinking about a 3D full xyY plotter…
@Matteo_Bertolino, my suggestion is to make calibrated profiles for your displays, especially the high-gamut ezio; you won’t really know your colors until colors are played through them. I struggled with the sRGB “approximation” until I finally capitulated and bought a colorimeter, best money I’ve spent in photography yet.
It’s my only working monitor; the Eizo in connected via hdmi to an iMac on the floor (with broken monitor).
So the end of this story is: the ones who own a OSX system and a wide gamut display are better off using another editing software. Probably none of the open-source software would work as well as with other commercial products. Sad enough?
I really like darktable and it’s capabilities, I find it goes way beyond, for instance, Lightroom (where I come from, and where I might come back…).
Or I use darktable with AdobeRGB profile, taking advantage of its power and potential, forgetting about “a few” colours lost in the way. At least, with a calibrated monitor, the colours I see are correct, as well as luminance, white point, and other variables.
so good so far.
Then I set Perceptual as the softproof intent, hoping it would show less intense reds, but with the face visible. But no change to the display. Operator error/confusion?!
Me I tried this.
Took the very same RAW image in both Lightroom and DT.
On both software I worked with Adobe RGB98.
I exported both files with sRGB profile. Now, the outcome is very different in terms of colours.
Should it be so??
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).
