I'm having an issue where the luminance readings from Argyll 1.1.0 RC2 are always high by about 4-6% when compared to any other application that uses the EyeOne.dll SDK provided by X-Rite.
Hmm. I checked using my Rev D., and got a discrepancy of about 1% at a luminance level of about 42 cd/m^2, which (last time I looked into this) seemed close enough, given that I wasn't sure that the reference (my display) was more stable than that. Looking at it again however, I have found that this discrepancy is explained by a bug in my driver - I've accidentally swapped the high and low gain linearity factors :-( :-( :-( Fixing this up and testing again over an average of 5 readings of white with both drivers gives an error of 0.05%, an improvement of 20! For my Rev A instrument the agreement between the two drivers has a discrepancy of 0.02%. So it will be interesting to see if your error goes away with this fix. [I note though that there is a 12% discrepancy between the absolute values of the Rev A and Rev D instruments I have access to - absolute calibration is notoriously difficult.]
Graeme Gill, on a somewhat unrelated note could you add an option to dispcal and dispread to always average by a user specified (or automatic?) number of readings before recording/using/displaying any such value? Adding a threshold value to the previous idea may not be a bad idea either.
I'm not so sure about this. dispcal is already very, very slow compared to other calibration software. Internally the i1pro driver already checks a reading for consistency over the integration period. I understand that you are seeing some "interesting" behavior in your particular situation, but before adding some sort of counter measure, it would be better to understand what is causing such inconsistency.
Since the values read jump around slightly on my CRT, especially for dark readings (probably because of the Eye-One Pro which I've heard is weak at low luminance),
The combination of a CRT display and the i1pro is not as refined as some of the dedicated colorimeter such as the DTP92 or DTP94 which have hardware synchronization to the CRT refresh period. All you can do with the i1pro is to use a long enough integration time to make the refresh influence small. A longer integration time also improves low light accuracy. A more interesting option might be to have a mode for dispcal and dispread to use the i1pro adaptive reading mode rather than a fixed integration time. This should result in longer integration times for darker values. Graeme Gill.