Category: Color

For artists, photographers and animators it’s often essential to be working with an accurately color calibrated screen. It’s also important to be able to print accurate colors being sure the hard copy matches what is shown on the display.

The OpenHardware ColorHug Colorimeter device provided an inexpensive way to calibrate some types of screen, and is now being used by over 2000 people. Due to limitations because of the low cost hardware, it does not work well on high-gamut or LED screen technologies which are now becoming more common.

ColorHug Spectro is a new device designed as an upgrade to the original ColorHug. This new device features a mini-spectroraph with UV switched illuminants. This means it can also take spot measurements of paper or ink which allows us to profile printers and ensure we have a complete story for color management on Linux.

I’m asking anyone perhaps interested in buying a device in about 9 months time to visit this page which details all the specifications so far. If you want to pre-order, just send us an email and we’ll add you to the list. If there isn’t at least 100 people interested, the project just isn’t economically viable for us as there are significant NRE costs for all the optics.

Please spread the word to anyone that might be interested. I’ve submitted a talk to LGM to talk about this too, which hopefully will be accepted.

A couple of days ago I released colord 0.1.30. This was an otherwise unremarkable release with the normal splattering of a few bugfixes and the occasional small new features.

One such feature is the use of GResource. The new GResource stuff that landed in Glib 2.32 allows you to embed abritary binary data into the actual executable file. This is typically used for embedding small files that are normally loaded at runtime, for instance D-Bus introspection files or small application icons. Embedding that data also lets us strip the blanks from any XML file, and optionally compress the data too. It means we’re not seeking and loading many small files when the binary is run, which reduces by a small amount the amount of I/O that is done, and hence speeds up startup.

So I got thinking. Looking at the cold startup[1] I/O profile of colord, the first thing it does is scan for any files in /usr/share/color/icc for *.icc files. On the default system in Fedora, we only have a few files installed in that directory, and all of them are generated by colord at package build time and shipped in the colord package. We know where they are going to be, and what the contents are. Typically there are ~10 profiles installed, and they are all less than 1kb in size.

Since 0.1.30, at build time the profiles generated by colord (and only those) get included into the binary as resources. This means the colord binary size grows by slightly less than 10k, but means we don’t load 10 small files from the disk at startup. The files are still installed like normal so that applications can reference them as files like before, but if there is an internal mmap’ed copy of the same profile we use that instead. This reduces the amount of I/O that colord does at startup by about half. It speeds the daemon startup by about 35ms on SSD hardware (as seeks are cheap) but on spinning rust drives or LiveCD media it makes an order of magnitude more difference.

[1] cold, as in not in hot-cache. Do ‘echo 3 > /proc/sys/vm/drop_caches’ if you want to see the difference.