Datacolor User to User Support Group.

--- In colorvision_group@yahoogroups.com, CDTobie@... wrote:
> In a message dated 2/14/08 11:55:18 AM, yahoo@... writes:
> > Thanks for getting back to me, David. I'm going to sound
> > argumentative here not because I'm disagreeing with you,
> > just because I'm trying to understand where there's a flaw
> > in my logic; I hope you'll take it in the manner intended...
> 
> No, it was me that started sounding argumentative (I'm in the
aftermath of a 
> major icestorm, no electricity at home, up all night feeding the
woodstove, 
> etc... ).

Ouch. (And I certainly didn't think you were being argumentative,
don't worry.) I hope reading through frustrating questions at
least keeps you warm!

> But I really can't teach an entire course in color management theory 
> via email for an interested programmer, so I will decline to answer
your long 
> list of theoretical questions here. Sorry.

:-) No problem; thank you for humouring me as much as you have.

> Reading the ICC spec, and attempting 
> to learn color management from first principles is an admirable
thing, its 
> just unrelated to end user usage of commercial color management
programs.

(In my defence, I've also read a couple of books on the
subject and tried some web research, but I remain confused.)

> Besides, if I attempt to answer your questions here, it will only
create a second, 
> then a third generation of theoretical questions.

Yes, you're probably right; I'm terminally curious. I
have a clear mental model of colour management, but it's
apparently not the correct one!

> Let me give you a couple hints: display profiles do not use rendering 
> intents, that is restricted to output profiles.

Yes, this is one of the things that bothers me. Other than
that they're emissive, I don't see what's special about
displays: the question of what to do with an out-of-gamut
source is just as valid. I fail to see how a monitor under
a fixed set of viewing conditions differs from printed
output viewed under a fixed set of conditions, even if the
monitor's set of conditions has to include a restriction
on ambient light and the printed output's conditions has
to include a specific light level and spectrum. Saying that
metamerism means you can't *always* match perfectly is all
very well, but I get the impression that *never* matching
perfectly is for some reason an acceptable option, whereas
I'd view "perfect under a given set of viewing conditions"
as a good starting point. Just musing about my frustrations
with the ICC; I'm not expecting to be set right!

> And one more: data going to displays 
> from Mac or Windows videocards is eight bit per channel, so there is
no magic 
> way to make adjustments without levels losses except in the display.

Um, this is kind of my point. You can't do it in the LUT,
which is why fiddling with the LUT is a bad idea. It certainly
won't help, assuming the CMS is already picking unique colours
out of the profile, and as such insisting on adjusting the LUT
before generating a profile seems arbitrarily unconstructive.
A CRT *does* have more than eight bits per channel being
output (only 256 possible values, but selected out of 1024
in the look-up table for a 10-bit DAC), so what makes no sense
for an LCD *does* make sense for a CRT.

However, you *can* do it in the CMS before the 8 bits per
channel are put in the frame buffer, which ought to be
performing the colour transformations specified by the
(display) profile in, I hope, more than 8 bits of accuracy,
given that it's being fed 16 bits per channel by Photoshop.
If the CMS and/or profile are really only working in 8 bits
per channel, I'm underwhelmed and surprised. (It's true that
this would be a moot point if I only had 8 bits per channel
in the image colour space. I never do: I'm far too keen on
sorting out the exposure after the event, and always shoot
raw; even with JPEG, I'd still work with 16bpp as an
intermediate step.)

If the source image contains colours which can be represented
by the monitor, it should be possible to select that colour
by putting the corresponding value in the frame buffer. Whether
these colours are distributed evenly, and therefore would work
for an application that's not using the profile/CMS to decide
which values to put in the buffer in the first place, shouldn't
be a factor.

Sorry - I'm not meaning to drag this out, I'm just surprised
that there isn't a simple explanation for where I'm going
wrong! It may be my failure to communicate.

Thanks for listening (and, in advance, for anyone who has
more spare time and the willingness to put me out of my
misery).

-- 
Fluppeteer