[argyllcms] Re: Bug in 1.9 beta

  • From: ternaryd <ternaryd@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 29 Aug 2016 06:52:53 +0200

On Mon, 29 Aug 2016 10:56:43 +1000
Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:

ternaryd wrote:
This number is not
related to the (conceptual) size of each
member in the array nor to the number of
bits which are actually significant in that
array. In X11 the member size would be 16
unsigned bits.

No, this is specified by the bits_per_rgb
entry in XVisualInfo,

Xlib.h:

typedef struct {
        unsigned long pixel;
        unsigned short red, green, blue;
        char flags;  /* do_red, do_green,
do_blue */ char pad;
} XColor;

The member size refers to the data type; the
bits_per_rgb to the number of bits actually
used out of those available in the data type.
And neither is related to the array length.

  p->nent != (1 << p->rdepth)

nent refers to the array length, rdepth (coming
from bits_per_rgb) to a portion of the data
type of each member. There is no base for the
above assumption. This would be like enforcing
all array sizes by

   int array[1 << (sizeof (int)*8)]

No.

There are 4 possible elements from the frame
buffer out, and they and the corresponding
depth as recorded by ArgyllCMS ramdac
structure are:

I'm the wrong man to discuss this; too many
LUTs and too many different terminologies for a
beginner. I just handed along something I got
from an nVidia employee, who convinced me and
was backed up by the values I could find when
executing dispwin in the debugger. He also
claims that there is nothing non-standard in
doing this, but again, I'm not able to defend
this claim.

You've already said, that you are not interested
in 10bpc, and while there are only 8bpc, all
this has no effect. So I'll stop right here.

Other related posts: