[OpenICC] monitor/videocard identification (fwd)

[Graeme Gill]

Bob Friesenhahn wrote:
> The application would tell X11 which profile describes its colorspace. 
> The X11 server would tell the device driver which profile describes the 
> colorspace of the data provided to it.  The frame buffer device driver 
> would generate mapping tables (possibly loaded into the hardware for 
> performance) to convert between the application's colorspace, and the 
> colorspace of the attached display.  If the frame buffer device driver 
> controls multiple display frame buffers, then it will need to manage a 
> translation table for each frame buffer.

I'm not convinced that getting X11 to do the color conversion is the
simplest way of doing this. In general an application may want to
interact with several different color devices (printers, scanners,
cameras), so unless all of the driver software for those devices
is also going to handle color in a similar way, the application
is going to be stuck with handling color in a very piece meal fashion.

An alternate view would be that the device driver software (and I'll
lump X11 into this category) deals in device color, and that
a system wide color resource (i.e. like ColorSync or ICM 2.0/WCS)
gives an application the tools to conveniently translate between
color spaces.

Addition OS support is in letting profiles be associated with
particular devices (along with user preferences), so that
there is a central user configuration for color.

Of course the above components could be wrapped by higher level
libraries to make the view even simpler from an application point of
view.

 > itself in order to achieve the best color resolution.  Modern LCD
 > displays already contain translation tables (typically 10 bit) in order
 > to emulate CRT gamma and support user-adjustments, but they can't
 > usually be updated from the host computer.

The other thing to carefully distinguish between is profiling|characterisation,
and calibration|linearisation. The latter is often best buried close to
the device, the former is the world of ICC profiles etc.

Per channel lookup tables don't give you color space conversion. Even lookup
tables and a matrix don't give you color space conversion unless the device
is close to additive, and even then it isn't going to handle gamut mapping
in any fashion other than clipping the individual components. It's
very understandable why LCD displays have lots of circuitry to make them look
like they are a CRT display, but this isn't necessarily the best way if
the operating system and its components are fully color aware.

So a uniform means of configuring the calibration hardware in a display,
and identifying a particular color device are very desirable. I wouldn't
regard the hardware in the display as being generally the place for
color space conversion though. Some device may be exceptions to this -
for instance some of the high end LCD's may have real gamut mapping
and color space conversion support (although I'm not clear that
it is accessible), and certainly things like commercial Digital Cinema
Projectors have such hardware.

Graeme Gill.