[argyllcms] Re: Black point, gamma level
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: Simon Kirby <sim@xxxxxxxxxxxx>
- Date: Mon, 22 Oct 2007 23:50:39 +1000
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 the
primaries 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. As
soon 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 to
1/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.
Other related posts:
