[argyllcms] Re: Argyll-reset and Windows-reset gamma curves

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Thu, 08 Aug 2013 22:04:36 +1000

Ivan Kolesov wrote:

> I guess. By the way, do you think this can be tested by checking both cal
> files with dispcal -r? It should show the apparent number of significant
> bits, right?

Not really - I'm assuming that on most of the systems, the Gamma Ramp setting
is one way to the graphics hardware, and the operating system caches the
last values, so (at least on MSWin & Linux) you always get the 16 bit values
back. I think OS X might actually show you what the hardware is doing.

> Also, there may be no difference between Argyll-set and system-set default
> gamma in Linux, and this would prove that the Windows-set curves *are*, in
> fact, wrong.

It depends on the hardware. If the hardware is actually 8 bit entries
(which will be the case for almost all DVI output, but not for VGA or
display port), then there will be no error. If greater than 8 bit,
there will be errors in the least significant bits.

>>From the practical perspective, can you please confirm that those who
> profile their monitors in Windows without prior calibration, should reset
> their gamma with Argyll first?

That's the safest thing to do.

> I've also tried dispcal -R, and it gives
> 10 bit, but that's for uncalibrated curves, so I'm not sure if it's even
> relevant.

It is very relevant - it shows that xcalib is loading inaccurate values
in practice, not just in theory.

> So, I guess the question still stands, if this discrepancy has any effect
> on the calibration and profiling processes via Argyll.

It shouldn't do if you are using Argyll to load the VideoLuts. It will do
if you use xcalib to load the calibration curves for an Argyll created profile.

Graeme Gill.

Other related posts: