[argyllcms] Re: Profile input white not mapping to output white
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Thu, 29 Nov 2012 09:59:43 +1100
Ben Goren wrote:
Hi,
> That's what the RAW software already does, but Argyll is unaware that it's
> happened and
> basically attempts to re-apply that same process. Furthermore, RAW software
> is designed
The processes are in the wrong order. Convert to color managed space,
then select white point. Anything else is fairly crazy (how can you evaluate
the image in an unknown device specific space ?). The RAW converters need
some re-jigging to be color managed. Clipping colors above the white point
in a chromatically consistent manner is something that should be done
right at the point the white point is set, not some time afterwards.
[ie. it seems to me that you are trying to patch up some fundamental
issues with the workflow, and this is not a good long term strategy.
Better to fix the workflow, if possible.]
In any case, I don't want to do anything unexpected - the absolute colorimetric
response is meant to faithfully represent the device behaviour, not be
perceptually
processed in anticipation of one particular workflow. You can in principle
take the profile from Argyll and re-process it (or use it) in a manner that
does what you want, but you can't do the reverse - you can't take a profile
that clips above the white and undo the clipping, since the information is gone.
> to align the channels such that everything that's spectrally flat should when
> it's done
> already have equal RGB values, at least for whatever's lit by the
> (impossible-to-guess-after-RAW-development) illuminant the RAW software used
> for the
> scene.
I'm not sure I follow this. Why is a spectrally flat sample of much
importance ? The viewer won't adapt to a spectrally flat white unless
it's present in the image. They will adapt instead to whatever appears to
be white, something that is impossible to accurately quantify (being
a complicated visual and cognitive process). It can be approximated
by various algorithms (which is good for mass processing of images
and a first cut), but for the best results really needs to be done manually.
Setting a white point for an image on capture is done for two reasons,
both driven by the output referred nature of most reproductions:
1) To maximise the quality of subsequent media renderings. You get the best
brightness and color vividness if the white of the image is close
to the white of subsequent media.
2) Because often the media color is visible in subsequent
renderings, forcing the viewer to adapt to it (ie. on displays
there will be other white elements, in print there is often
surrounding non-printed media color.)
> However, I can state with great confidence from empirical testing that adding
> the
> synthetic black and white points to the .ti3 and handing it off to the latest
> official
> release of colprof with no processing options results in a profile that's
> both as close
> to colorimetrically correct as I think it's possible to get and visually most
> pleasing
> as well. For the proof, see my previous post with the four images, and do a
> blink
> comparison. The appearances of the synthetic charts and the photographed
> version with
> the D50 white and black patches are almost indistinguishable. Remove the D50
> lines from
> the .ti3 and the charts are instantly discernible even in side-by-side
> comparisons.
I'm sure it helps your workflow. The problem is that it's just one workflow,
and I
think it will severely compromise the usefulness of the profiles to cater for
just that
workflow. Now, maybe it could be added as an option, but I'm very dubious about
mapping 1,1,1 to D50 in the raw data - it would make more sense in your workflow
to map any colors over the media white point to D50 (assuming the media white
point is the white point you want).
> So...on the one hand, the ``right'' answer would be for Argyll to do its
> magic on the
> RAW camera data, but that would mean you'd have to get into the business of
> Bayer
> demosaicing and all the rest -- not something I think you're interested in.
> (But if you
> are, I'll *really* get excited!)
It's on my list of things I'd like to look into (especially if it seems that
many of
the RAW converters aren't properly color managed), but I can't see that
happening
any time soon :-( :-(
> That's why I still think the least-worst answer would to be to add a switch
> to colprof
> that says, ``the input is from a typical modern DSLR that's been through RAW
> processing
> and thus is already white balanced and clipped, so assume that the endpoints
> of the
> gray axis are already where they should be.''
I'll look into a "clip to white point" option. It may do what you want.
Cheers,
Graeme Gill.
Other related posts:
