Hi everyone!
I’m using wide gamut display and Compiz as a compositor, which has CompICC plugin that adds color management to whole desktop, so not only cms-aware apps would display correct colors.
However, darktable behaves very strangely with this setup. While mouse is over the image, colors look correct. However, as soon as I go to controls with the mouse, the colors get washed out. As soon as the mouse is off the controls, the colors are back.
darktable-cmstest version 3.0.0rc2+68~g4c7f7c163-dirty
this executable was built without colord support
darktable itself was built without colord support
primary CRTC is at CRTC 0
CRTC for screen 0 CRTC 1 has no mode or no output, skipping
CRTC for screen 0 CRTC 2 has no mode or no output, skipping
CRTC for screen 0 CRTC 3 has no mode or no output, skipping
CRTC for screen 0 CRTC 4 has no mode or no output, skipping
CRTC for screen 0 CRTC 5 has no mode or no output, skipping
DisplayPort-0
X atom: _ICC_PROFILE (6922 bytes)
description: sRGB
Your system seems to be correctly configured
I don’t fully understand how oyranos works, there’s very little info on the web. I can’t even make assumptions if the issue is on oyranos or DT side. I spent the Saturday on reading and trying to comprehend the whole thing, yet no success… I also filed bugs to both bugtrackers, however I don’t expect much from that.
Theoretically, as far as I understood, oyranos pretends that the display is sRGB for everything that is not cms-aware, yet shall let cms-aware apps to use the wider gamut (I don’t understand how). And obviously it doesn’t do this, at least not as expected. The project itself seems half-dead at the moment…
Would be grateful for any suggestions or explanations.
Seems darktable is picking up the sRGB profile, although that is probably not the profile you want. Have you calibrated your screen and told oyranos to use that profile? That is step one.
Oyranos pulls the profile from the monitor via EDID. I got question about this process, too, because there still are some knobs to rotate (WB and gamma, for instance). But the result seems to be right. Also the monitor has pretty good AdobeRGB mode, so I can theoretically pull in the standard AdobeRGB profile. But to what I can see without using a colorimeter, the native profile looks slightly better to my eyes. The ARGB calibration gives warm tint on half-lights, while native is all grey.
And yes, I’m not sure if it’s correct that sRGB profile is stored into the _ICC_PROFILE atom. Probably not. Not could I find a way to change this.
I am using displaycal and there was a time, darktable didn’t like to cooperate, as long I have used colord in dt’s build options. Ever since I switched off colord and it works (never tried to revert).
Further investigation showed that the “pale” colors were the right ones))) If mouse is over the image, it gets oversaturated due to _ICC_PROFILE atom is set to sRGB by oyranos. As a result, at the moment I can not see any reasonable way to setup color management to give advantage to cms-aware apps while not getting oversaturated desktop an other app’s output. As an ugly hack I can just switch off the color management while working with DT and put it back on afterwards. It’s the matter of check/uncheck the box in compiz setting manager.
Some additional information on the situation. That’s from CompICC Compiz plugin description:
There are some applications, which want to do own colour corrections for displaying large gamut photos, proofing or monitor calibration. Those need to tell CompICC not to colour correct a certain region of their window to do advanced colour management of their own. After updating these colour management aware applications they will work the same as before. Without updating to the X Color Management specification they see all monitors as in sRGB, which is not wrong for most of them.
That is what CompICC expects from the app to bypass forced transformation to sRGB to display wide gamut colors corectly. Does anyone knows if DT complies with X Color Management specification? The preferences do have “xorg” option in color management, so it’s probably should, which means something is probably broken. Or that setting just means it reads and uses _ICC_PROFILE atom and that’s it?
There seems very few people do know how DT’s color management works. Certainty I’m not among them…