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

  • From: Gerhard Fuernkranz <nospam456@xxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 26 Nov 2012 15:20:33 +0100

Hi Graeme,

Am 26.11.2012 03:02, schrieb Graeme Gill:
But there's no guarantee that camera 1,1,1 is D50.

Certainly not for the raw RGB data (w/o any white balancing or other color 
transformations applied).

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.

This requires of course the a priori knowledge/assumption that the raw RGB of 
the particular camera is (almost) linear - otherwise it would not work.

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 

For one thing the white test patch on the test chart may not (probably does 
not) map to R=G=B device values. And even if it did, you've chosen a cLUT 
profile, indicating that you do not trust that the the device is additive, 
implying that
you do not trust that the same ratio of RGB values to always have the same 

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?

If the distance and/or orientation of an object to the light source changes in 
the captured scene, then the luminance of the surfaces is expected to change in 
the photo accordingly, but one would rather not expect the chromaticity of the 
object in the photo to change as well.

A CLUT profile created from a test chart does not necessarily fulfill this 
property, but the same surface reflectance may map to different chromaticities 
at different luminance levels. I.e. such a profile is not luminance-independent 
then. For scanner profiles (fixed media type and exposure) this is perfectly 
fine, but for camera profiles, I could imagine that this may be undesired.

I don't think it's correct to assume that brightness should clip at the test 
chart white patch either, if the device values have more headroom. That's 
really what the extrapolation is all about.

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.

Best Regards,

Other related posts: