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??
Definitely yes!
Each Raw processor no matter if is proprietary or not will deliver different output in terms of colors.
Internally darktable does not use AdobeRGB for processing. It uses a much larger color space so that no color information get lost (?camera RGB and Lab?). For the output your image will get converted? into the colorspace of choice.
Also for your displaying proper colors on your monitor some magic is on going, which I guess is the topic here. So you never lose colors because of the sRGB limit. You just do not see some colors which are out of the sRGB space on your screen.
Matteo, I want to take one more opportunity to round up some of this dialogue and put perspective on it. I’ll put my summary up-front:
One way or another darktable should be able to use your display profile, even in OSX;
The internal working profile sounds like it should be your real concern.
I just read the darktable page on color management, and between its default behavior for getting the display profile and the manual alternative you shouldn’t be having a display problem. Whatever working profile the internal image has, darktable should be able to convert it to display gamut prior to displaying.
Now, absent from the page was any reference to the internal working profile. I may not have dug (googled) deeply enough, but if AdobeRGB is the internal working profile in darktable then you’re probably getting some color loss in-display. I plotted both your display profile and AdobeRGB (danged plot tool is a bit addicting…), and the display profile clearly encompasses AdobeRGB. This is probably behind @Elle’s recommendation in one of her articles to be using Rec2020 or some other wider-gamut working profile than AdobeRGB, as displays are outstripping it’s gamut. Maybe a darktable person here could shed some light on how it handles the internal working profile.
If I understand the Lightroom situation correctly, it hard-codes AdobeRGB as the working profile, so you may not find relief over there.
All that said, we’re talking about display, not file or device output. I don’t have a high-gamut display so take this with a grain of salt, but the chromatic differences between AdobeRGB (if that is indeed the working profile) and the ezio display profile are not that great on the plot and may not be readily discernible on the screen.
Where I think you want to pay close attention to gamut translation is in your final output to media; the gamuts of files and devices are far smaller than what you’ve worked with in editing, and the translation has to be handled with care to avoid blotching-up colors on the page or screen. I recently experienced this first-hand; I thought sRGB gamut would be small enough for raw display on a projector at church, and I was horribly wrong…
Anyway, I understand your frustration, just wanted to try to focus it on the right thing…
Hmm, looking at this page, at the xy diagram at the bottom of the page, it looks like your profile for your monitor really is the right profile:
The corners of the triangles in the eizo image are probably using D65 as th white point, with xy values for the primaries not adapted to D50, so don’t exactly match what @ggbutcher 's plot shows.
I’m guessing AdobeRGB and the Eizo monitor profile are somehow only very slightly misaligned along the line between the green and blue primaries, such that only a small bit of AdobeRGB isn’t “in gamut” with respect to the Eizo monitor profile. Now how accurately that profile describes your actual display, that’s another question. If it were me, I’d use ArgyllCMS to profile the monitor, just as a “sanity check” on the profile generated by the monitor’s own software.
When you say the monitor that came with the Mac is broken, is this monitor built into the same case as the rest of the computer? There’s no way to unplug it? I have no idea how a Mac computer works, but is there any chance that the original monitor is still somehow registering with the system? Did you put your Eizo profile in the folder where @gwgill said it should go? Is your Mac picking up the Eizo profile as the system monitor profile? Or is it still trying to use a profile for the broken monitor?
I think Lightroom uses MelissaRGB as the hard-coded RGB working space (ProPhotoRGB primaries, the sRGB TRC at least for the User Interface Curves and such, though some? most? internal operations do work on linear ProProPhotoRGB).
AFAIK, darktable doesn’t have any hard-coded internal RGB working space.
The problem isn’t with darktable’s internal RGB working space.
If I understand what others have said correctly, anyone using darktable on a Mac should choose “system” as the display profile, from the darktable drop-down menu for choosing an input profile. Don’t choose any monitor profiles from disk. Don’t choose AdobeRGB from the darktable drop-down menu for choosing a display profile. Just select the provided “system display profile” on the menu under the “monitor” icon, on the Lighttable tab, down at the bottom right corner of the middle panel.
@Elle the iMac has got inside all the machine. I broke the monitor, in fact, when trying to open it up to instal a SSD
The iMac’s monitor is active, yet failing, big time. I could, I guess, unplug it by simply removing the cable. I guess…but I am afraid of further screwing things.
I have no idea if the iMac monitor is doing anything on the system as a whole.
The .icc profile is the proper folder
Finally, the “system display” profile within DT is identical to the sRGB option. While I see significant changes when switching to AdobeRGB98.
And the very same RAW file, in photoshop, gives me very different results if compared with DT, both in sRGB and AdobeRGB98.
What makes me feel like giving up with it are these passages from you guys/girls:
“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”
“What IS limited is cairo on OSX, or rather the Apple API it uses”
“There has been a problem with displaying other-than-sRGB (generally wide-gamut) images in OS X. I’m not clear on what the cause was, it could have been that the Quartz graphics layer assumed all data to be sRGB and Gtk2 had no way of telling it otherwise”
since OSX is my primary development platform, and I already had a look into the Cairo Quartz code, I volunteer to do some further investigations and try to come up with a good solution that we could propose to the Cairo developers. As it was already mentioned, I have successfully patched Cairo in such a way that it bypasses the system color management and sends the pixels values directly to screen, unchanged. The conversion to the monitor profile is then delegated to the client application.
I have investigated further and I now understand your hesitation over suggestion C. All of the following is my best guess: I have not investigated in sufficient detail to gain greater certainty.
I have no knowledge of the code of Gimp. But after a quick look, I see that Gimp calls the cairo API, and cairo calls the OS API. The problem is that cairo does not support color management. The intended behaviour of cairo is that it passes on the image data unchanged to the display.
“The surface is created using the Device RGB (or Device Gray, for A8) color space.”
Up to OS X 10.7, Device RGB was, in effect, the monitor color space. From OS X 10.8, Device RGB is sRGB. The intended behaviour of cairo has been derailed by this change. So the ‘clean’ fix for the issue with Gimp would be for cairo to be modified to restore the intended behaviour following the change in OS X.
From what @Carmelo_DrRaw and others have said, and assuming I understood the discussion (big assumption!), the current problem seems to be that the provided Apple API for retrieving the system monitor profile isn’t actually returning that profile.
Well, the problem seems to be in the “cairo quartz backend”/Mac interaction, not in cairo per se. GIMP/darktable/etc color management on Linux is just fine, and apparently is also just fine on Windows.
But it does seem sad that for years now this problem has been known, and no-one other than @Carmelo_DrRaw seems to have come up with any solution, and that solution is a not an actual solution but a workaround.
This bug report says “something” was fixed (the bug was closed as fixed) , I wonder what that “something” was, as it apparently didn’t actually fix the real problem: https://bugzilla.gnome.org/show_bug.cgi?id=681784
To me it makes not much sense to use a RAW file for testing color management accross different programs.
Just an Idea which may not make sense as well:
Use an exported JPG with AdobeRGB as profile from darktable and load it into LR and PS.
Next export a JPG from LR and open it in darktable. If the look the same in all programs then you are done .
of a RAW file (Nikon) or whatever other RAW (even Fuji)
it say that the color profile is “Display P3”?
I put the same file on a OSX laptop and it gives RGB as color profile.
I don’t understand if I’ve never noticed or if something changed suddenly. Any suggestion?
.