Open source Colour Management System

Skeleton

09. November 2004 - Version 1

All real world optical devices suffers of abstinence of an ideal behaviour regarding colours. While manufacturers of digital camera equipment have shown, they can produce output close to industry standards, other devices are lost in this field. Namely monitors and printers show often unpredictable colours. So the photo comes too dark, the trousers on an web offer have an other hue as in real world, an beautiful smiling face has on some monitors an green cast while on others look dull.
This text is intended to serve as discussion paper for a new system, which supports users and programmers to achieve colour matching through different devices and users preferences.
First I want to lay down why I think an Colour Management System is good for the open Source community and for users. Then an system will be developed, which hopeful will be improved, with the target of supporting for easy colour consistency and manipulation.

Usage:
Tables, diagrams and lists show the logical structures of the proposed Colour Management System (CMS).
Italic letters are used to point out first implementation targets or already implemented parts.
The rest of the text is descriptive, makes specific statements or is simply of polemic nature.

What are predictable colours?

Most users want to get out of their printer what they see on monitor. The web shop shall deliver what was shown on the web site. The family photos on the CD wants to look the same on any computer. An designer wishes to create colours which can go later in production without surprise. For contracts professionals needs colours which looks the same on an test print as on an edition of 10.000 offset prints. The Linux exhibition flyer shall be identified on the web page as well as on an letter head booklet, poster, the stickers on the exhibitors clothes and the booth logo.
These is what shall an Colour Management System make at least possible without too many work on user side. If it is easy to achieve no one will like to miss it.

Current state

Linux has few capabilities to handle physical device colours. The Xcms system implemented by Tektronix was never widely used by open source applications.

It is possible to get predictable colours with comand line tools. The argyll and the littleCMS projects have such tools included. Other systems are based on user experience and are not compatible nor communicable outside their special context. For instance printer drivers have often an build in colour engine which varies from device to device.

Applications have started to explore colour management. Namely three packages exist to calibrate devices. GUI driven programs are on the way to make colour management easy for daily work. These programs work mostly in an own world connected through the industrial established ICC standard. The ICC initiative is an honourable open published standard to communicate colours and devices characteristics between manufacturers, application designers and users. There are several issues with the quality and applicability of these standard, but there is common sense to further develop it to solve the remaining issues.

Comparable projects are Apples^TM ColourSync^TM, which is an very successful and practicable effort as well as Microsofts^TM plans for Longhorn.

Deficits of the current unsystemic state:

one main disadvantage of spreading colour management over different applications is low speed, because it is in software
users are forced to repeat their settings in every application they want to use with colour management
consistency is only achieveable with an few set of application, while carefully handling. Often users need to be an expert.
misinterpretation is usual - on programmers as on users side, as competence is spread over different projects
learning curve for each project is higher as Colour Management needs an serious amount of knowledge, even with the easy lcms API
manufacturers tend to support productive systems to get a balance between investment and profit

Sideffects are:

linux has currently no lowcost calibration devices available
the discredit of an non colour aware operating system falls back on all applications, as non usability state for hole field of tasks
possibility to newly develop an expandable and flexible system

Hierarchy

from user to system level:

User level settings
Application / Distribution settings
APIs and utilities
CMM abstraction
Hardware acceleration

While upper levels can and shall persistently influence the system, lower levels need to make their changes because of higher level request or fluid. For instance an proofing switch in an application shall not to in the configuration file, as it is an temporary setting.

User level settings:
It is clear users want the same behaviour throughout the hole systems giving their preferences or leaving them at preset defaults.
User level settings is the most simple layer . There the level of knowledge is most small. Even so any changes are influencing the whole system, if not an application overrides. Colour experts wants to know what is going on. Configuration files makes it easy to show everything transparently and allow direct access of important settings in an highly flexible manner. Including of other files show dependencies - alternatively dependencies needs to been pointed out in the documentation and the help pages.

Application / Distribution settings:
includes setting of paths and basic services. Here an CMM can tell it is available (more about CMMs below). An database can declare it is up and running. Dynamic settings must go into the users local configuration file, while the installation of an library can show its capabilities anywhere. Of course syntax must be eighter Xresources or xml or <other suggestion> , no mix up.

APIs and utilities:
shall allow programmers and scripters to easily access and deploy the Colour Management System. Utilities take over the part of reading configuration files and are responsibility for consistency.

CMM abstraction:
Concurrent implementations of the ICC standard makes it desirable to been accessible though one single API. Setting of an Colour Management Module (CMM) must be sufficient to provide an basic set of functions. Additional services can been stated in the configurations file. These statements shall be descriptive as they are possibly the starting point to explore capabilities of an CMM. Some of these statements should be predefined by an standard, like profiling and profile creation capabilities, CGATS handling, visualisation capabilities ...
These API needs further layout (suggestions?).

Hardware acceleration:
can be an main benefit of the CMS, as it provides services not easily integratable in applications. Current colour transformations are weighed by quality and speed. Hardware acceleration may overcome these limits providing both at the same time. It is no must, in order to have an quick desktop. sRGB specification of colours allows an easy way to exclude computational expensive transforms. Gamma tables are computational cheap, while getting basic corrections in hardware. Graphics card settings are available through the X API (ICC vcgt tag upload). For Monitor gamma tables (some monitors have an 10-bit internal gamma table) further investigation is needed. Later provides an accurate handling of partial corrections, without limiting colours in an 8-bit colour path - less quantisation errors.

User level settings	Application / Distribution settings	Set of APIs and utilities	CMM abstraction	Hardware accelleration
rendering behaviour preferred CMM (Colour Management Module) set of default profiles to use as fall back behaviour of loading and saving colour data set of user defined transformations optionally bind the predifined transformation to certain situations preferred configuration tools	location of profiles and configurations information about available services preferred configuration tools	toolkit APIs language bindings shell scripts command line utilities support libraries	pure CMMs APIs unified CMM API format translators (icc <-> xml <-> Xcms?)	fallback options for software rendering support of graphic card gamma tables support of monitor gamma tables OpenGl colour transforms with CG shader

Components

interface collection:

configuration
CMM
calibration data query
calibration devices
utilities

User configuration file (xml or ?)

as described in the "User configuration content" description.

Command line tools - for scripting

path hierarchy:

/usr/share/color - for CMS belonging globals
/usr/share/color/icc - for ICC profiles

~/.color - the users CMS place
~/.color/icc - the users ICC profiles

CMS database with possible queries for:

device characterisation datas
Colour Matching Modules (CMM) with CMS API
precalculated transformation tables individually for each CMM
available calibration data translators

API for all Colour Matching Modules (CMMs) as described here

Translators for characterisation datas - convert between ICC <-> Xcms(?) <-> XML

GUIs for the system will usually been build on top of different toolkits and for different distributions.

Programming language bindings can been realized through database access, the command line tools and possibly an C(?) interface.

Specialised Utilities - for

viewing, checking and repairing profiles
checking the paths colours go
communicating colours and colour spaces (vrml, html)

Networktransparent integration with other services - print spoolers, image acquiring protocols on top of these services or integrated into.

The following two pieces can exist separate of the colour handling part of the CMS.

Calibration devices interface

- already in argyll (?) allowing to easily integrate device drivers for serial and usb measuring devices.

Profiling services standards

- including querying capabilities of profilers, providing information about recognised formats (CGATS) and profile upload.

Concentrating competence

An place for an application programming interface

centralised
minimising programming efforts
flexibility
availability

Xlib or an other mostly integrative library (maybe Cairo) is the best place to manage colours. Goal is to reach as many as possible applications. This takes off complex task needed to understand to individually implement by each of the interested teams and programmers.
I will take Cairo as an actual development effort to concentrate services as it fits highly in this strategy.

Cairo is intended as drawing engine and as output unifying library. It has many complex things build in. Programmers write small code, select an output medium and can concentrate on algorithms and the like interesting things. There is an small need to tackle with things, which repeats from application to application like page translation for postscript printing. Additional service is only possible while integrating things like transparency handling, font support ... Consequently all tasks, belonging to common imaging, are best placed there. If elsewhere all applications have to handle them their own. This is contrary to the principle of service concentration. As side effect programmers have to learn less interfaces. They can do more for specialised task, improving robustness, quality and service. We have seen the like with the gtk and Qt toolkits.
Well, as an fast fourier transformation is perhaps overkill for Cairo, mostly every imaging application needs monitor output. As far as Colour Management goes it is fine the display behaves as expected - serving accurate colours. On level below there can Colour Management occur too. For instance writing an imaging application with hardware acceleration (as soon as available) is easy with Cairo. In opposite an graphics application on top of an GL layer is highly specialised. This is what I think makes Cairo an very flexible place for an CMS.

The scheme of an working kernel is like this:
single Application Programming Interface -> services (including Colour Management with fall back option) ->backends

From all places where colour management can be implemented, Cairo seems the only one to realize all criteria on top of this chapter.
It targets itself to become an key position. An CMS would thankfully use this position and brings its own services to attention.

Transition

Old APIs and development kits may coexist long time before the Colour Managements System will affect them inside. While I think an perceptual uniform CIE*Lab API is more desirable, the monitor colour space "sRGB" will remain an default. Applications and toolkits can decide whenever they want to enable Colour Management as they simply let according information pass through.
It is regarding speed correct to pass the monitor profile to an transform in order to achieve no performance break down.

Mixed media

An consitent appearence over differnt media and backends can sometimes only be obtained by switching colour management completely off. Note this is not goal, but part of the intergradation towards an completely colour managed desktop. Passing an monitor profile is in this case as well one possibility.

Backends need instantly an additional mini API. They must tell the central operating drawing engine about their capabilities. In exchange for this information, they have no need to implement full support for Colour Management, or even accelerate throughput.

Implementation

figure 2: CMS interaction

In case "PDF output" Cairo can simply pass all data through, like in following pseudo code example:
cairo_set_data_type_to_uint16
if (cairo_test_pdf_capabilities == can_handle_icc_profile)
profile = cms_get_icc_profile "SBgXL.icc"
cairo_set_icc_profile (profile)
cairo_custom_colour_space_start
// set positions, transfer image data to the PDF backend,
// embeding the profile is done in the PDF backend
cairo_custom_colour_space_end
delete profile
else
...

For case "render with glitz" and the same image:
if (cairo_test_glitz_capabilities == can_handle_icc_profile)
...
else // fallback
source_profile = cms_get_icc_profile "SBgXL.icc"
destination_profile = cms_get_icc_profile_local_monitor
key = cms_get_transformation_key (source_profile, uint_16,
destination_profile, float_type)
buffer = new uint16 [size]
cms_transform_data (key, buffer, image_data, size)
cairo_send_data_to_glitz (buffer)
cms_release_key (key)

If it is clear that the backend can handle the transform itself or do not need any transform, then the fallback code can been commended out.
In any case Cairo would be responsible to deliver appropriate data.

Interoperability

As all big operating systems go the colour managed way, they provide interfaces to do so. For applications from other systems, as well as for cross platform toolkits, it will not be that work as they find an library taking all burden from their shoulders. This makes it more likely to consider porting while using the proposed CMS.

An other toppic is colour information exchange over desktop applications. For example an screenshot should be ideally taken with the source image colour characteristics. The same for colour pickers. One workarround is to refere to the monitor profile and do an backward transform to the desired colour space. This at least enshures to achieve the same apperance as the use might see on an it actual viewing setup.

Acknowledgement

Different concepts and ideas came from applications, other systems, the ICC standard and the discussions on the littleCMS and Openicc mailing lists and the beauty of seeing itself.

regards
Kai-Uwe Behrmann