One small, but nice feature is the new metadata tags that I’ve been standardising with Florian Höch and others. Of these, MAPPING_device_id is probably most interesting. This is a key that is automatically stored in the binary ICC profile itself, and stores the device ID of the device that it was created for. This means if you re-install the system, or email the profile file to someone with identical hardware, it automatically gets added as the default profile, unless you’ve manually set the device to something better.

From a security point of view, the colord daemon is no longer being ran as root, and instead uses a private group. Most of the work was done by Vincent Untz and the OpenSuse security team, but a few Ubuntu guys helped too and now we can worry less about random library vulnerabilities affecting us.

Benedikt Morbach also switched colord to optionally use a systemd service file, which will allow us to do some cool things in the future with regard to preventing network access, respawning on failure and that kind of thing.

So slowly but surely, we’re increasing the number of things that “just work” and updating colord to use a few best practices and the latest technologies. For the future, I’m looking at a wayland extension for full screen color management using a GLSL shader, but that’s some time away before it’ll be really useful, and allow us to simplify color management for applications even more by putting all the heavy lifting in toolkits.

… so we’re getting there.

If any strings are difficult to translate let me know and I’ll either add translator comments or reword them. Thanks!

Making hardware does cost money, and I can’t give the hardware away for free like I do my other software. I’m aiming to do an initial production run of 50 units, but I’m going to need some advanced orders just to make sure I don’t get stuck with a lot of stock and no buyers. I’m offering a 20% discount on each unit, on the assumption the first users will be testing the firmware and reporting problems. If you want to support a cool open source project, I’m asking £48 for each unit, plus postage and packaging. There’s a whole website if you want to know more about the project, and there’s even a newsletter if you don’t need hardware, but what to know how we’re getting on.

I would very much appreciate it if people could publicize this project, and help me get to my target of 50 pre-orders.

Thanks,

Richard

I’ve got a few hundred measurements like this from the prototype hardware:

input value:  0.123456,0.234567,0.345678
gives:
output value: 0.876543,0.765432,0.654321

Does anyone know how to estimate a 3×3 matrix to convert the output value to the input value? I need to do this to be able to calibrate the open-source calibration hardware that I’ve created. Thanks.

If you’re interested, check out the released tarball or code from git, and tell us what you think.

For those wanting to know the purpose of this little new project, it’s so SPICE can integrate with GSource (for USB redirection), and so that colord can do asynchronous cancellable transfers to colorimeter devices (for native calibration).

I’ve created a new project GUsb that wraps libusb1 with several high level wrappers that makes it easy to use in GLib programs. See the README for more details.

Go here if you want to look at the pre-release code — although we’ve not yet had a single tarball release yet, and any applications using GUsb have to define G_USB_API_IS_SUBJECT_TO_CHANGE before they can include gusb.h

If you’re interested in helping out please email either Hans or myself. There’s no mailing list just yet. It works for me; If it breaks for you, you get to keep both pieces (or send patches). There are no Fedora or Ubuntu packages at this point, although after the pending 0.1.0 release I’ll submit the package for Fedora package review for F16+.

Note, nothing depends on this library just yet; it’s too late in the GNOME 3.2 cycle to add new low level deps, and it’s also not even slightly API stable. Comments welcome.

If you’re interested in the development of the colord color management framework, please can you subscribe to this new mailing list. It’s going to be low volume, and mainly used for development discussion and release announcements.

Thanks.

A year ago, a large part of gnome-color-manager got forked out into the colord project, as color management was needed on desktops like KDE, and also we needed a system component for CUPS. This made the lines of code in gnome-color-manager drop substantially, but then gnome-color-manager gained a dependency of colord.

Fast forward to about 6 months ago. The design team wanted some pretty drastic changes to the color management interface, and most people agreed that is CM should be a core part of the GNOME desktop. It needed to be properly integrated rather than a stand alone package. The following things needed to be done:

1. Redesign the control center panel and push it into the gnome-control-center project
2. Redesign the calibration framework using the new GtkAssistant style, rather than using lots of modal dialogs.
3. Move the profile registration into a gnome-settings-daemon plugin
4. Move the device registration into a gnome-settings-daemon plugin
5. Integrate the colord profile information with the GTK print dialog

For point 1, Bastien wanted me to convert my hastily-written libcolord sync methods into async methods. This meant adding lots of new code to libcolord, and in the end I rewrote most of libcolord to ensure that all the async methods were indeed non-blocking. This took a couple of days talking to the designers, and another couple hacking colord, and another few days hacking gnome-control-center.

For point 2, I had to perform some pretty major surgery on the calibration code in gnome-color-manager, and I’m sure I’ve broken something for somebody. That said, the new UI is pretty and certainly easier to use. To do this I spent two days in the #gnome-design channel posting hundreds of screenshots and talking to all kinds of designers about new ideas. The code itself was probably another couple of days. Matthias found a GtkAssistant bug that Benjamin promptly fixed. Now I’m happy with the new wizard.

For point 3, it was pointed out in the gnome-settings-daemon review that I shouldn’t be passing filenames to profiles in the users home directory and instead I should be passing file FDs. This is of course better from a security point of view, and I spent about a day adding the FD passing as an optional feature to CreateProfile in colord. This uncovered a bug in SElinux (it appears the FD passing stuff is not well tested), which is pretty much solved now. I probably spent half a day working out the SELinux bug.

For point 4, Bastien wanted a lot of the Xrandr functionality to be merged with the existing stuff in gnome-desktop, and for the new color plugin to depend on that. This meant an API change to gnome-desktop, and two new patches for feature requests. These needed followup patches to address bugs and style issues, but hopefully those patches will be good to commit later today. These patches took up about two days of my time. This leaves the device registration patch to g-s-d which is almost ready for prime time too.

For point 5, I initially prepared a patch for the GtkUnixPrintDialog, which worked, but Matthias said was in the wrong place. This took nearly a whole day. I’ve re-factored this into the CUPS print backend and that patch is now awaiting review, although I fear some more drastic changes to the CUPS backend might be required. New functionality that was required in GTK has now been coded, reviewed, committed and fixed. This took another day.

So, all these days look like a giant waste of time, considering you can’t do anything more than you could a couple of weeks ago. But, think again. Taking the time to do the design work correctly, and to build on existing projects and libraries is the key to success in the open source world. Bastien was so strict about gnome-control-center and gnome-settings-daemon as ultimately if my new code breaks just before a big release, he’s the one who has to fix it. Federico was strict as he’s got to maintain and fix gnome-desktop for the coming years. Matthias was so strict with GTK as he’s got to keep things working in a sane way and doesn’t want hacky solutions that will be a nightmare to debug. We all get to use the new stable, debugged and supported code.

This is how open source is supposed to work. It takes an amazing amount of time and patience to do this, but it’s really the only sane way to integrate new functionality into an existing system. Re-implemented features lead to re-implemented bugs, and having to fix things in more than one place. I’m so lucky working for Red Hat, as I get the time to do things like this properly without people breathing down my neck for different things. There are not that many companies that understand how to really foster an open source ecology.

So, expect GNOME 3.2 to be quite cool from a color management point of view. I’m getting there, with a lot of help from my friends.

2011 was my first LGM. Random points of note:

• Huge thanks go to the LGM organizers for sponsoring my flight to and from London.
• James Shubin was a superb host, and I really thank him for letting me crash at his flat for the week and eat his food. He’s a cool dude.
• Meeting up with Kai-Uwe, Peter and the other guys was really great and the OpenICC BOF was a real highlight of the week — lots of thing are coming together now. Lots of color dudes all in the same place. The only people missing that I wanted to buy beer were Marti, Chris and Graeme. Hopefully next year.
• Most of the talks were of a very high quality and interesting.
• Most of the people at LGM were developers of one kind of another, although I did expect a mix of devs and users like at FOSDEM. I’m not sure if a mix would have been better.
• I’m sure colord is stronger as a project from the feedback I’ve received. I’ve certainly swapped contact details with a few people and hopefully some interesting conversations will happen in the next few weeks.
• I think my colord talk went well, although in retrospect it was perhaps a little too technical for the audience. I also talked pretty quickly to try to condense 1h of verbage into 30 mins. Apologies to the translation booth.
• Montreal is a cool place that seems less American than America and less French than France. It’s hopefully a place I’ll return to in the future.
• Poutine is really tasty, in a artery clogging, heart-attack inducing kind of way.
• I hope LGM is in Europe next year; I hate long flights. Either way, I’ll be there.