Datacolor User to User Support Group.

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

--- In colorvision_group@yahoogroups.com, CDTobie@... wrote:
>
> In a message dated 2/13/08 4:38:24 PM, yahoo@... writes:
>  
> > So, question number one: Can I use a Spyder to produce a
> > Photoshop-friendly profile without touching the graphics card
> > LUTs? Gretag described this as an "advanced feature" when I
> > last spoke to them, but it seems a logically obvious thing to
> > want to do (use a colour-managed application with an LCD? how
> > dare I...)
> 
> You seem to want to get under the hood and soup up your car before
you even 
> try driving it.

:-) I'm a software engineer. My approach to getting colour
management on my computer was to read the ICC profile spec.,
boggle that "perceptual intent" appears to mean "do whatever
you like", and then try to find products which use the profile
to do what I want. I'm more like a taxi customer that's looked
up a route on Google Maps in advance, and wonders why the taxi
seems to be taking a non-obvious route - I'm prepared to believe
that the difference from what I expected is sensible, but I'd
still like it explained to me so that I know I'm not being, er,
taken for a ride.

> Making LUT-less profiles is NOT standard fare, not even a very 
> good idea, and certainly NOT what you should be doing first,  
though for some 
> reason it seems to you like the obvious thing to do. The color ramps
of an 
> LCD are not nice smooth gamma shaped curves like those on a CRT;
they need some 
> pretty significant LUT adjustments to neutralize and match them
channel to 
> channel. Not doing that, and asking Photoshop to fix it all for you
on the fly, 
> to that very nonlinear, misbalanced screen is just not reasonable.
Thats why 
> neither of the major monitor calibration companies are recommending
it to you.

Hmm. Okay, two issues here. As a starting point, I should say
that I completely accept that the LCD colour ramps are going to
be all over the shop, and that I expect them to need to be
corrected. I'm just going to argue that the LUT is not the place
to do it. Please forgive the long explanation - I'm just trying
to be clear.

1) The LUT is, for your average DVI connection (excluding
dithering, ignoring NEC's dual-link high colour displays,
assuming the LUT is going into the graphics card and not any
internal LUT in the display, and ignoring high colour depth
HDMI/DisplayPort), a mapping from 256 shades of red to another
256 shades of red, from 256 shades of green to another 256
shades of green, and 256 shades of blue to another 256 shades
of blue.

This isn't true for a CRT - most graphics cards have 10-bit
DACs. In this case, it's completely sensible to get the best
colour reproduction possible by trying to space out the
representable colours nice and evenly, and being able to
represent 1024 shades of each colour means that the samples
can be jiggled around usefully.

For DVI, with only 256 shades of each colour, doing anything
other than a direct 1:1 mapping of each colour shade (or,
admittedly, a permutation - but a LUT with an inflection point
would only be useful for a *really* broken monitor) cannot
improve the position of the possible representable colours;
all it can do is remove possible representable colours from
the "list", by mapping more than one frame buffer value to
the same DVI output and correspondingly leaving some possible
DVI outputs unreachable.

For non-colour-managed applications, this might still be a
good thing: if the application puts 128,128,128 in a frame
buffer, it's more important that you get mid grey out than
that colours 200,200,200 and 201,201,201 happen to come out
the same on the monitor.

For a colour-managed application, which knows which colour
it wants to represent and finds out which colour it should
be putting into the frame buffer to get it, it doesn't matter
whether 128,128,128 or 72,51,93 is mid-grey, because it can
find this out and put the right value in the frame buffer
regardless. It *does* matter if 200,200,200 and 201,201,201
are the same, because it would only use one of the two values
anyway; the fact that the two are the same implies that there's
a gap somewhere which represents a unique colour that the monitor
can display, and which cannot now be produced by any possible
value placed in the frame buffer. There has been no improvement
in the range of colours that can be displayed, and the actual
number of displayable colours has been reduced.

Because of the 10-bit DACs, this isn't an issue for CRTs, and
the LUT turns an unevenly-spaced set of 256 colours on each
channel into a more-evenly-spaced different set of 256 colours,
which are more useful for creating a smooth profile. Over DVI,
the LUT turns an unevenly-spaced set of 256 colours into a
more-evenly spaced set of fewer-than-256 colours, all of which
were already present before the LUT was set up. The CMS will
already pick whichever colour most closely matches what it
needs, so (assuming the application is colour managed) the
evenness of the colours is irrelevant, but whether a given
colour can be represented at all *is* relevant. It might be
nicer to have more colours where the LCD doesn't provide them
(which is why the 10-bit LUT helps a CRT), but given that this
isn't an option, using all the colours that *are* available is
better than not doing so.

FWIW, I'd have exactly the same objections to changing the
LUT on a CRT if the application were using a 30-bit display
mode - but these modes are very rarely used. It's possible
that, for an extreme correction, even a 10-bit LUT will
alias two frame buffer values to the same output, but it's
not guaranteed in the way that it is for an 8-bit to 8-bit
mapping.

Given that, and given my assertion that I only care about
the colour quality from applications which use a CMS, why
is it so odd not to want to change the LUT? (Or, to put it
another way, why *would* you want to change it?)

2) Regarding asking Photoshop to fix the display... but
Photoshop internally represents the image in the colour
space chosen for that file. When displaying, it uses the
CMS to map from the internal representation, through the
profile, to the values that it needs to put into the frame
buffer for final display on the monitor.

I appreciate that there are various possible formats for
profiles, and that the variants which rely on 1-D LUTs
and matrix transforms can't represent an arbitrary
nonlinearity. However, the graphics card LUTs are also
only 1-D, and correspond exactly to the "B" and "M"
curves in section 0.5 of the ICC profile specification
- every possible profile representation can do this,
unless I'm completely misinterpreting it.

My understanding is that calibrating a display is about
controlling what colours the monitor displays for given
frame buffer contents, and that profiling a display is
about *determining* what colours a monitor displays for
a given frame buffer contents. A CMS-aware application
should then be able to use the profile to decide what
value to put in the frame buffer in order to get what
it wants. So long as the profile is accurate, calibration
can change the range of colours that the profile can be
used to create (if you calibrate the monitor to a higher
brightness, you can represent brighter colours; if a CRT's
LUT is calibrated to produce more evenly-spaced shades
then the profile has a more evenly-spaced range of colours
from which to pick), but - especially if the application
tries to dither between representable colours in the way
that Photoshop (I'm told) does - the profile is what
determines how a given in-gamut colour is displayed.

Given my objections to reducing the abilities of my monitor
by altering the LUT, why is there a problem in representing
the equivalent attempt to linearise the display in the
profile? I thought that was (partly) what the profile is
*for*!


I appreciate that some people using a colorimetry solution
will be wanting non-colour-managed applications (especially
video) to look better, and that changing the LUT is, for
them, important. However, it seems to me that there should
be a substantial subset of the owners of colorimeters who
want the best output of colour-managed applications, at the
cost of non-CMS-aware apps not producing the right colours.
I don't understand why changing the LUT (for an LCD) can ever
be useful for this subset of people, and therefore why it's
such an obscure thing to ask about.

I'll be completely happy to be wrong about this, and live
with what products can actually do, but not being able to
understand why the available products seem to be "doing it
wrong" is bugging me. :-)

> > Secondly, as mentioned, I used two monitors, with different
> > gamuts. 
>
> Not only that, you use two different TYPES of monitors, which
require rather 
> different viewing conditions, and which should not be used side by
side, or 
> frankly even in the same room.

Said like a true colour professional! I'd love to have a
room full of CG221s. I have what I have, pending any visits to
eBay; I accept that they're not going to match perfectly, and
that I can only rely on one of them at a time for trying to
get nominally correct colours. I can turn one of them off (or
block it from view) when I want to get an exact tone right.
However, for more general photo editing, it would be nice if
they weren't the million miles apart that they currently are,
and that I could make use of the combined screen real-estate
with only subtle colour differences.

> You also describe one of them as nasty... you 
> should get the best displays you can afford, and work from there,
rather than 
> work with nasty stuff...

:-) I might have over-stated my situation. The CRT is a half-
decent Iiyama 19" panel (VisionMaster Pro 454, AKA HM903DT),
chosen because (by that time, when CRTs started to be phased
out) it was pretty much all I could find which can be talked
into 2048x1536 for that money. Previous attempts at calibrating
it suggest that the green gun can't be set low enough, relative
to red and blue. It also crashes occasionally. It was a $400
monitor some years ago; not the shoddy 17" Dells sitting on my
desk at work, which can't even do SXGA properly and have a minimum
black level that's not black even in daylight, but no GDM-900FW
either.

My LCD's a T221, which means it's got a 2001-vintage panel
and correspondingly dubious gamut. I'll gladly swap for any
panel with similar (3840x2400) resolution which covers Adobe
RGB. Oh, wait...

It's not a colour professional's set-up, is what I was trying
to say (I'm an amateur photographer with an academic interest
in colorimetry, and a vague desire to be able to print photos ok
in fewer attempts). Even were I to add a modern LCD with a better
gamut, to replace the CRT, it's not likely to match the existing
LCD very well, and there is simply no alternative to the T221.

> > This leads me to two scenarios:
> > 
> > a) The file I'm processing is fully contained within the smaller
> > gamut of the LCD. In this case, it would be useful for the CRT
> > and the LCD to match (i.e. the CRT should, as much as possible
> > for in-channel mapping, be calibrated using the graphics card
> > LUTs - because I don't want to keep fiddling with it manually -
> > to match the LCD, and I should be able to use the profile from
> > the LCD). Or...
> > 
> > b) The file I'm processing needs the expanded gamut of the CRT,
> > and I should use the CRT's profile with it calibrated to use
> > as large a gamut as possible (which at least means that the
> > limits of the RGB LUTs should be at full range, no matter what
> > this says for the intervening values and the native white point).
> > It would be nice to be able to apply some profile which would
> > keep the LCD correct except for the clipped colours, but I
> > appreciate that XP's CMS doesn't support doing that, so under
> > these circumstances I'm going to have to accept that the LCD
> > won't be "right".
>
> You are working way too hard at this.

:-) *That* I'm quite prepared to believe.

> Just profile both displays (with LUT 
> corrections, please) and if you don't quite trust the most saturated
colors on 
> one, then use Photoshop's Gamut Limit tool to check which colors in
it are out 
> of gamut... you won't need to do this often to figure out what
colors are not 
> going to be quite as satuated as they should be on that screen.

I'm a little confused, I think for the same reason as below:
I'm talking about running two displays on the same computer,
and unless something's changed about XP while I wasn't looking,
although I can fiddle with the LUTs for the monitors independently,
I can only have one active profile at a time.

> And don't 
> assume (until you do a 3d gamut comparison) that the LCD is notably
smaller than 
> the CRT, it may not be that much different, in fact it may be larger
in some 
> areas.

Good point. The LCD predates the time when LCDs suddenly got
better with the colour blue (having found, I believe, a new
filter material), and it's certainly not got an ideal black
level, but it might still have some colour within range that
the CRT doesn't. However, there are certainly colours which
the CRT can handle and the LCD can't, so I still need to be
able to pick and choose.

> > I'm assuming that I'd have to switch between the scenarios
> > manually - I'm not expecting a Photoshop plug-in to automate
> > the process!
>
> You don't need to switch between anything, just use your display
profiles for 
> each display. The two will match, where they can match, and top out
where 
> they top out. There is no manual switching or manipulation needed.

? XP. Two displays, one machine. One profile at a time, no?
(Otherwise dragging a window from one screen to another would
require more than a copy blit.) I understand that Apple and/or
Vista might do a better job of this. If there's a way to tell
Photoshop to render different pixel values into the frame
buffer for each output, my situation is, indeed, simplified.

I'm not sure whether I'm missing something, or whether I've
failed to explain myself. In case it's the latter, I'll
have another go, and try to be brief:

Scenario a: The image fits within the gamut of the LCD. I
can use the LCD's profile (preferably *without* changing
its LUT entries, for reasons explained earlier). In order
to look vaguely like the LCD, the CRT's LUTs can be tuned
to map the frame buffer contents for a given colour on the
LCD to a similar colour on the CRT. There may be colours
outside the CRT's gamut (but probably not many), and,
because it's only a 1-D mapping (red to red, etc.), it
won't compensate fully for the differences between the
phosphors and the colour filters (the CRT's "red" may be,
e.g., more yellow than the LCD's, and there may be bleeding
between the colours).

However, it'll be better than nothing, it *will* be able to
compensate for the nonlinearity of the LCD's voltage/luminance
curves, and it can obviously map the white/black points to
match (gamut permitting). A Photoshop window on the LCD will
be "correct", and dragging it to the CRT will be near enough
that it's not distracting to make use of the combined screen
real-estate. I'm not too concerned with using the CRT's LUTs
in this way because they'll have 10-bit accuracy, which should
be enough to avoid aliasing even after severe abuse of the
gamut. I don't want to adjust the CRT manually, however, since
this would require manual recalibration every time; loading
the LUTs is a level of inconvenience with which I can cope.

Scenario b: The image is out-of-gamut on the LCD, but in-gamut
on the (native gamut of the) CRT. Here, I use the CRT's
profile, with an appropriate LUT setting for it that gives
the best profiling (full range, evenly-spaced samples).
I have a choice when it comes to the LCD: either accept that
the colours on it are wrong, and keep a 1:1 LUT mapping, or
set up a mapping which approximately match the CRT for colours
inside its gamut, and clamp the end-of-range LUT entries. This
particularly has the disadvantage that it'll make the GUI look
odd (unless I fiddle with a lot of settings to move every GUI
colour in-gamut), but the illusion of one continuous monitor
would be better - although, again, the match won't be perfect.
It also, obviously, messes up the display on the LCD, for all
the reasons I argued against LUT mangling for DVI - but since
the LCD is already incapable of displaying the image properly,
I'm prepared to accept it for the unusual scenario of images
with extreme colours (I'm not Ken Rockwell, my cameras have
normal saturation settings).

I could get a better match to the LCD by tuning the CRT at
calibration time. I specifically don't want to do this: part
of the reason for having the CRT in the first place is that
it's a cheap way to achieve a better gamut than the LCD can
provide. It's within my levels of competence to make sure
I'm looking at the right monitor if I'm fine-tuning a colour
against a print-out. Most of the time, I just like having
the screen space to see what I'm doing while I'm editing,
and not having the differences distractingly huge would be
nice.

It would be better to have both monitors producing their
best output (appropriately-calibrated CRT, 1:1 LUT on the
LCD at an appropriate brightness) with correct and
independent profiles. I don't believe this is possible
under XP, which is why I'm talking about trying to have
two lots of optional profiles and trying to get two
completely different monitors to match (and understanding
that they won't, perfectly). I'm happy to be wrong, and
to find out that they can both be profiled independently
and concurrently. Otherwise, I appreciate that trying to
have multiple optional profiles on multiple monitors could
be considered as an "advanced feature".

> But you will 
> need to use appropriate ambient light for both, and appropriate
white lumiance 
> for each. You won't get a side by side match unless you set both to
the same 
> white luminance, and have reasonably similar black points (thus
dynamic ranges) 
> on each, and thats not likely to happen with one LCD and one CRT.

Understood. It ought to be possible for the CRT's LUTs to
match the white point of the LCD (it usually runs brighter),
and for the black points to be similarly matched; I *do* have
control over the ambient light conditions (i.e. heavy curtains).
Whether I can talk the colorimetry software into producing the
appropriate LUTs for me might be another matter.

I may be spoilt by looking at how the profiling works, and
then trying to abstract from that to what I want it to do;
I work in computer graphics, so unfortunately theory tends to
be my starting point for anything like this (this is nothing
compared with the arguments I have with TV salesmen who try
to tell me that 1366x768 is a sensible HDTV resolutions).
It may be that if I'd started with an existing colorimetry
solution, rather than trying to do my research before I
bought, I might not be frustrated with what ought to be
possible, but apparently isn't.

Thanks again for your help, and for that of anyone who cares
to chime in and tell me exactly where I'm being an idiot.

-- 
Fluppeteer