In a few short days we’ve already got the colord-kde repo up, and Daniel and I have been writing some initial code. Several more people have offered to help this week too.
If you know C++ and Qt please send me a patch for one of the TODOs in the kded module. Most are simple, for instance //TODO: get the md5 checksum of the data
GNOME has been a color managed desktop by default for two releases now, and I deliberately designed colord to have an open Freedesktop DBus API that could be used by both desktops. I am a little disappointed in KDE that it hasn’t made the jump too. Really, KDE just has to include a KCM module to do the 6 things on this list and also perhaps include a simple control center panel to configure it.
Basically, I need a KDE dude. Of course, I can help quite a lot and mentor the project, but I’ve never really coded Qt or C++ in anger, so to speak. If you’re interested, I could maybe even set up a Google summer of code place as well, although I’d prefer it to be an existing person familiar with the KDE community so there is some ongoing maintainer.
If anybody is interested, let me know and I’ll set up a meeting and we can talk and discuss details. Thanks.
My work in color management has been bubbling away in the background, and new features are being added slowly and carefully.
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. :)
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.