[argyllcms] Re: Argyll and 30-bit colors

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Tue, 16 Aug 2016 16:56:37 +1000

ternaryd wrote:

Yes it should. A depth of 32 bits in X was
allowed since a long time, and it's up to the
driver what to do with the spare bits.

64 bits - 16 bpc max.

Those lines in
"dispcal -v2" with "Failed", don't they vary
the colors hoping to get a reading which
matches some target values within some
tolerance?

Greater than 8 bpc or dithering help this case,
as would a new dispcal algorithm.

If it's hard to figure out, why not ask the
user? 

Because in general, the user won't know. Operating
system vendors, video driver writers and video
card vendors seem to go out of their way to
conceal such detail. Often, they mostly don't
know themselves.

Maybe you could even allow him to set
some environment variable such that this
setting would apply to all Argyll tools. I
think if someone doesn't know he's using 30-bit
colors, his bank account will certainly know.

A user option is technically practical, but
is likely to be yet another setting that can be
wrong.

BTW, dispcal told me that it was unable to find
the bit-width of the Video LUT;

I'm not sure what you mean.

a bit later I
read that the official software for the Eizo
Monitors (running Windows only) won't allow to
adjust the Video LUT either. Might there be
some connection?

ArgyllCMS currently has no code to set LUTs in displays.

What would be the effect of this upon the
results? Smoother but less precise curves?

Hopefully smooth and more precise curves.

I haven't figured out yet what madTPG is, but
if dithering helps, why don't 10-bits?

They will both work, but one is currently possible,
the other is hard to find.

My ColorMunki Photo certainly not being a high
quality spectrometer, it should be already
better than my previous Spyder4. But I'm
afraid, I don't follow you here: If the
instrument is too imprecise to give reliable
(repeatable) measurements, how would dithering
help then? Would it be possible (useful?) to
run some test cycle to measure the tolerance of
the instrument?

Profiling tends to average out instrument noise,
and there is little point in putting two samples
less than 1/256/chan apart, given the sparsity of
the overall sampling.

The current dispcal code doesn't average out noise when
it is trying to get a sample to hit a particular
target, and display path quantization + instrument noise or
quantization tends to cause problems.

Graeme Gill.

Other related posts:

  1. Home
  2. argyllcms
  3. Archive
  4. 08-2016