That is why I will use Nikolay's testing workflow for this. Maybe it would be a good idea to add this to the documentation?
It's something more advanced users will want to do, so it really belongs in and advanced usage section. Perhaps there is enough interest for a special topic page.
This would also make a good addition to the documentation which does not tell anything about the sensible range of DE: "Make sure you check the delta E report at the end of the profile creation, to see if the profile is behaving reasonably." Maybe some example numbers could be given here?
It's very variable, depending on the details. Some well behaved devices may give averages < 1 and peaks < 2, while things like xerographic printers might be average 6, peak 15, so it's hard to give much guidance.
Actually, the current 1.0.3 release code does something different,The current 1.0.3 release does not support Spyder3 :]...
Right, but it's basically the same driver, because it's basically the same protocol with the same calibration record to the same type of sensors with the same optical arrangement.
Could you comment a little bit about my idea of averaginig non-zero sensor readings? Are you considering/thinking about it/testing it or is it lacking something?
I was going to look into some details, such as when the transcnt or intclks is zero, and whether is is some integration time that guarantees at least two transitions.
When I manage to get the monitor calibrated properly I will try this then. Maybe it will yield sensible results, maybe not :)
There are some affordable and quite good charts available, and US$10 is not that expensive: <http://www.targets.coloraid.de/>, although the IT/8 it better for matrix profiles than CLUT profiles. Graeme Gill.