[resolved] Current best color management method in Kubuntu?


(clepsydrae) #1

Hi – got a new (cheap) monitor and the colors are pretty out of whack.

I’ve toyed with displaycal and a colormunki in years past, and back then (as I understood it) the advice was to generate a profile and use it for specific apps (e.g. gimp) rather than worry about system-wide profiles for whatever reasons (complicated? buggy?).

I’m now on Kubuntu 18.10 with multiple monitors (but only really care about the new one) driven by an Nvidia GTX 1060. I see this which implies that system-wide isn’t too painful nowadays on Kubuntu. I also see this from a couple years ago which is a lower-level approach.

Any recommendations? I don’t need much in terms of features. I just want to generate a solid profile and have it “on” for the screen without much more hassle than that. If can just go through the steps on displaycal and follow the instructions in the first link above, that sounds great, but if reality is messier, and e.g. there is still some argument for only using the profiles in specific apps, I’d like to know before I spend too much time on it. :slight_smile:

Thanks for any pointers!

(P.S. I also use Redshift, in case that complicates anything.)


#2

Sorry. Currently, color management on Linux only works well with Gnome-based desktop environments. colord-kde and dispwin always confuse profiles if you start switching around between more than 1 monitor. colord-kde and dispwin (Displaycal) work perfect with 1 screen. Displaycal is a great calibration an profiling tool. configuring colord on the command line appears to be rather complicated.
So use Cinnamon, Gnome or Budgie if you want it simple and fool proof.
Edit: another safe way with Kubuntu is profiling only with Displaycal and setting that profile “manually” in the apps that you use. But then you can only use those apps with the same monitor. (But I think thais was already suggested.) In this case, you must not use software calibration.


(Mica) #3

I haven’t had these problems with KDE so I disagree that you can only use GTK3 desktops. I’m doing fine with KDE on one machine and i3wm on another.


(clepsydrae) #4

Thanks all – @paperdigits: are you using KDE on multiple monitors?

And does anyone have any thoughts on the first link I posted in terms of KDE configuration? E.g. @betazoid it sounds like maybe they are describing a different setup than you described? Maybe I’ll give it a try and see what happens.

I also am not afraid of CLI configuration and running some scripts on login and the like, if necessary, and if it makes things reliable. I won’t be switching DE so I need to make this work in KDE best I can. :slight_smile:

Thanks,
-c


(Mica) #5

Currently this is only on my laptop monitor. I can try and plug in a second display and check it out, but I’m not sure when I’ll have time to do that.

On my Debian/i3 box, I’m using xcalib to load the ICC profiles. So I guess you could go that route if need be.


(clepsydrae) #6

Thanks – I’m going to try out the first link I posted and see where it gets me. Will report back!


(Morgan Hardwood) #7

How does colord handle loading calibration curves into the video card gamma table when using more than one monitor?


(clepsydrae) #8

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?


(clepsydrae) #9

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…


(Mica) #10

You have to disable redshift while you edit, as it changes your screens look. You’ll never get good color with it running.


(clepsydrae) #11

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. :slight_smile:


#12

Thanks for posting this here. Good to know. I hope you will have a chance to let the redshift devs know about the malfunction


(clepsydrae) #13

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:



(clepsydrae) #14

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.


(clepsydrae) #15

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.)


#16

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.


#17

wt* is redshift?


#18

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.


(clepsydrae) #19

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.)


#20

Could you just delete Redshift?