[Openicc] new version of xcalib

[Stefan Döhla]

> (i.e. back of the envelope calculation shows that a 0 to 100 L*
>  range divided equally into 256 steps gives steps of 0.39 delta E,
>  less than half of the perceptible threshold.)

afaik, Lab gray ramps are not the same as standard RGB gray ramps (even
with gamma). They are different especially for dark grays.
Therefore, I expect different perecptual quality in the dark and the
light tones.

>> Compared to Win32 the size of the gamma ramp is not fixed but 
>> driver-dependant.
>> E.g. my old Toshiba Portege notebook has only 64 entries per channel. 
>> The user (in this case xcalib) must downsample to this size. 
>> Upsampling could be possible as well (but I don't think that there 
>> are really devices).
>
>
> Right, so it allows more directly for a frame buffer with more or less
> than 8 bits per component.

Yes, X is ready for that.

> On further investigations it seems that OSX does have a driver level
> capability for a variable number of entries, and 16 bit entry values
> for 10.2 and beyond.

This capability is the same as the above mentioned one in X.

> There are also functions for DDC access. See 
> <http://developer.apple.com/documentation/Darwin/Reference/KernelIOKitFramework/IOFramebuffer/Classes/IOFramebuffer/Functions/Functions.html> 


X has already some basic DDC capabilities. I haven't digged too much into
the sources, but I guess, X could be extended to provide DDC/CI
interfaces to the user (and for X internal use). I read somewhere that
at least XFree86 is member of VESA and should therefore have access
to the corresponding specs. I would really appreciate support for DDC/CI
in the main X distribution.

>>>     DVI:
>>
> So you're expecting that the DVI output will be after the graphics
> cards RAMDAC tables ? I guess that makes sense in a hardware
> way, although overall it doesn't make any sense if DVI is inherently
> 8 bit/component, and LCD's have an inherent response that is
> unlike a CRT's. It implies that LCD's have to have their own tables
> in the driver hardware, that make them emulate a CRT's 2.5 gamma
> (which of course makes sense from the point of view of compatibility
>  of the LCD's VGA input).

If I were a video card manufacturer, I would do it this way. Since most
content is already gamma-tagged, it makes sense that the gamma is
applied internally. But I'm not sure on this.

> It's rather a pity that these internal LCD lookup tables don't seem
> to be accessible in any standard fashion, so that the display can be
> calibrated accurately.

Ben said, NEC extended DDC/CI to support this feature for their
GammaComp utility. I expect other display manufacturers to follow
NEC and implement it the same way (if NEC allows them to do it).

This approach seems to be pretty simple and the right way of doing it.

>>>     DDC:
>>
> In the DDC information that is publicly available, I haven't seen
> any mechanism for that sort of thing. Adjusting front panel controls,
> yes. Poking memory locations, no. Can you point me at any references
> in that sort of direction ?

As far as I've seen it's just setting bits at certain memory locations.
Since DDC/CI is bidirectional, I imagine that the display is queried
before anything is sent or read from these memory locations.
According to Ben, reality is somehow different - but donate me
a NEC UX**80 or SpectraView and I will find the right locations ;-)

Stefan