[argyllcms] Re: Argyll Version 1.3.1 released
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Thu, 28 Oct 2010 13:46:47 +1100
János, Tóth F. wrote:
A possible new(/old?) bug: The dispcal test patch is not "always on top" on
the secondary display (Win7 x64, extended desktop mode, running calibration
on the secondary display)
A simple notepad window could cover the dispcal window when I opened a txt
file. It is strange because I couldn't reproduce it after I restarted the
calibration.
Hmm. It would be interesting if you can reproduce this behaviour.
None of the operating systems have the concept of an "always on top"
window, since they have to deal with there being more than one
applications that says it is to be always on top. So on MSWin,
the test window is marked as being a top level window, and will
always be on top of ordinary windows, but other top level
windows may appear over the top of it (ie. pop-up dialogs, the
minimize/maximize animation etc.).
Generally it is best not to try and do other things on the display
if you are doing a serious calibration or profile.
By the way, despite the increased setup time, I think that dispcal takes
less time to finish the calibration on my H-IPS display (It takes ~35
minutes now ; HQ, adaptive, black/white drift compensations).
Perhaps the readings are more consistent now, so that it does
fewer retries.
And the LUT
curves all start from 0,0,0 now (with disabled black point correction).
On the other hand, I used the hardware settings to set up the D65 WP (with
<0.3 dE) and I told dispcal that it should target the native white point.
The LUT curves are not ends in 255,255,255 as I expected but 255,254,254
(when rounded to 8 bit integer).
That's interesting. Could you send me a verbose output of such a calibration ?
(The code doesn't actually force the end to be 255,255,255, but it does
try and weight it heavily to achieve this.)
Graeme Gill.
Other related posts:
