[argyllcms] Xorg video card lookup tables, tone response curves, etc

Hello all,

I've just recently become interested in all of this because I'm writing
some software (in Matlab) to invert scanned BW negatives. After
spending far too long reading the docs, archives and doing some
experiments with an Eye-One colorimeter and two displays, it's
starting to make sense! Sorry for the long post, but I'd just like
to make sure I've understood everything correctly.

First of all, let me say 'thank you' to Graeme and any other
contributors for writing Argyll - it's *much* better than the software
that comes with the Eye-One.

As I understand it, the calibration procedure is meant to bring the
display hardware/drivers into a state such that there is a well-behaved
relationship between pixel values 0..255 and luminance of the display.
So, question 1:
- which, if any, hardware and software combinations can result in
   a gamma table output resolution of greater than 8 bits? Can Xorg
  do this? I had a look at the xorg mga driver code but was left none
  the wiser.. A related question is, does X11 manage the gamma ramps
entirely in software, or can it ask the video driver to do it in hardware? 

Next, dispcal can aim for one of several target curves relating input to
intensity: a power law with a particular gamma or the sRGB luminance curve, but in both cases it has to correct for the non-zero black point of the display. 
According to the fount of all knowledge (wikipedia) the srgb curve is
        I(x) = x/12.29               for 0 =< x =< 0.04045
        I(x) = ((x+a)/(1+a))^2.4 for 0.04045 < x =< 1,
where a=0.055, the numbers being chosen to give 0th and (approximate)
1st order continuity. Going from the textual description in the dispcal
docs, dispcal adds in the black point so that, by my interpretation, the
target curve should be
        I_b(x) = b + (1-b)*I(x)
Is this correct?
        
The other option is described as a gamma curve with an input offset, so
I suppose that would be something like this:

        I_b(x) = ((x+a)/(1+a))^g

where  b=(a/(1+a))^g is the target black point, so

        a = 1/(b^(-1/g) - 1)
That would be fine and quite manageable if we knew g, but the documentation states that g is chosen such that I_b(x) matches the relative intensity of the 
*ideal target gamma curve*, ie, the constraint is

        I_b(0.5) =  0.5^gt
where gt is the gamma specified in the -g flag. Solving this for g appears to be quite tricky - is this really what dispcal does? Wouldn't it be much more 
straightforward, from the point of view of an application that wants to
acheive a certain luminance, to set g=gt?
Moving on to the profiling, no matter what the target curve during calibration was, presumably I can get the measured response after calibration from the profile? Am I right in assuming that the red, green, and blue tone response curves (which are tables in the profiles I've produced with argyll, but a parameteric gamma 
curves in the profile I producing using Gretagmacbeth's software)
will tell me the luminance of the display for each of the 256 input values, assuming 
the corresponding video card gamma table has been installed?
If so, then my plan is to display gray level images in matlab by doing optimal quantisation to the TRCs directly, minimising, eg mean square error in log intensity, 
skipping any notional gamma response.
In fact, for devices with only 8 bit DACs, is it not the case that the best thing is to use the native uncalibrated response, thereby not wasting any gray levels due to quantisation, and use the profile to fit the image to what the display can do? And by the same argument, the next best thing is to calibrate to a gamma as 
close as possible to the native gamma, again to avoid wasting colours?
The other option I thought of for high quality gray level images on devices with >8bit DAC resolution is to do image-specific optimal quantisation to an adaptive gray map with high resolution entries, then install the map into the video card. That would give you the best possible 256 gray levels chosen from, eg 1024 for 10 bit DACs. If the target image contained mostly subtle gradations in a narrow dynamic range, the video card would spend it's 256 colours in a narrow range. Has anyone tried this? I guess it could be done by interpolating the TRCs for the uncalibrated display to get the high resolution 
mapping from LUT entry values to display luminance.
One last question: does anyone know what happens in Xorg under Mac OS X? Does it manage it's own VCGT or does it share the one managed by the underlying Quartz display 
server?

Ok, that's it for now :)
Thanks,

Samer

Other related posts: