[argyllcms] Re: Camera matrix profile, adding ti3 perfect whitedata set
- From: Nikolay Pokhilchenko <nikolay_po@xxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Tue, 02 Feb 2010 12:48:36 +0300
Date: Tue, 02 Feb 2010 11:57:51 +1100
Graeme Gill wrote:
>
> > But for a printer,
> > for example, the situation is different. The chromaticity of the
> > darkest dark can and often is different from the chromaticity of the
> > white patch (ink vs paper). (And for a monitor?) So for a printer,
> > "color balancing" so to speak has to be done with respect to both the
> > brightest and darkest part of the image, along with setting the L
> > values.
>
> I don't see it as much different, but this is because Argyll doesn't
> use the chromaticity of the black point in its perceptual gamut mapping
> (other software may do this though). Instead it assumes that the
> observers sense of neutral corresponds to the chromaticity of
> the media white point, since it is assumed that the image dominates
> their view and hence their state of adaptation. So the neutral
> axis is assumed to be those colors with the same chromaticity
> as the white point. In practice it then "bends" the neutral
> axis close to the black point, so as to achieve a neutral
> looking result over the majority of the luminance range
> with the darkest possible black.
>
This method for the printers works very well. Thank You, Graeme!
>
> > One issue with NOT using "-u" is that even the it8 target shot itself
> > has to be re-white-balanced if it is re-rendered from the raw file and
> > has the non "-u" profile applied. Otherwise the gs00 patch is rendered
> > as neutral (R=G=B) and the rest of the image has a yellow cast
> > (because on my target gs00 actually has a slight blue cast as
> > indicated by the Lab values in the reference file).
>
> Hmm. It's an assumption in my part that the lightest test patch
> is neutral. It's pity the white patch is not neutral in respect
> to the other neutral patches for your test chart then. I guess
> the white point chromaticity could be computed in some other
> fashion that attempts to average the chromaticity of all the neutral
> seeming patches, but for typical paper media, the paper
> is assumed to be the reference white, and usually people want
> the paper background "removed" when they scan documents in
> relative colorimetric mode.
Graeme, I think it's not optimal to tune the system to the whitest patch,
assuming it's true white. The profiler should take real color of the whitest
patch(es) in account. May be, the true device white point can be accounted not
only by one whitest patch, but by a couple of patches at the top of target
gamut, even by not neutral ones. IMHO, it will be more correct, than the
present approach.
>
> The test chart's XYZ reference values
> are relative to the illuminant used to measure them, so naturally
> if the measurement illuminant is normalized to D50, and D50
> is used as the white reference (which it is with ICC PCS),
> then a neutral (ie. spectrally flat) test patch value
> will have a chromaticity of D50.
The profiler should be more flexible and should compute true white even in case
of absence of the spectrally flat patches.
Another point of view: If the RAW camera data are not white-balanced and have
equal per-channel gain, the camera can capture more of bright colors, than been
white-balanced and clipped by changing per-channel gain. When we cut-off
channels by white balance or by the classic profile, we are cutting off the
camera gamut and some of colors. The colors, which was not saturated in
original RAW, became saturated in resulting image.
I think, there may be another approach to convert the full RAW channels ranges
without clipping the channels by white balancing. It's necessary to do the
profile with imaginary white point, which is higher than real white point
determined by classical target, but matches the real white point in the
xy-plane for purpose of white balance. The imaginary white point must be
selected as high as needed to not clip the device channel values while
obtaining the correct white balance. With such approach we can preserve the
whole camera gamut without clipping. The target white became gray at the
profile output, and the bright colors (with comparable to the target white
brightness) can be preserved.
What we can do with image and "gray" real white point? I've wrote here:
//www.freelists.org/post/argyllcms/Optimizing-contrast-to-fit-source-gamut-into-device
With combining high imaginary white point and auto-contrast gamut optimizing
feature, it's possible to preserve and map to output profile space all of the
captured colors without camera gamut degradation.
I've done the camera RAW profiles with adding perfect and high white point data
while scaling down the camera data to not clip it. If the shot was taken
without RAW channel clipping, the whole camera gamut is preserved by such
method. The problem with brighter-than-white colors arises, but I think, it may
be solved buy properly gamut mapping.
Other related posts:
