[argyllcms] Re: Bug in 1.9 beta
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 29 Aug 2016 15:22:51 +1000
ternaryd wrote:
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)
I've no idea what point you think you are making.
The number of entries in the RAMDAC/VideoLUT
table is the value returned by
XRRGetCrtcGammaSize().
nent refers to the array length, rdepth (coming
from bits_per_rgb) to a portion of the data
type of each member.
rdepth is both an X11 per component LUT entry
size, and (potentially - if the output of the
X11 LUT was wired directly), the input index into
the RAMDAC/VideoLUT, which is the next logical
piece of hardware. The warning message is emitted
if these two values are different.
There is no base for the
above assumption. This would be like enforcing
all array sizes by
int array[1 << (sizeof (int)*8)]
Again, I've no idea what point you think you
are making. The X11 LUT number of entries
is (1 << fdepth), where fdepth is from X11 colormap_size.
The entry size is rdepth, from X11 bits_per_rgb.
The VideoLUT/RAMDAC number of entries is
from XRRGetCrtcGammaSize(), and therefore can
be different from X11 bits_per_rgb.
I'm the wrong man to discuss this; too many
LUTs and too many different terminologies for a
beginner.
I'm at a loss to understand why you are putting forward
such arguments then.
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.
Either you or they are don't seem to be clear
on any problem with the code, or my understanding
of how things work.
He also
claims that there is nothing non-standard in
doing this, but again, I'm not able to defend
this claim.
The X11 Visual and Color values have a clear
hardware model. The connection between that and
the RAMDAC/VideoLUT information returned by XRANDR
indicates a gap in the model, that NVidia seems
to have been less than clear in filling.
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.
I've said that I don't see a whole lot of good
reasons to implement 10bpc frame buffer access,
since test patches and resulting calibrations and
ICC profiles are already > 10bpc.
Graeme Gill.
Other related posts:
