[argyllcms] Re: CC Profiles In X Specification and dispwin
- From: "Alastair M. Robinson" <profiling@xxxxxxxxxxxxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sun, 13 Jan 2008 12:28:42 +0000
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:
