[argyllcms] Re: Unable to access VideoLUT

  • From: ternaryd <ternaryd@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Tue, 23 Aug 2016 11:30:10 +0200

On Tue, 23 Aug 2016 16:05:59 +1000
Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:

This seems to imply, that 11 significant
bits per color specifications is indeed
correct? Can you give me a pointer where to
read about the meaning and usage of this
eleventh bit?

Unless you can find nVidia documentation on
this (and public nVidia technical
documentation seems sparse), then no
information seems to be available.

I did find some things. First, there is a post
which refers to a different card and the
previous version of the driver, but exposing
exactly the same behaviour regarding ArgyllCMS:

https://devtalk.nvidia.com/default/topic/925981/364-12-gtx-660-can-t-access-videolut-to-load-display-profile/

The interesting part seems to me what an
nVidia rep wrote:

---- >< ----

1. The pixel values are decomposed into fields
   based on the red, green, and blue masks in
   the X11 Visual.
2. The value from each channel of the pixel is
   used as an index into the X11 Colormap. E.g.,
   for depth 24 with 8 bits per channel, there
   are 256 entries in the colormap.
3. Each entry in the colormap has 11
   significant bits, which map to a conceptual
   [0, 1] range.
4. The color from the colormap goes through
   Digital Vibrance and the new colorspace
   conversion matrix, and is blended with the
   cursor. This blended result still has an
   11-bit range.
5. The final blended result is used as a
   linearly-interpolated input to the gamma
   ramp.

So the last step is what's important for
argyllcms, presumably. 

---- >< ----

The mentioned masks are 10 bits, leaving the
two MSB zero in a 32 bit value. This I can see
in xdpyinfo.

The "digital vibrance" sounds like something
aimed at pretty colors, and not correct ones,
so I think I'm happy that this doesn't seem to
be supported by my card. The cursor thing
should not interfer with color management
(right?), so there is only the new colorspace
conversion matrix left. Information about this
one I could find in chapter 15 of:

http://us.download.nvidia.com/XFree86/Linux-x86_64/367.35/README/index.html

    xrandr --output DP-6 --set CscMatrix \
        0x10000,0,0,0,0,0x10000,0,0,0,0,0x10000,0


[...]
These writable lookups may or may not be the
same as the VideoLUTs that are accessed via
XRANDR, and it is the latter that ArgyllCMS
uses for setting calibration curves, not the
former, since the former are application
controlled.

By what I understand from the first citation, I
would guess, that the 11-bit color maps are
those of X11; as colors are specified by 32
bits using the 3x10-bit color masks, there must
be some type of conversion (divide the channel
value by 1024 to get it into [0..1], then
multiply with 2048 to get the index in the
color table). As this would be a simple bit
shift left of 1, I can't really see the point
of it. But if this is the X11 color map, what
about the Video LUT?

The last sentence of the first citation seems
to imply that ArgyllCMS could actually be able
to access the Video LUT and a color space
conversion matrix, but I couldn't figure out if
there is one such LUT and matrix per monitor or
one for all together.

As I understand my setup so far, I have at
least 4 LUTs: One in the Eizo monitors which I
need to adjust booting in Windows. A second in
the video card, which is the Video LUT. A third
which is the X11 color map, and a fourth which
would be applied by an application using an ICC
profile (and a fifth, if that application
first had to apply an input profile). This is a
whole lot for me to be confused.

-- 
Cris

Other related posts: