Year: 2011

Does anybody want to help translate the colorhug-client project to new languages? The transifex page is here.

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

For the past 3 weeks I’ve been working long nights on an open source colorimeter called the ColorHug. This is hardware that measures the colors shown on the screen and creates a color profile. Existing hardware is proprietary and 100% closed, and my hardware is open source. It has a GPL bootloader, GPL firmware image and GPL hardware schematics and PCBs. It’s faster than the proprietary hardware, and more importantly a lot cheaper.

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

Dear lazyweb,

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.

Alexandre Prokoudine asked me a few questions about color management, and this was the result. Enjoy.

GUsb is a GObject wrapper for libusb1 that makes it easy to do asynchronous control, bulk and interrupt transfers with proper cancellation and integration into a mainloop.

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).

In colord, I need to do cancellable asynchronous interrupt transfers to talk to spectrophotometer devices like the X-Rite ColorMunki, and connect up libusb1 with a GMainLoop. It turned out Hans de Goede also needed to do the same kind of integration with his spice work. So, we want to share code to minimize bugs as the GSource code gets kinda hairy.

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.

I’ve just asked for a colord mailing list to be created, as it seems odd to discuss KDE integration with a system daemon on the gnome-color-manager mailing list.

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.

Back a couple of years ago, I started gnome-color-manager. Like all new projects grown out of an idea, it was a self contained project that could be added to GNOME if the user wanted, or removed if they had space or stability concerns.

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.

 

Start of a new era: GNOME 3