[OpenICC] monitor/videocard identification (fwd)

[Bob Friesenhahn]

On Tue, 7 Dec 2004, Graeme Gill wrote:
>
> 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.

I agree that X11 is just part of the puzzle.  X11 is just an 
application, and there are other ways to address frame buffers. There 
are also many devices which are completely unrelated to X11.  I 
suggested that the display colorspace transformations be done by a 
"device driver" because then there is a good chance that the all users 
of the frame buffer will benefit, even if they are not using X11 (e.g. 
OpenGL).  A device driver will also know about how to use any special 
acceleration built into the hardware.

The Unix environment is a bunch of disjoint parts thrown together. 
Many parts are optional or have several choices available.  Given 
this, it seems that the best approach is to provide a shared library 
that these parts may voluntarily use in order to obtain color 
management in a common way.

> 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.

Unfortunately, Unix in general does not have the notion of central 
configuration.  It does know about shared libraries but beyond this, 
it is pretty much every man for himself.  That is why I believe that a 
common shared library which refers to a common configuration 
repository is the best approach.  The currently available CMS 
libraries provide the low-level CMS mechanics, but they do not provide 
a sharable framework which defines common behavior.

>> 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.

Agreed.  However, most computer DVI interfaces are 8 bit (I think HDMI 
supports up to 12 bit) so when you combine this with the internal 
gamma mappings, there is a loss of actual color resolution. 
Regardless, this issue does not have much to do with Unix CMS except 
to point out that there may be value with pushing the mechanics of CMS 
(but not the management of CMS) as close to the device as possible.

> 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.

What is exotic today will become high-end tomorrow, and what is 
high-end tomorrow will become common the day after.  It pays not to 
rule out advances in technology.

Bob
======================================
Bob Friesenhahn
bfriesen at simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen