[Openicc] new version of xcalib

[Graeme Gill]

Stefan Döhla wrote:
> As far as I know, these instructions were introduced with ICM2. Win95 
> and NT were shipped with ICM1 which lacked many features.

To be honest I've not really come across anything that could be regarded
as a built in CMS on WinNT, so where ICM1 is hiding, I'm not quite sure.

> But limited to 256 entries ... ALWAYS!

But that is not actually a major limitation, if you are careful
in your color configuration. The input end (8 bit per component)
is a colorspace with a transfer curve that you are defining with
the RAMDAC values. It's therefore possible to choose the values
of your 256 steps so that each step is visually imperceptible.
(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.)
The space the entry itself operates in is out of our control
though, being that of the device. Now if the device is a CRT,
this isn't too bad, since most CRT's have an inherent gamma of
about 2.5, but if it's an LCD or worse, some sort of inherently linear
device (like DMD), then we're going to need more than 8 bits
to be able to achieve perceptually imperceptible steps.

An implication though is that MSWindows isn't allowing for the possibility
of a frame buffer with more than 8 bits per component.

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

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. There are also functions for DDC access. See 
<http://developer.apple.com/documentation/Darwin/Reference/KernelIOKitFramework/IOFramebuffer/Classes/IOFramebuffer/Functions/Functions.html>
Whether or how this is accessible from user space I haven't traced yet.

>>     DVI:
>>
>>     It's not clear how RAMDAC tables work with a DVI interface, which
>>     natively seem to be 8 bit per component only. Are the RAMDAC
>>     tables still applied to the DVI digital output ? Is this
>>     Video card dependent behaviour ? Do displays with DVI input
>>     have their own RAMDAC lookups ? If so, how can they be loaded ?
> 
> Since the RAMDAC works in the digital domain only, I don't expect any 
> difference.

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

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.

>>     DDC:

> I don't agree on this. NEC published DDC/CI which is a add-on for the
> DDC standard. Even for Linux we have rudimentary apps which support some
> DDC features (contrast and other unnecessary items).

Do you have a reference to the NEC document ? I found one on "NAVISET",
but there was nothing directly about DDC/CI in it.

I've noticed the Linix tools, but the impression I got was that they had been
implemented mostly by reverse engineering the wire protocol. It
solves a particular problem, but it doesn't give you much confidence
that it's going to work with all DDC compliant monitors out there.
Of course it shows that access to DDC is available in Linux.

>>     I also haven't discovered any reference yet indicating that it's
>>     possible to set RAMDAC values using DDC, in monitors that have their
>>     own secondary lookup tables (particularly if they are being driven
>>     by DVI). Since DDC specs. are not publicly available, and can only
>>     be obtained at considerable cost, it's hard to know exactly how it
>>     works, or what it is capable of.
> 
> 
> DDC can be seen as I2C over VGA and DVI cables. A unused line is used for
> both. For Linux one would need the i2c modules being loaded and a
> userspace app that knows which memory addresses are to be set for the
> displays LUTs. If someone has a NEC UX**80 and some electronic equipment
> he can possibly get this data. I don't like it as well, that the specs
> aren't published for free.

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 ?

>>     USB:

> It's proprietary for sure - I wouldn't bother with them because DDC/CI is
> definetely the better way to do it.

But the USB supports seemed to be "DDC over USB", so if setting RAMDAC
values is standard on DDC, it might also be the same on USB.
I haven't seen any references to DDC supporting such a function
though. Do you have any pointers to information on how to
set RAMDAC values via DDC ?
[I found a reference for NEC/MITSUBISH to their GammaComp utility
that seems to set gamma ramp values for their particular LCD monitors
via DDC, but it isn't clear if this uses an proprietary extension to DDC. See
<http://www.necmitsubishi.com/support/main.cfm?thePage=http://www.necmitsubishi.com/gammacomp/body2.htm&title=GammaComp%20Download>
]

Graeme Gill.