[argyllcms] Re: CC Profiles In X Specification and dispwin

Hi,

Leonard Evens wrote:


I'm still finding it hard to visualize what happens to a pixel in a
file.  I can see that it might have to be modified while editing to
represent it in some device independent manner as a "color" in a color
space. But presumably that doesn't get done by the display profile.
The conceptual hurdle I had to clear when I started working with ICC profiles was this:
ICC Profiles are far more "passive" than I'd previously believed - they do very little in isolation. An application uses them in *pairs* to build a transformation (typically using lcms) which is used to convert colours from one colour-space to another. The profile is, at its core, nothing more than a set of mappings from RGB (or CMYK, or whatever) values to and from device-independent colours.
When a colour-managed application loads an image, the internal workflow looks something like this: 
* Load Image
* Does Image have an embedded ICC profile
   Yes -> Use it.
   No -> Use a default profile such as sRGB instead.
* Create a transformation from the Image's profile to the Monitor's Profile
* Convert image data using that transformation
* Display image data.
As you rightly observed, this process doesn't use the LUT data - that's beyond the scope of a normal application. 


Is the point that the data in the display profile is used by the application
> to deal with differing rendering intents, or gamuts, etc. before sending the 
> values to X, which would then use the loaded lut.

Sort of.

The usual process when it comes to colour-managing a monitor is two-fold:
1. Calibration - using both the monitor's controls and the videocard's hardware Look Up Tables to bring the display as close as possible to an ideal state.
2. Characterisation - measuring and building a mapping describing the display's remaining deviation from that ideal state.
The first step is actually optional. You can build a profile to describe the monitor in any state.
If you loaded a simple gamma curve into the LUTs with xgamma -gamma 0.8 then built a profile, then did the same with xgamma -gamma 1.1 both profiles would describe the performance of the display under those particular conditions. Both profiles are valid, but obviously only when the hardware and LUTs are in the same state as when the profile was built! xcalib's loading of calibration data into the LUTs works exactly the same way as xgamma - except that the data taken from the calibration portion of the ICC profile is calculated specifically to bring the display as close to an "ideal" state as possible. 


In particular, would pixel
values, already represented in a device independent color space, which
happen not to need altering due to rendering intent or other such issues
just be sent unaltered to X where the loaded lut would then make the
last corrections.
Well, this happens all the time with applications which are not capable of colour-management - that's why it's helpful for the "ideal" state of the display that calibration tries to achieve to be close to sRGB, since that profile is often considered a "default".
In a colour-managed application, the only time that would be likely to happen would be if an image had the monitor's own profile embedded in it! 


Also, in connection with this, it seems that the application could do
everything without loading any luts into X.


Correct.


So what would be the point of doing it with xcalib?
It's merely a part of bringing the display into a known state. A more advanced counterpart of xgamma, which uses tables specifically tailored to a particular monitor. 


Presumably it is that other applications which don't explicitly do color

> management do use implicit color management and if the display is not
> 'calibrated", what you see on the screen for such applications might be
> wildly off target.
Non-colour-managed applications do benefit from the video-card's LUTs being set correctly, yes. 

All the best,
--
Alastair M. Robinson

Other related posts: