[argyllcms] Re: perceptual black too light
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Wed, 15 Feb 2006 13:55:40 +1100
Gerhard Fuernkranz wrote:
One of the things I noticed a while ago is that this rule is probably
not as iron clad for additive devices. One issue that I don't think is
tackled in many (any ?) current profiling packages/CMM's, is that
when attempting absolute colorimetric to an additive device, it's
probably not the best idea to map the L ranges and then clip the
colors - your white point will get badly clipped if the white points
differ. The source space should really be scaled in L to fit within
the gamut of the destination in this situation.
On the one hand, absolute colorimetric should basically also preserve the
luminance,
It depends on whose definition of "absolute" you use. In the original
meaning of absolute, yes. But the ICC used a modified definition,
meaning "not media relative", rather than real absolute. There has
been some attempt to clean up this confusion of nomenclature in
recent ICC specifications. In practice I imagine it would be unusual
for someone to be looking for absolute luminance reproduction based
purely on the contents of an ICC profiles, so by "Absolute colorimetric"
I'm assuming the ICC definition, which means preserving the absolute
hue of the white point. Presumably luminance matching would be
achieved by other ends (display calibration).
> but on the other hand I fully agree that the clipped src white on
the destination device is definitvely the worse evil, and more nasty, so
scaling down the luminance sounds very reasonable (cheating and "bending
near white", is IMO rather not an option for colorimetric intent, where
colorimetric accuracy for _all_ in-gamut colors is important).
However, IMO this luminance scaling is rather an issue to be considered by
the CMM which applies the profile with abs.col. intent, and rather not an
issue for profile creation, although of course a luminance scaled wtpt tag
or scaled chad tag could be recorded in the profile as well. But at profile
creation time, the other profile which is combined later with the own one is
not yet known.
Yes it's a CMM problem, but then in the "dumb CMM" model, this makes it
a profile creation problem. In the end it doesn't matter - it's a gamut
mapping problem, that has to be implemented somewhere.
For this reason, I think that for softproofing a D50 illuminated print on a
monitor with a different white point (e.g. D65), the illuminant relative
interpretation of ICC-absolute intent (as it is now clearly defined in
recent ICC specs) is more appropriate than the traditional interpretation of
absolute colorimetric intent, which preserves XYZ unchanged.
But as far as I can tell, this doesn't differ from relative colorimetric
intent.
> Sure, such a
softproof is not suitable for a side-by-side comparison, but it should
result in an approximate appearance match, for an observer which is adapted
to the native monitor white. Notice, that the ICC assumption is basically,
that the observer of a reflective print is adapted to the _illuminant_ and
not to paper white,
I can't buy that in reality. If you are not looking at the illuminant itself
(which you aren't likely to do if you want to see anything), then
the illuminant has no effect on your adaptation unless it is reflected
off something. The thing in your primary field of view is the print, so
you're going to adapt a lot to the color of the paper.
I have a proof of this. Every Thursday one of the newspaper here prints
a TV guide on light green newsprint paper. It has color photo's in it. The
paper color is XYZ 48.9 54.1 38.9 (D50 Lab 78.5 -8.47 7.17) and is
obviously green. The photo's look fine. Subjectively, highlights
are "white". One page 3 is a picture of Turin, Italy, and
the snow on the alps looks white. One adapts to the white point
of the paper quite well, even though the illuminant white point
is definitely not green.
> while the observer of a monitor is approximately adapted
to monitor white. Thus an illuminant relative transformation from D50 to
monitor white makes IMO sense, in order to emulate the apperance of the
paper color on the monitor for a softproof.
My analysis (which I commented on on the Lcms list a while ago)
is that this change in the ICC spec. is not well founded, and I can't
see it being helpful. In the softproofing situations I'm aware
of, people really do want an absolute white point (and luminance
levels too, if possible) match, so that they can compare directly
to hard proofs. Making display profiles have an ICC absolute intent
that operates identically to relative colorimetric doesn't do this.
Having a CMM link mode that scales the L to avoid white point clipping,
would aid this. In practice that means that anyone currently doing
softproofing needs to use calibration to adjust the white point of
their monitor, in which case relative colorimetric will suffice.
The downside is that you can't switch between proofs of prints
with different paper stock colors, without changing the calibration
of the display.
But what happens if not a device link, but a device profile is being
created? A device profile does not map the src device space to the dst
device space, but the B2A0 table needs to map _PCS_ to dst device space. And
in the PCS, the perceptual gray axis seems to be generally assumed to be
[0,0,0]..[100,0,0] (except for V4, where the reference medium defines a
non-zero perceptual black point in the PCS). Thus, if the src profile
specified with "profile -S" has a skewed gray axis, and the dst device being
profiled inherits this gray axis direction, doesn't then the PCS gray axis
[0,0,0]..[100,0,0] map eventually to the skewed perceptual device gray axis
inherited from the given src profile? Or how do you actually split the
transformation from the src profile gray axis -> dst gray axis into two
sub-transformations src -> PCS and PCS -> dst (where only the 2nd one is
recorded as B2A0 table in the device profile being created).
I haven't tested this very much, but I don't think that there's
a problem (and in fact that the new scheme eliminates the problem you
mention above, which I think exists in current version.) Because the
source grey axis is just a point of reference, any reference is
equivalent. So [0,0,0]..[100,0,0] will also (essentially) be preserved
in the output. The only caveats are the slight shift due to any
CIECAM white point differences (which is mostly undone by the
rotation in Jab space), and the fact that the transform
is less well controlled away from the source profile grey axis
which is actually being used as the 3D mapping reference.
That's what I had basically expected, granted that the BP does not deviate
too far from neutral. And I guess, a deep, dark black is generall desired.
My first round of testing (which I think now was buggy), indicated that
there
were hue shift artefacts at the black end. Now that I've fixed various
bugs, I'm not seeing that defect anymore, so it does seem to give the best
overall result. Now I'm back to looking at the rspl smoothing factors,
that, in light of the bumpy CMYK gamut surfaces I'm seeing, seem too
low in the V0.53 release (I notice now Gerhard, that you were using
"profile -r3" in your example a little while back, which is consistent
with what I'm now noticing.)
Graeme Gill.
Other related posts:
