Technical Blog of Richard Hughes

Linux has traditionally shown the user packages to update and install, which is great for administrators, but sucks for end users. How many times have you been prompted with an update list that asks you to decide whether to update something you have no idea about?

Mo illustrated a few days ago about how confusing the updater is and I agree with her; and it’s mostly my fault for not pushing applications harder. Lists of unlocalized generic packages are so 1990’s, and compared with the Ubuntu Software Center or the Android App-store we look like amateurs.

So, a solution. I’ve been working on app-install with some people from other distros for the last few months, and last week it had it’s first public release. Schema version 2 is already being worked on, and now optionally integrates with PackageKit and also provides some other features like sorting applications by rating and application screenshots. I’ve already generated distro metadata for the entire fedora repository (this takes about four hours on my laptop) and packages are available. It’s really easy to generate metadata for the other repos too, but I digress. Read the README file for all the guts about how it works.

I’ve got two demo applications that use the app-install data. One is an installer and one is an updater. These are work in progress, and show dramatically the lack of my UI design skills.

The installer will be an additional tool (much like the ubuntu-application-installer compliments synaptic) which is focused on ordinary desktop users. If you know what an epoch is, it’s probably not for you. The old tool will remain, so panic not. This tool will just install applications, that-is anything that ships a desktop file with an icon. Anything else just isn’t shown. Sorry! We will hopefully show groups too, perhaps even the same entries as the “Applications” menu.

The updater will be an improved version of the old package updater, and anything that’s not an application (e.g. PackageKit-libs-devel) will be under a group (not shown in the screenshot) called “System infrastructure“. If you update an application that depends on a package from the “System infrastructure” group then it gets pulled in as a dep. Otherwise you only update the system stuff (e.g. systemd, dbus, kernel) if you choose to select the “System infrastructure” metagroup. Of course, you can descend and pick updates in that group individually like before, if you know what you are doing, but I think most people will just install the metagroup as one lump.

Also, bear in mind that neither app-install or the application data packages are in distros just yet. This stuff isn’t well tested. The packages may steal all your magazines from your bathroom.

Now, I mentioned my ineptitude at designing GUIs. This is where you come in. I would love you add mockups of what you think an application installer or application updater should look like to this page. I’m going to ask Máirín (mizmo on IRC) to help with the design work, so please upload mockups I can share with her and the other design people. Thanks!

HP are recalling more laptop batteries. If you’re affected, can you please email me the output of:

for i in /sys/class/power_supply/*/*; do echo $i; cat $i; done

and I’ll add the required rules to upower. Thanks.

GNOME Color Manager provides a high level interface for applications to use.

One of the things GCM tries to do is making getting profile settings easy. This means associating devices with profiles. This doesn’t necessarily mean connected devices like printers and scanners, as .jpg files from my Nikon D60 have a profile, although the camera has never been connected to the computer. In fact, I’ve got several profiles for my camera, studio lighting, outside full sun and cloudy.

By dragging the .jpg or .tiff file (or even a raw file) onto the “Color Profiles” main window you can create a virtual entry that describes the device that captured the image. All the manufacturer, model and serial number data is obtained from the file metadata and a virtual device is created. This virtual device can be assigned a profile (or profiles) and this color profile can be used in photo viewing programs like eog and shotwell. This makes things magically work, as you can generate and assign the profile in GCM and it works everywhere else.

So what do you need to do as an application developer to get the chosen ICC profile for a file? First, you want to check if the file has any embedded profile (you can get the embedded profile using GTK) as this will always take precedence over a generic profile. It’s unlikely that a jpg photo from a camera will be tagged, although a jpeg file from a scanner (if you’re using a new Simple Scan) might be. Lets assume the file has no embedded profile for now.

If you call the org.gnome.ColorManager.GetProfilesForFile method on the org.gnome.ColorManager session service you’ll get an array of tuples. The first tuple entry is the profile filename, and the second is the profile description which you can add to any UI if you want, or it can be ignored. You just need to pass the method the full path of the file you want to view, and the hint. The hint is a string value used to influence what profiles get chosen, but for now just pass NULL or “”.

Of course, this method should be called async, as GCM will be looking at the file and extracting metadata which might take quite a few milliseconds if it also involves a disk seek. You probably don’t want your UI to block. If you’re already extracting the exif data for the image you’re viewing (like eog) then you can optimize the calls to GCM and only re-request profiles if the ‘Make’,  ‘Model’ or ‘CameraSerialNumber’ changes. It’s usually the case that a huge directory of photos will normally be taken from the same device, and thus need the same profile to be applied. Of course, if you are maintaining a local cache rather than just querying GCM for each image then be sure to watch the Changed() signal on org.gnome.ColorManager and drop any caches if that gets emitted.

There is a lot more information on the new wiki page, along with use cases and a ton of programmer notes. You’ll need to compile git master for the drag-drop virtual device creation and the GetProfilesForFile() method call. All this new stuff is going to be available in GNOME 2.31 too, so hopefully soon we can rock hard and stuff can just work.

Yesterday afternoon my community sponsored ColorMunki arrived. Within hours, I had fixed all the issues using it for display calibration:

Notice the device specific images? If you don’t get images you’ll be directed here and asked to submit images for other users. This just left projector support, which was also pretty easy to add:

So, then I moved onto calibrating printers. Normally people only want to profile the local printer, but I really want to profile the printer I use on a weekly basis: Snapfish. The idea of a print shop is you upload image files and in a few days time you get then back in the mail. Now GCM allows me to generate 7 photos worth of calibration squares and when I receive the photos I can generate the ICC profile so all subsequent photos are color compensated:

All the code is in git master, although the print shop feature is not quite finished yet. Yell if it breaks.

A few months ago, I started working on gnome-color-manager. Now, making a display profile using an external calibration device is as simple as a few clicks and a few minutes of waiting. Quite a few people are keen on me working on printer calibration next, and to properly support spectrophotometers. This means you could generate print profiles with a few clicks of the mouse, just like display profile.

Unfortunately, I don’t have a spectrophotometer, and without hardware it’s pretty hard to add support. The devices are also quite expensive, and not something I can expense with Red Hat (they are kind enough to allow me to work on gnome-color-manager in work time as it is!) Generously, the guys on the gnome-color-manager list have put together a collection. If we can get close to the £320 total, then I can buy a device of my own and add support to gnome-color-manager and work on the upstream CUPS support.

If you’re interested in us achieving this goal, and you’ve got a few quid spare, I would be very grateful. We’ve already got £145 towards the total. Any donations gratefully accepted. If we get close enough, I’ll bite the bullet and convince my wife I need to spend some money on “work stuff”. Thanks.

EDIT: total reached! Many thanks to you all!

Work on gnome-color-manager continues. Display, scanner and camera profiling seems to work very well now, but I would really like to move on to creating profiles for printers. To do this I need to buy some expensive kit, something like a ColorMunki. If anyone has one of these sitting in a draw being unloved, it would be all I need to add support to gnome-color-manager. It’s not something I can expense, as it’s not really part of the day job. Anybody?

Does anybody know of any standard CMYK color space ICC profiles that exist in the wild? I’m hoping to convince the copyright owners to release them under a free licence. The Adobe, ECI and IDEAlliance profiles are all really non-free and thus we can’t ship them by default. Thanks!

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!