[argyllcms] Re: Strange contrast clipping during calibration

  • From: Gerhard Fuernkranz <nospam456@xxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Thu, 23 Aug 2012 12:14:47 +0200

Hi Graeme,

granted that the display behaves at least monotonic, mightn't it be better to 
search for the brightest WP with the desired chromaticity, subject to the 
constraints max(R,G,B) = 1, instead determining the clipped WP from a coarse 
(possibly too inaccurate) model?

[ However, there are situations where a WP with max(R,G,B) = 1 may not really 
be desired. For instance, if the channel response happens to be say 
monotonically increasing in the 0...0.9 RGB range, but flat (clipped) in the 
0.9...1.0 range, then we would rather want leave out the clipped region 
completely and place the WP at the knee at 0.9, and not at 1.0. Unfortunately 
that's not just fiction - I have seen this kind of clipped channel response in 
real life on an LCD display. And I could imagine even more weird behavior of 
display-internal color corrections. Basically, in order to deal with such 
flaws, one would need to determine the largest monitonic RGB subset 
[0..Rmax,0..Gmax,0..Bmax] first, and let the calibration limit the RGB numbers 
sent to the display to this subset. ]

Best Regards,

Am 23.08.2012 02:24, schrieb Graeme Gill:
János, Tóth F. wrote:
Changing the luminance targets to "native" didn't change anyting.
No surprise there - the white point needs to be native for the algorithm
to be used that targets a dynamic 100% in all channels. A non-native white
point targets a calculated white point value.

The puzzle is why the target that is computed from the additive model
doesn't actually lie close to the gamut surface (ie. doesn't have one channel 
at 100%).
In the previous log you sent me, you'll notice that the clipped value was 
expected to
have an RGB value of 0.886559 0.823500 1.000000 for a white point target of XYZ
83.058731 87.390821 95.159898, but the eventual RGB to meet the white
target was 0.9106000 0.8348100 0.9275700. So something is out of
kilter with the initial model and the actual device response.

It's possible that this is due to the inaccuracies of the rough models device
curves. I will change it to just use the matrix to compute the gamut
boundary clipping, as this may solve the problem. You can try this out

Graeme Gill.

Other related posts: