Year: 2009

I’ve been hacking at gnome-color-manager for a few weeks now. We had a first release last week, and we’ve since been adding in more new features and a couple of nice bugfixes. But that’s not what this blog post is all about.

To calibrate a device, you need to scan in (or take a photograph of) a very accurately printed image. These printed images are called “targets” and usually come with a CD-ROM of the calibration data for that batch, or a URL of where to get the calibration data from.

Now, the number of people wanting to use a calibration target is going to increase in the future, as they’ll want to have a color-calibrated workflow whilst using Linux. These random CD-ROMs that get lost and URLs that might vanish don’t seem so easy to use when you’re calibrating 200 workstations, maybe using a different type of target for scanner, camera and film. And re-calibrating them all two years later doesn’t look like fun either.

So, ideally, we would ask the manufacturers of the calibration data (just big text files of numbers), and we could ship it in a shared package, that the distros can ship. Unfortunately, a lot of the targets in existence have NDA or horrible licensing terms shipped with them. This makes distros like Fedora that can only ship free software and content sad.

Enter Wolf Faust. He’s the bloke that’s been shipping high quality IT8 targets all over the world for the last few years. He’ll ship you just a single target (there is no minimum order), so it’s enthusiast friendly. The pricing is cheap (25 Euro) and postage and packaging is reasonable (5 Euro), which makes him the obvious choice for someone that just needs a target or two to calibrate their photographic or graphics workflow.

Wolf Faust has just released his entire set of calibration data under a free license. This means we can ship it in a distro package, so that calibrating a scanner is as simple as borrowing a target from a friend and taking a photo of it and then selecting a target name from a GUI drop-down. No need to fumble about with CDROMs or downloading the correct target from a website, now it just works.

Now, I guess Wolf has realized by making the calibration data “free” content, he’ll sell more targets; and I hope he does. If you make it easier for people to use your product more people will buy it for sure. It makes no sense keeping this data secret and wrapped up in legalese. It might not be much, but this for me is an advance of freedom, as much as just-another-package in a repository.

Note, gnome-color-manager will install shared-color-targets automatically using PackageKit if you try to calibrate a device and it’s not already installed. We’ll do the first official release of shared-color-targets just after Christmas.

A few days ago I created the shared-color-profiles project. This contains redistributable ICC profiles from different vendors (some free, some non-free). The configure script allows a distro to install just the profile types that are acceptable. In Fedora, that boils down to the profiles in public domain, but we’re hoping to add CC-BY-SA and CC-BY-ND manufacturer submitted profiles really soon. At the moment I’ve added Adobe, Argyll, ECI, ICC and IDEAlliance profiles. A few people are interested in creating profiles for common cameras models, although this would probably be a community supported effort rather than a vendor-supported effort. Anyway, doing this allows us to define proper color working spaces and default spaces to use in applications.

Anyway, if you know of any vendors or standard bodies that have released profiles that allow distribution as part of a combined package, or as CC-BY-foo or public domain then please let me know as a comment on this blog. Thanks.

Next Monday I intend to release the first supported version of gnome-color-manager (2.29.1) into the wild.

There have been quite a few new features added to git master recently, and very many bugs squashed. I wanted to thank Pascal de Bruijn for the hours and hours of regression testing he’s been doing, and quite a few other people on the mailing list that have also been reporting bugs before the release. There are quite a few translations already committed, so the first release should look really good.

New features added in the last couple of weeks:

• Ability to support and manage “disconnected” devices
• Cairo CIE widget showing gamut ranges
• Ability to delete and import existing profiles
• Adding of the rendering intent settings to the DBus interface for applications to use

More testing is always welcome. Thanks!

And so, long story short, we decided to revert the change for F12.

Part of being an open source maintainer (and also my job at Red Hat) is to ignore trolls, but some of the messages I was getting yesterday were just personal attacks and abuse. That’s not cricket at all.

GNOME Color Manager now a mailing list – It’s for discussion about colour management in GNOME, and that sort of thing.

Late last night, after a few hours of intense refactoring (to allow udev based devices, as well as xrandr based devices) we got the initial scanner support working:

This lets us support printers and digital cameras pretty easily too. At the moment we just need to figure out how to make gnome-scan make a scan for us and save it in tiff format, and then we can get the calibration working for all types of scanners. Of course, you need a precision printed reference image, but you can get these pretty cheaply from Wolf Faust.

Then, we need to work with the gnome-scan guys to agree an interface so that gnome-scan knows what profile to use for each device. Either a library or DBus interface (with calls in either direction) are being considered, although I think the session-activated dbus interface is probably going to win. There’s still quite a bit of integration work to make CUPS ICC profile aware, but that’s on the list after scanners are working. After all, you need a calibrated scanner to calibrate the printer. Help is always welcome, so please checkout the code and help find bugs.

GNOME Color Manager now has a website. The mailing list will be set up soon, which means we can start building a community.

I’ve also recently completed the calibration integration, using the great ArgyllCMS to do the heavy lifting. This means it’s literally two clicks (with no options!) to generate an accurate screen profile with hardware that costs less than $50. And it only takes about 15 minutes. Anyone that takes photos or cares about colour accuracy should really invest in one of these things.

Also, a few people have been telling me to just write a GNOME front end for Oyranos and scrap what’s already been done. While I think Oyranos is a great project, I needed something that “just worked” and did the bare minimum integration without a hundred configuration options or integration points. I’ve also been told that some parts of colour management are heavily patented, and so I’m going to keep things as simple as possible for now so gnome-color-manager can be used in as many places as possible. If the Oyranos guys want to hook into gnome-color-manager then that would be great, but I think for now, GNOME Color Manager should aim to do much less than what the Oyranos guys have been trying to achieve.

Well, you could say I’ve been busy. I’ve had a couple of days off this week, and instead of relaxing like normal people, I wanted to fix ICC profiles on GNOME.

First the hard bit. You have to go to your screen vendors website, and download the “drivers” for your monitor. They’ll likely come in a zip file with other junk like .inf, .cat and other windows driver stuff. Somewhere in there should be a .icm or .icc file which contains the data you need specific for your monitor.

Then go to System->Prefrerences->Color Profiles and select the correct file for your monitor. There are also some other test files you can play with.

Then you can set any gamma or contrast or brightness settings if you wish. The gamma defaults to 2.2 just like newer Apple systems and Windows XP, but if you don’t like this you can set it back to 1.0.

You’ll need shared-mime-info from git master (for the double click to work) and gnome-color-manager from gnome git.

There’s still lots of work to do, such as:

• New project icon
• Help and man documentation
• A website of some description
• A mailing list
• The calibration button to be wired up with hardware devices

I’ve ordered myself a Pantone Huey hardware calibration device, and soon hope to have this wired up to gnome-color-manager to make accuratly calibrating a device as easy as a single click.

Now, I’m all out of time for this little bit of fun, as I have to return back to fixing PackageKit and DeviceKit-power for the impending F12 release, but if anyone wants to help me with this I would be very grateful.

I’ve got a multi-monitor setup here, with my T61 being my primary display, and a 28″ LG flatpanel as my secondary display.

I also take a lot of photos, and do editing in GIMP and Rawstudio and have noticed the colours on the LG are very different to the colours on the T61 screen. And when I print them, they bear little resemblance to what I just saw on screen. I’m almost thinking of buying a macbook and OSX just so I can actually see the colours I’m about to print. Heck, even Windows XP does things better than Linux does now.

I’ve done quite a bit of research, and found the general state of colour profiling to be, well, pretty hardcore, and in GNOME practically unusable. I can set my xgamma table using xcalib or dispwin, but this isn’t aware of xrandr setups and only applies the profile to a single screen. It’s certainly not a persistent setting or easy to figure out as it’s not installed by default.

In an ideal world I would visit System->Preferences->Color calibration (which is installed by default) and then either import the .icm file I’ve downloaded from the manufacturers website, or click a button and calibrate my display using an external calibration device. Certainly no commands on the root prompt, or typing in a bunch of hex.

So what am I thinking:

• A gnome-settings-daemon plugin that applies ICC profile when a monitor is attached (or just integrate with existing xrandr plugin)
• A gnome-color-calibration configuration UI that lists the attached output devices and allows you to associate profiles with them
• Available colour profiles installed system-wide and also in the users home directory
• One click calibration using supported devices (for instance ColorVision Spyder2)

Now, this colour problem is very complicated. There’s lots of work in applications to support other colourspaces and profiles and lots of very clever colour libraries (e.g. ArgyllCMS or lcms) but not a lot of work is being done to actually make this usable on the desktop.

Now, I’m very short on time these days, but would be very willing to co-maintain a project (or join an existing one) if other people are interested in this. I’ve got more than enough work to do with PackageKit, DeviceKit-power, and gnome-power-manager but I can spare a few hours a week to this as I think it’s a very important problem to solve. If it’s annoying me with my photography hobby, then it’s got to be a really big deal for professionals trying to use Linux. So, anyone interested?

There’s been a lot of noise about PackageKit and debconf in the past, but not an awful lot of coding… Until now.

Daniel Nicoletti is the maintainer of KPackageKit, and a log time contributor to PackageKit. He’s also the guy behind all the recent SimulateX() methods that required quite a bit of clever coding to work properly on all backends. The simulate methods alone make PackageKit much more useful with apt (where updating a package can remove another) and now he’s dealing with the debconf problem.

I’ll not repeat what he’s planning to do as all the details are available on his blog, but it basically involves adding a DBus frontend on debconf and telling packagekitd a private connection of a helper program running in the session. This means debconf can work in the standard PackageKit “no blocking” modes when required (e.g. for an unattended update) but also ask required questions when setting things up like MySql when running interactively.

I’ve still not changed my stance on asking questions and blocking during a package install, but with this new helper program and secondary session interface, a lot of the debconf headaches can go away. I’m sure all the changes might take a few weeks to even be prototyped, but it’s nice things are going in the right direction.