[argyllcms] Re: Argyll-reset and Windows-reset gamma curves
- From: Ivan Kolesov <ivankolesov64@xxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sun, 11 Aug 2013 11:02:13 +0600
>
> >>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.
>
Thank you. It should matter, because dispread, if run without -k, does not
reset the current gamma ramp as does dispcal.
> > 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.
>
By the way, xcalib does seem to load gamma ramps from vcgt tags accurately,
at least on my system. I've checked this with several Argyll and 3-party
profiles.
>
> > 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.
>
>
Also, I've tested Argyll's interaction with Powerstrip, and it's kind of
funny, because the latter has the 'Write directly to DAC' option, which is
supposed to bypass Win&drivers altogether.
The process is simple: you load the curves in Argyll, 'capture' those from
the videocard in Powerstrp and save it there. The funny thing is, then the
direct write option is checked and I capture an Argyll-loaded profile, it
is mangled, sort of, because when checked with dispwin -V, it shows the
same 0.4% discrepancy with the original cal file. I don't have the math
proficiency to check if it's mangled just like the linear curves are, but
it seems to be the case.
On the other hand, if the direct write option is unchecked when capturing
the curves, they are saved as is, not mangled. Moreover, even if I check
the write direct option before loading the captured curves, they still show
no discrepancy.
I guess the bottom line is, this mangling happens only when the gamma ramp
is read 'directly from hardware', whatever that means in terms of coding.
Otherwise it works like it should.
This does not seem to raise any questions at this point, just FYI. I also
wonder if Nvidia cards have this problem as well. Maybe if someone could
check this...
Other related posts:
