[OpenICC] X and colour management

[Kai-Uwe Behrmann]

Hello all,

this email takes an small look at the current situation how 
applications can do colour management under X. I further try to show 
differences of an X integrated colour management and an application based 
colour management. An (yet fuzzy) proposal of an Xlib informational, 
hardware API follows.


Situation:

the used components for displaying accurate colours on an display are:
o grafic card or monitor holding 3 one dimensional video LUTs.
o colour transformations on server side exist in the Xcms API
o colour transformations inside the application, accessing an CMM in 
  the applications responsibility
o selfcalibrating systems (not widely used, because of costs)


Pros and cons:

benefits of an X integrated solution:
Xlib LUT API:
o putting an gamma LUT in the X server seems no problem for single monitor 
  systems (tested with xcalib)
Xcms (possible future):
o colour management all ! content on screen (needs to extend the API ?)
o potentially works across APIs - XV, Xinerama, normal window ...
o hopefully well optimised (otherwise switched off by users)
o minimal programming effort for applications, which have nothing in mind 
  with colours, like wordprocessors
o leading to an colourimetrically consistent desktop

benefits of an application based colour management:
o possibly implement and use own algorithms, additional hardware drivers..
o provide switches for an bunch of situations, which may be overkill for X
o informational transparency and thereby control of manipulations in 
  colour critical work (open source only)


colour management inside and outside X shows (currently) many problems:
LUT access:
o no X API to transport gamma curves into the monitor LUTs over the video 
  cable (needed to not narrow the 8-bit limit further)
Xcms:
o API is not very popular
o not optimised
o not used(?)
o not ICC conform
application level colour management:
o multi head and similar concepts need much knowledge inside applications,
  which region has which profile assigned to
o detection of hardware is currently difficult with X (no direct API ?)


The question is:  will Xcms continue - how?

As the integration of colour management in applications goes on, an 
coexistence of self managing and X side colour management would be nice. 
This allows applications to use only one colour transformation from an 
colour space of choice to the displays/screens colour space.


Hardware information API in Xlib:

Reading out the EDID information (as proposed by Egbert Eich) and 
interprete it regarding model information, seems possible. I dont know how 
stable this is throughout different implementations.
I found no way, other than looking directly in the X config file, to find 
out the model name of the grafic card + ID number over Xlib. An 
dedicated API for this informations would be highly welcome.
The API could be added to <X11/extensions/xf86vmode.h>, as there resides 
the gamma access functions allready. The XF86VidModeMonitor is not useful 
as it only reflects the config entry which is free selectable and not 
stable over distributions and configuring tools. An hardware dependent 
string like the EDID information is unique, provided it is commonly 
interpreted. 

The reason to get this information over X is simply, it has an good 
network background, many applications will lack. Xlib could tell where it 
runs and on what hardware. With this information an future Colour 
Management System will be able to tell about the adequate profile, either 
to X and to any interessted application.


regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + CMS proposal <www.behrmann.name>