How does colord handle loading calibration curves into the video card gamma table when using more than one monitor?
So: the link I posted is for KDE, but not for Kubuntu, which does not have packages for either oyranos or kolor-manager (starngely?).
I calibrated with Displaycal and saved the profile. It “installed for current user” and although the preview on that dialog works via displaycal, but it does not install properly.
If I use dispwin to set the profile, it holds for a variable amount of time, from ~.5 seconds to 2 seconds. It seems like there is some automated process in the background that is overriding the settings. Any ideas on that?
Using colormgr I can see that the default profile for the device is as desired. I also tried installing the colord-kde package which lets me choose the profile for a monitor, but the same thing seems to happen: the profile is chosen but it only holds for a short time and then reverts.
There are several other oddities which I will spare you, but: does anyone know what other part of the system might be interfering with these attempts?
Aha! It was redshift that was reverting the colors. When I disable it, the correct profile holds. Looking good now… might enable for the other monitors as well… so far so good…
You have to disable redshift while you edit, as it changes your screens look. You’ll never get good color with it running.
Yes of course , thanks. The issue was that even when redshift was doing nothing (middle of the day, no color correcting happening) it wouldn’t allow the color profile to be changed.
Also, even if redshift has been enabled and then disabled, I have to open up system settings and go to each monitor and set the color profile to the default and then back to the corrected profile again, because when redshift is disabled it reverts to the default, but this is not properly indicated in the system settings GUI.
No big deal, but good to be aware of. And confusing when I was trying to figure out what was up.
I now have all three monitors calibrated and it all seems to be working fine. Time will tell. 
1 Like
Thanks for posting this here. Good to know. I hope you will have a chance to let the redshift devs know about the malfunction
Looks like they know about it, and there may be a parameter that enables them to play nice together, but I got a little confused reading through the bug about all the details:
Ah, even better: in the redshift GUI, go to advanced options, change the mode from “auto” to “randr” and enable “Preserve screen colour”. Seems to all work happily together now.
1 Like
Well, spoke too soon, there are still bugs when enabling/disabling redshift, but it’s close enough to work with. I have a shortcut assigned to a custom script that runs dispwin to set the profiles on all three monitors so I can always disabled redshift, hit that key, and know that i’m back to a sane place.
(It seems like when redshift is disabled, it doesn’t return to the normal profile, it just stays where it was, so the next time redshift is enabled it gets a bit redder from there. Repeated enabling/disabling makes the screen redder and redder.)
I have no idea. Not using software calibration currently but could try with my laptop screen eventually. My guess is though that it works properly.
btw, sorry, I was busy and could not answer sooner.
wt* is redshift?
anyway, I tried color management with kde many times with different distros. it did not work properly. eventually the system confuses or forgets the correct profiles. is is hard to say when though. Check with darktable-cmstest after some days/reboots and switches between the screens.
I read something about the nvidia drivers, free and proprietary, supporting gamma curves now, but I might have that totally wrong and I also have no idea about what’s going on under the hood.
Redshift is akin to f.lux: color temp adjustment to match the day, based on research showing that our sleep patterns are affected by sepctra.
Re: KDE/Kubuntu – yeah, it’s not seamless so far. Found another bug: on startup I need to run my “force set” script, presumably because redshift interferes initially. I think without redshift running everything would be working fine. I’m actually really impressed how simple it was to get going on KDE/Kubuntu. There was little/no documentation about how to do it, but in the end it was remarkably smooth (install colord-kde, install argyll, install displaycal, calibrate, click “install profile”, use system settings to confirm that the profiles are the default.)
1 Like
Could you just delete Redshift?
Sure, or I can just disable it when I need to. But I use it when I’m not photo/video editing so I’d like to get everything to work together to the best degree I can.
They can’t work together since they both simply grab the hardware and use it or their own purposes. (To be able to coordinate their activity would mean having some formalized notion of what these utilities are attempting to do, and such formalization restricts the sort of open innovation that allowed them to be created in the first place. If something like Wayland could formalize a well thought out color management extension, then maybe this could be resolved.)
Note that I’m informed that recent X11 releases may make this even more confusing by combining all the different mechanisms for setting up the X11 CRTC VideoLUTs, rather than having the last one take precedence. You won’t ever quite know what is messing things up, nor how to set it to a known state 
1 Like
Is there any update for Wayland Color Management? I hope it is able to be resolved to a working solution. (Maybe more hope than X11?)
Hi @alexmitchellmus and welcome! Currently the spec for Wayland color management is being fleshed out, so there is no solution in place currently.
Not “the” spec, “a” spec - one of many. None of them get close to ticking all my boxes, and I wouldn’t get your hopes up…
X11 color management works now. Wayland - maybe sometime or maybe never.