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 numbers).
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 chromaticity.
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, Gerhard