libcolor-glib

[Richard Hughes <hughsient gmail com>]

I've just merged a pretty big branch into GCM git master.
libcolor-glib is a new library to be used pretty much exclusively by
GCM. It's not designed to be used by end-user-applications like gimp
and darktable, but instead just by gnome-color-manager and any
additional tools that ISV's want to build. End user applications
should continue to use the DBus interface which has not changed.

libcolor-glib is starting to grow in functionality, and some of the
core new pieces are:

* Userspace DDC control, so we can control things like the HP
DreamColor monitors and upload custom color spaces.
* In-process colorimeter reading.

The last point is interesting. I wanted to put the calibration
routines in process, so we can get rid of that crappy VTE window,
output scraping and all the popups from that. It would also allow us
to do ambient lighting control like the windows tools do. This would
however mean using argyll as a library (which it isn't) and also using
argyll "headless", i.e. without a VTE. Argyll doesn't work very well
without a console attached to it. Argyll is also AGPLv3, so can't be
run in process with a GPLv2+ program.

So, I've spent a couple of evenings reverse engineering the HUEY
device. I needed a MIT licensed version of this code for another
project I'm working on, and so including it in GCM as LGPLv2+ seemed
obvious. The GcmSensorHuey object kinda works now, although I've made
some very large guesses and approximations, and the XYZ color only
*just* bears some resemblance to reality. The ambient light sensor
does however work reliably, although I had to work out a fudge factor
using my ColorMunki, so isn't exactly precise. If you know anything
technical about the hardware, I'm all ears.

So, for the next release if you're using a Huey and gcm-picker, you
get the GCM in-process native driver. Anything else (including the
ColorMunki) you get to use argyll like normal. Calibration is still
always done with argyll, as generating a ICC profile is a little more
involved that just getting a few XYZ values.

So, a few Q&A's:

Q: Do I intend on making other native drivers for other hardware
A: No, as I don't have the hardware. I might make bits of the
ColorMunki work like the ambient light sensor, although I'm having
problems getting traces from the windows driver.

Q: Are the GcmSensorHuey values accurate?
A: No. If we know a bit more about the hardware we can reduce the
amount of futzing and bodging we do. When my head recovers (reverse
engineering is hard...) I'll take a look and see if we're doing
anything batshit insane.

Q: Can we help by copying the logic out of the decompiled windows
driver or from Argyll.
A: No. Don't even look at other source code if you want to contribute
code as LGPLv2+. Note: it's okay to strace argyll commands, or to
record the windows driver usb traffic, and this is what I've been
doing.

Q: Are you working on a sekret project?
A: No. I'm putting a few technical demos together, but nothing sekret.

Q: Are you aiming to replace Argyll.
A: No. Argyll is a mature project that works really well and is a
complete calibration workflow. GCM is a new project that does very
limited things.

Questions ahoy! :-)

Richard.