[argyllcms] Re: Profile input white not mapping to output white

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Wed, 28 Nov 2012 11:21:39 +1100

Ben Goren wrote:
> Again, empirically, the synthetic D50 white patch I manually added does 
> exactly that:
> 1.000000 1.000000 1.000000 [RGB] -> Lut -> 100.000000 0.000090 -0.000032 
> [Lab] 0.999999
> 0.999999 0.999999 [RGB] -> Lut -> 99.999950 0.000090 -0.000047 [Lab] 0.999999 
> 1.000000
> 1.000000 [RGB] -> Lut -> 99.999998 -0.000105 -0.000068 [Lab] 1.000000 
> 0.999999 1.000000
> [RGB] -> Lut -> 99.999939 0.000352 -0.000205 [Lab] 1.000000 1.000000 0.999999 
> [RGB] ->
> Lut -> 100.000000 0.000006 0.000164 [Lab]
> That seems to me to show the maximum possible preservation of highlights 
> without
> compromising the white point, which I should think is the exact desired 
> outcome.

Hello Ben,
        I think there is a conflict in intent here. My intent in writing
colprof is for it to faithfully represent the devices behaviour. The
intent of extrapolation is to estimate the devices response as if it
had been characterised with a test chart that fully exercised its gamut.

Your intent seems to be to create a profile that gives you the
visual output in clipped areas that is most pleasing.

If the profile had multiple cLUT tables (one for each intent),
then it might be possible to simultaneously accommodate these
different aims, but I am a bit dubious as to the utility of this.
It seems to me to be a very special situation in photography where
a pre-set white point cooked into a profile is going to be right
for more than one situation.

In general I would have thought that each photo needs to be assessed
and it's white point chosen to suite that photo, and the software
used to do this is then able to treat (ie. clip) values beyond the
white point in an appropriate manner.


Other related posts: