GNOME Color Manager and You

GNOME Color Manager provides a high level interface for applications to use.

One of the things GCM tries to do is making getting profile settings easy. This means associating devices with profiles. This doesn’t necessarily mean connected devices like printers and scanners, as .jpg files from my Nikon D60 have a profile, although the camera has never been connected to the computer. In fact, I’ve got several profiles for my camera, studio lighting, outside full sun and cloudy.

By dragging the .jpg or .tiff file (or even a raw file) onto the “Color Profiles” main window you can create a virtual entry that describes the device that captured the image. All the manufacturer, model and serial number data is obtained from the file metadata and a virtual device is created. This virtual device can be assigned a profile (or profiles) and this color profile can be used in photo viewing programs like eog and shotwell. This makes things magically work, as you can generate and assign the profile in GCM and it works everywhere else.

So what do you need to do as an application developer to get the chosen ICC profile for a file? First, you want to check if the file has any embedded profile (you can get the embedded profile using GTK) as this will always take precedence over a generic profile. It’s unlikely that a jpg photo from a camera will be tagged, although a jpeg file from a scanner (if you’re using a new Simple Scan) might be. Lets assume the file has no embedded profile for now.

If you call the org.gnome.ColorManager.GetProfilesForFile method on the org.gnome.ColorManager session service you’ll get an array of tuples. The first tuple entry is the profile filename, and the second is the profile description which you can add to any UI if you want, or it can be ignored. You just need to pass the method the full path of the file you want to view, and the hint. The hint is a string value used to influence what profiles get chosen, but for now just pass NULL or “”.

Of course, this method should be called async, as GCM will be looking at the file and extracting metadata which might take quite a few milliseconds if it also involves a disk seek. You probably don’t want your UI to block. If you’re already extracting the exif data for the image you’re viewing (like eog) then you can optimize the calls to GCM and only re-request profiles if the ‘Make’,  ‘Model’ or ‘CameraSerialNumber’ changes. It’s usually the case that a huge directory of photos will normally be taken from the same device, and thus need the same profile to be applied. Of course, if you are maintaining a local cache rather than just querying GCM for each image then be sure to watch the Changed() signal on org.gnome.ColorManager and drop any caches if that gets emitted.

There is a lot more information on the new wiki page, along with use cases and a ton of programmer notes. You’ll need to compile git master for the drag-drop virtual device creation and the GetProfilesForFile() method call. All this new stuff is going to be available in GNOME 2.31 too, so hopefully soon we can rock hard and stuff can just work.