[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
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
Other related posts:
