Datacolor User to User Support Group.

> Calcs can be done in a larger space, but when all is said and done,
you are 
> sending 8 bits per channel to the videocard, and from there to the
display. No 
> highbit pipeline yet. However, some printer export modules and RIPs
offer a 
> highbit pipeline, and I don't find it to improve prints, so I'm not
hanging my 
> hopes on magic from a highbit pipeline to displays (if and when it
comes). But 
> its great for corrections, even if the actual pipeline is only 8
bits/channel. 
> Thats why loading the same LUT tables to the display, instead of the 
> videocard, can smooth the visible result onscreen, to some degree.
But only if you are 
> asking for fairly radical corrections in the LUT, like shifting the
entire 
> gamma significantly... and its only an on-screen thing, it doesn't
effect the 
> files, or the prints, just the screen preview.

Sorry to keep banging on about this, but I still think we have
crossed wires here. I'm going to have another go at making my
point, with a simplified (if extended) example, and put a big
disclaimer here to anyone who stumbles across this thread out of
context: my understanding of colour management is likely to be
flawed, and I present the following so that its errors can be
pointed out to me by anyone with the patience, not because it's
gospel. David: I'm very grateful for your assistance, and I'll
understand if you feel you've done your duty regarding me
(especially given your climatic conditions) and want to leave it
for someone else with the patience to unconfuse me, but I'll be
most grateful if you have time to tell me where I'm going wrong.

Are you sitting comfortably? Then I'll begin.

Let's say we have a hypothetical two-bit display, on which we'd
like to display evenly-distributed greys between 0 (our black
point) and 1 (our white point); that is, we'd like our four possible
frame buffer values to be:

(bit pattern -> intensity)
00 -> 0.0
01 -> 1/3
10 -> 2/3
11 -> 1.0

[I realise the definition of "evenly-distributed" sweeps a can
of worms under the carpet. This is irrelevant for the purposes
of this hypothetical discussion.]

Now, say our actual monitor isn't nicely linear, like this. The
actual intensity it outputs when fed the four frame buffer values
are:

00 -> 0.0
01 -> 0.1
10 -> 0.35
11 -> 1.0

(Note that our end points are correct - we've done our best to
set the white and black levels. We know the values from our
attempt to profile/calibrate the monitor.)

A colour editing application which doesn't know about colour
management will place bit patterns "00", "01", "10" and "11" in
the frame buffer and magically expect them to map to "0", "1/3",
"2/3" and "1" respectively. We can't make this happen, but if
there's a look-up table on the graphics card, we can map each of
the frame buffer values to the nearest possible colour that the
monitor can display. In this case, we end up with the following
look-up table:

00 -> 00 -> 0.0 (= 0)
01 -> 10 -> 0.35 (the nearest match to 1/3)
10 -> 10 -> 0.35 (the nearest match to 2/3, just)
11 -> 11 -> 1.0 (= 1)

Now an application trying to get 1/3 and 2/3 by putting 01 and
10 in the display will get the best approximation that our
display can manage.

However, there are two obvious disadvantages to having done
this:

1) It may matter more to the display that bit patterns 01 and 10
are different than what exactly they map to. This is likely to
be the case for GUI features with subtle shading, and for a less
hypothetical display, it's most likely to be a problem where the
display's gamut is clipped and a larger possible colour range are
all mapped to the same colour.

2) There is now no value that we can place into the frame buffer
in order to reproduce colour 0.1, which is a colour which the
display is perfectly capable of reproducing. Our four-colour
display has become a three-colour display.

If we look at an application which uses a colour management system,
it no longer puts a fixed value into the frame buffer, expecting
a fixed output. Instead, the application passes the colour it wants
to the CMS, which responds with the value which needs to be placed
into the frame buffer.

On a perfect (0, 1/3, 2/3, 1) display, if an application asks for
1/3, it will be told to place "01" in the frame buffer. For our
display, 0.35 is the best approximation to 1/3; the CMS will tell
the application to use a bit pattern which results in 0.35 if "1/3"
is asked for. If no look-up table is used, and our possible frame
buffer values map to 0, 0.1, 0.35 and 1, the CMS will tell the
application to use "10", which corresponds to 0.35. If the
graphics card LUT is in use, the CMS could tell the application to
use either "01" or "10", since they both result in the same output.

If the application asks for colour "2/3", there's only so much
that our display can do. The CMS will return the best colour match
that it can produce, which is a bit pattern that corresponds to
0.35 whether the LUT is in use or not (the LUT has done nothing
to improve matters).

If the application wants to display "1/6", there's a difference.
Without the look-up table, the best approximation to "1/6" that
the display can reproduce is 0.1; the CMS will return the bit
pattern that produces this (01). With the look-up table, we no
longer have a bit pattern which can produce 0.1, and our best
match to "1/6" is "0".

While the error in approximating "1/6" as 0 is less than the error
in trying to produce "2/3" and getting 0.35, the LUT still reduces
the ability of the display to reproduce colours accurately across
*some* of its gamut. While the LUT has not made the worst errors
in reproduction any worse in this case, it has still had a
detrimental effect on the display.


To extend the analogy, let's see what happens if our graphics
card LUT has an extra bit of output quality (as with the extra
two bits from a CRT being driven from a 10-bit DAC via an 8-bit
-per-channel frame buffer, or a high-bit-depth digital link
such as dual-link DVI, HDMI, or DisplayPort). Let's say the
eight possible colours from our three bits of output now map
to:

000 -> 0.0
001 -> 0.04
010 -> 0.1
011 -> 0.17
100 -> 0.25
101 -> 0.35
110 -> 0.6
111 -> 1.0

Before we update the look-up table, it contains:

00 -> 000 = 0.0
01 -> 010 = 0.1
10 -> 101 = 0.35
11 -> 111 = 1.0

In calibrating the monitor, we can set up the look-up table to
produce a better approximation to 0, 1/3, 2/3, 0:

00 -> 000 = 0.0
01 -> 101 = 0.35
10 -> 110 = 0.6
11 -> 111 = 1.0

In addition to making non-colour-managed applications produce
better colour, this *does* help with a colour-managed app. We've
lost the ability to display 0.1, but - rather than gaining a
duplicate value mapped to 0.35 - this time we've gained a new
colour, "0.6". While we'll lose a small amount of accuracy in
reproducing colour in the 0.05 to 0.225 (the range of colours
nearer to 0.1 than anything else available), the much larger
range from 0.475 to 0.8 is now more accurately represented
by the new colour. So setting the LUT on a CRT is a good thing,
but only (from the point of view of CMS-aware apps) because
previously-unavailable colours are added which are more useful
in filling "gaps" in the colour space than the unmodified range
of colours that we can reach.

Note that I'm assuming that a colour-managed app is capable of
asking for a colour such as "1/6", even though the frame buffer
has less accuracy than this. I don't see a problem with that:
firstly, Photoshop (et al.) can work with 16-bit internal
representations of documents. Secondly, in general the document
colour space won't have values which line up nicely to values
which the monitor can display (unless the document colour space
*is* the monitor colour space); even if the document only had
four shades of grey, there's every chance that one of them
could be best represented by "0.1".

I've over-simplified the job of the CMS here; in reality, it's
likely that an application would use the nearest colours that
the monitor can display, and dither between them to produce
a better approximation to the desired colour. Nonetheless, it
helps for as many of the monitor's available colours to be
available as possible. ATI's AVIVO cards can take a 10-bit
LUT and dither the output over DVI to approximate more than
the native 256 colours, but this dithering clashes with the
dithering performed in the CMS; it's better to maximise the
number of colours which can appear in any single pixel, and
for your average 8-bit-per-channel LCD and DVI connection,
that's best achieved by leaving the LUT alone. (Monitors with
internal look-up tables may or may not be able to do better,
depending on whether they also produce more colours through
spatial dithering.)

Obviously the deletion of a few closely-spaced colours is less
of a problem when 256 colours are reduced to (say) 248 than
when 4 are reduced to 3. Nonetheless, the argument holds that
the display has lost the ability to reproduce some colours
as accurately as it initially could. Additionally, although
the colours may be more accurately positioned along the 0..1
range, it's likely that any nonlinear arrangement will make
the spacing between nearby colours less even: there will be
jumps (most obviously, in our simplified example, the gap
from 01 to 10 is 0.0, since they map to the same colour,
whereas the gap from 10 to 11 is 0.65). This lack of smoothness
may be more disconcerting than the absolute accuracy of the
colour (which, without using a profile, is always going to
be hit-and-miss), for some applications.

Hence, I still claim, at least for a colour-managed application
and on a standard DVI display, doing anything but leaving the
LUT alone can only be harmful. I'm happy to have it explained
to me where the flaw in my logic is. Failing that, I don't
suppose there's a developer API available for the Spyder
colorimeters, is there? (I'm prepared to roll my own profile,
if I have to, but I still need the data...)

As you say, all of this is "only an on-screen thing" - but
since my needs of colour management don't extend to matching
two printers, or accurately reproducing scanned colour, my
sole concern is being able to edit an image on-screen and
have it look (reasonably) "right" after I print it out. I'm
quite keen that the display part of colour management work
correctly; otherwise I wouldn't have started my attempts at
colour management with a display colorimeter and the printer
manufacturer's profiles.

I realise I'm making a bit of a pain of myself with my first
appearance on this group; for that I apologise. My thanks
again to anyone who's got this far, and who can help me, and
to David for his previous help.

-- 
Fluppeteer