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

Graeme, thanks for all this information - it was like christmas
morning. A few further points below...

On 14 Apr 2008, at 05:03, Graeme Gill wrote:
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?


Yes. People complained that the resulting curve didn't match
the expectations set by other packages, hence the distinction
between the technical gamma (the actual power used), and the
"popular" equivalent gamma value.

 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?


No. It created more confusion to do this, since people want to be
able to use their expectation of what a particular gamma looks like
portably between systems.

[ At the moment I'm not entirely convinced that using an input
  offset for the power curve is necessarily the right thing to do.
  It seems like it should be in theory, but it's hard to be sure. ]
This is interesting. It seems to me that there isn't a single right thing 
to do. For an application that cares about accurate intensity display,
the important thing is to have a known, easily invertible relationship
between pixel value and intensity. In that case, it wouldn't matter
what calibration curve was chosen because the app would just use the
matching inverse to map from the desired intensity to the pixel value.
The whole Gamma curve thing was/is an approximate model of CRT
behaviour that doesn't fit once you take the black point into account
 - the problem is that people are used to the resulting colour space
(RGB values from 0 to 1) and some expectations of what "50%" is
supposed to look like.

I think it would make much more sense to throw out the Gamma
calibration model and bizarre nonlinear RGB spaces and calibrate
to log-intensity instead, that is if x is the pixel value between 0 and
1, then the intensity would be

        I=exp(k(x-1)) where k=-log(black_level)=log(contrast_ratio)
so to invert,
        x=1 + log(I)/k

The k is the "Dmax" of the display is the only required
parameter. Applications that manipulate RGB pixel values should
expect these to represent log intensities, eg to double the intensity,
add log(2)/k to the pixel values. This should give a reasonably
even spread of perceptible differences across the range too.
In my work with black and white negatives, I'm considering using
16bit log scale images for intermediate storage too - it simplifies
the maths and preserves information.
Am I right in assuming that the red, green, and blue tone response curves 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?


More or less. In the case of the Argyll profile they are the
per channel curve shape that minimizes the discrepancies between
the characterization model and the measured test values. The term
"luminance" has a particular meaning in color science, and no,
these curves aren't directly related to luminance, although
there may well be a strong correlation.


Maybe I was using the wrong term - I just meant intensity, ie
proportional changes in XYZ values.




of room to miss display response detail. The calibration on the other
hand is more detailed, using up to 128 measurements per channel,
and therefore capable of compensating for the detailed behavior
of a particular channel, and even the overall display if the


So does this mean that the TRCs in the profile are based only on this
sparse sampling of the colour space? And targen cannot sample
densely at least along the 3 colour axes? Having written code to compute
pixel values from target intensities using only the information in the
TRCs (inversion by cubic interpolation) perhaps it would be more
accurate to go via the calibration curve after all. In particular, the
TRC inversion suffered at the dark end because of the 16 bit
quantisation of the TRC entries - repeated values mean that the
TRCs are not actually invertible.


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? 

Sounds feasible. I'm not sure many people have tried image specific
calibration curves though, except for very special situations.
(it used to be done a lot in presenting color images on 8 bit
frame buffers of course, where the aim was to quantize 24 bit color
to 256 representative colors and then dither).

Yes, I remember when X used to switch colormaps between windows!
Maybe we don't really want to go back to that sort of thing...
If you wanted to take the path of not calibrating the display, then it would 
be advantageous for presenting greyscale output to optimize your test
chart to have a great number of test values near the neutral axis.
targen doesn't really have tools for this currently.
yes, I tried the -g parameter on in the vague hope that it might do something 
like that but I didn't check the resulting .ti1
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?


Sorry, no, I've never tried running X11 on OS X. It is quite possible
that there is no access to the video LUTs with this arrangement,
since under X11 it uses XF86VidMode extension which may not be available.
Well, for anyone who's interested, I've tried dispwin under OS X with Xorg running, and though Xorg does not have the XFree86-VidModeExtension, it does share the LUT with the rest of the system and is affected when dispwin is used. In particular, I was able to get Matlab to reliably display any chosen combination of entries in the LUT (tested by installing weird colours in the LUT!) so that's good 
enough for me.

Samer.



Graeme Gill.

Other related posts: