Simon Kirby wrote:
So, I have found that for my needs, simply performing the first step of running "dispcal" and then feeding the .cal file to "dispwin" makes me happy. The tile generation and then profiling generation from them seems to be more than I need, unless I am missing somthing. Assuming I use a 2.2 gamma ramp and working with images accordingly, do the additional steps help further? I can use "xicc" to tell appications to use the profile where supported in Linux, but how does this help further? One cannot adjust the wavelengths or saturation of theprimaries of the monitor, so I am not sure I understand how this helps.
Profiles are only useful if applications make use of them. You can certainly alter the white point using calibration, but you generally sacrifice brightness and (level) resolution to do so if all you've got to work with are the Video LUTs.
I've gone around and run this release on a few laptops and LCDs. I am quite happy with the results except for one point -- the slight shift away from black to a lighter grey colour for RGB 0,0,0 even with -yl and/or -k0.0 seems to still bother me. The problem appears to be more apparent on displays with a darker black. On laptop screens, the diferent is not as obvious but still apparent. Is it simply that the sensor cannot see as dark as I can see (albeit only when the entire display is black), or is there something else occurring? For an example, the .cal file from my desktop LCD contains: NUMBER_OF_SETS 256 BEGIN_DATA 0.0000 0.034718 0.026097 0.033171 3.9216e-03 0.038991 0.030068 0.036688 7.8431e-03 0.043202 0.033990 0.040177 0.011765 0.047353 0.037865 0.043639 If I load this with "dispwin", black becomes visibly brighter. I should note that when I manually adjust the values for the 0.000 index, I can see no change from native black until reaching 0.19 for any channel. Assoon as I reach 0.20 in any channel, I can visibly see the difference. I suppose this means the LUT is 8 bit and 0.20 is enough to round up to1/256. In any event, if I can see it, why wouldn't dispcal have output something closer to 0.10 for these values when using -yl -k0?
Hmm. I'll take a look at it. It seems to be caused by the target white point shifting, and the black point being computed relative to the white point.
One final question... :) Why do dispcal and the other software I have seen do multiple passes rather than a single pass. Would it not be easiest to simply measure a each video output level per channel and then do the calculations and be finished? Are the multiple passes there just to reduce the amount of sampling needed?
You can't determine the RGB needed to produce a target neutral value from the separate channel measurements, unless you assume the device is perfectly additive. Making such an assumption would severely limit the accuracy of such an approach on real world displays. So short of making many thousands of measurements up front to model the 3D RGB->XYZ behaviour of the display near the neutral axis, it in fact should take fewer measurements to iteratively find the RGB that produces a target neutral XYZ, rather than attempting to do this in one pass. Graeme Gill.