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

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Tue, 27 Nov 2012 11:33:43 +1100

Hi Gerhard,

> But my feeling is that obviously many people want to build their camera 
> profiles from
> pre-processed raw files, which have already been white-balanced by the raw 
> converter. For
> this use case a media white point located at RGB [1,1,1] may well be desired, 
> in order
> that the profile retains the white point which was selected by the prior 
> white-balancing.

My feeling is that white balancing before converting to a known colorspace
is probably not the best workflow.  How can you judge white in an
uncalibrated colorspace ?

> In the general case (arbitrarily non-linear device behaviour) the profile 
> needs to be
> applied first, of course, before white-balancing. In this case I'd rather 
> tend to apply
> the profile with absolute colorimetric intent (i.e. no white point scaling 
> when applying
> the profile), since the subsequent white balancing stage would define a white 
> point for
> the photo anyway. Then the profile's WP does not matter any more for the color
> transformation, and can be chosen according to encoding criteria (i.e. cover 
> whole RGB
> cube w/o clipping PCS numbers).


> Btw, one issue comes into my mind when I read the above statement:
> I'm wondering whether a camera (LUT) profile should possibly even enforce a
> luminance-independent mapping of surface reflectances in the captured scene to
> chromaticities in the photo?

I have had in mind for some time, the idea of doing a 2D cLUT profile
for input devices, that would have this property.

(I suspect the idea of shooting the same chart at different
exposures and combining the resulting test values moves a
resulting cLUT profile towards this idea.)

> In case of XYZ PCS there is also headroom up to ~200% in the PCS as well, 
> which should be
> IMO preserved, but in case of CIELAB PCS, the profile is supposed to clip at 
> media white.
> It's the question though, how an input profile with CIELAB PCS should do the 
> clipping, e.g.
>  * let the input table already clip the RGB numbers at RGB(media_white) 
> before feeding
> them into the 3D LUT?
>  * clip (extrapolated) CIE numbers in XYZ space and then convert to CIELAB?
>  * clip in CIELAB space directly?
>  * etc.

This depends on: The CMM implementation (for instance, I'm deliberately ignoring
the ICC spec. and not clipping in various situations where it is not needed
and IMHO undesirable), table range limits, and how the profile values are 
Certainly the -u option is designed to avoid clipping in the Lab cLUT situation.


Other related posts: