Color management in GNOME 3.8

I’ve spent a few hours each day for the last couple of weeks writing code to support the new mockups done by Allan for display calibration. This involved two pretty big patches, one for a reworked color panel in the control center, and one for the colord-session native calibration I blogged about a few weeks ago.

I’m glad to say this landed upstream yesterday after review by Bastien, and now people are trying it out and finding niggles which I’ve been busily fixing.

There are lots of nice features which required adding quite a few new properties to colord, the daemon which makes all this UI possible. colord now knows (from the kernel) if a device is internal, and can’t be removed. This allows us to make a few of the translations much better. We’ve also got the ability to “turn off” color management for a device, which is persistent between reboots. We can also remove profiles automatically added by colord (using metadata information) which is also stored in a database.

To test this, you currently need colord, gnome-settings-daemon and gnome-control-center from git master, although we’ll be doing some tarball releases in the next few days.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

4 thoughts on “Color management in GNOME 3.8”

  1. Hi,

    I’m using (gtk-)redshift which adjust screen temperature to the local time of day.

    Does it still make sense to have colour correction with something like this in place? Is it something the CMS needs to take into account?

    1. No, services like redshift are completely incompatible with color management generally. The calibration state is changed by redshift, which instantly makes the profile worse than useless.

      1. If he works in a glass office that has automatically adjusting neutral density filters to maintain a constant <200 lux illuminance indoors… it might work. He'd definitely have to disable redshift before he does a calibration & profile, or he's in big trouble.

        I'm thinking of all sorts of weird things now. Would this work if he worked inside a slowly revolving kaleidoscope? How would we measure this?

    2. The concept of redshift is valid, just like car radios that alter volume automatically based on car speed. It seems to just work, you don’t notice it. However, the real problem isn’t as much the slowly changing color temperature of ambient, but the quantity of light coming in through that office window.

      Graphic designers do this all the time. They always want to be near windows. Creativity and all that. I’m convinced 70% of all design and marketing ideas are delivered by carrier pigeon, and that’s why these types demand to have windows. Because it’s absolutely disqualifying for accurate color. Videographers, print and prepress people, work in subdued environments, with low ambient light less than 100 lux, maybe as little as 16 lux, neutral walls, ceiling, floors, and no windows.

Comments are closed.