[argyllcms] Re: perceptual black too light
- From: "Gerhard Fuernkranz" <nospam456@xxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Wed, 15 Feb 2006 00:39:15 +0100 (MET)
> --- Ursprüngliche Nachricht ---
> Von: Graeme Gill <graeme@xxxxxxxxxxxxx>
>
> Gerhard Fuernkranz wrote:
> > I guess it is not completely WP relative be cause of the incomplete
> > adaptation (D factor != 1) in the CIECAM model? Might it make sense to
> > force D=1, instead of computing it from the viewing conditions, for
> > intents which are supposed to map src WP -> dst WP? Would this probably
> > result in perfectly aligned WPs in Jab space, without need for further
> > alignment?
>
> It's a good question, and a reasonable suggestion.
The idea is, if we want to align the WPs anyway (e.g. -i2, -i3, -i4), then
why not let the chromatic adaptation of the CIECAM model do this job (if it
works?), instead of performing a rather heuristic transformation such as a
rotation in CIECAM space (though the difference is likely not too large, for
only small WP differences).
However, for your "absolute appaearance" intent, I guess it's likely not
intended to map the src to dst white point, but to retain dst_Jab = src_Jab
unchanged. But as a consequence, the white points are not guaranteed to
match. Since in this case src white is usually out of gamut on the dst
device, it cannot be reproduced correctly anyway w/o clipping. So it might
be indeed reasonable to cheat a bit and to "bend the white end", such that
src white nevertheless maps to dst white, as you say below. Only a subset of
colors near white is affected, while a majority of all colors are still
retained with dst_Jab = src_Jab.
> The general expectation
> for all the subtractive devices is that it is critical to make 0 0 0 0
> map to 0 0 0 0 (unless you're simulating a background color) to avoid
> the dreaded "scum dot", but whether this is best done by modifying the
> whole colorspace, or done by "bending it at the white end" is a question
> that's crossed my mind as well lately. (The -w option in icclink just
> tweaks the white grid point in the device link lut, but this is meant
> for fine tuning a background simulation.) A similar approach could be
> taken to what I'm doing at the black end, but I'm not sure I want
> to explore that at the present time.
>
> 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, 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.
> On the other hand, since a display usually doesn't display one
> image at a time, it doesn't really work visually to try and display
> an absolute colorimetric image surrounded by windowing system
> decoration that's displayed with the native color space of the display
> (hence the preference for using display calibration to set display
> white points.)
Agreed, all the other native monitor color space objects on the screen
definitively disturb the adapted whitepoint of the observer, making the
abs.col. softproof (e.g. for a D50 print on a D65 monitor) more or less
useless.
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. 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, 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. Likely your "absolute
appearance" intent would be even superior for this purpose, if D50 (not
paper white) is chosen as src WP, and monitor white is chosen as dst WP,
because CIECAM models not only the chromatic adaptation (as it does the
illuminant-relative interpretation of ICC-absulte intent), but it
additionally models other differences between print and monitor viewing
conditions (-> on a monitor under sRGB viewing conditions, an image must be
rendered approx. with gamma 1.1-1.2 darker to achieve the same appearance as
on a reflective print - which is of course not taken into account by a
colorimetric softproof).
> [...]
> Yes, but the source grey axis is just a point of reference, meaning that
> the maintaining of the skewed neutral axis should (presumably) maintain
> the reproduction of the "true" source grey axis (whatever you want that
> to be) as well.
I understand. So for a device link, I see not a big problem. The lightness
scaling on the skewed src gray axis will give a small shift of a and b, but
that should not be too much. And after the lightness mapping and aligning
src and dst WP, both, the src and dst gray axis have the same direction, so
no additional transformation of the gray axis takes place.
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've actually been playing with the "bend to the destination
> black point at the end" mapping again today, as it gives a
> deeper black point that relying on clipping, and so far,
> this doesn't seem to have a visible effect on the bulk of
> the neutral axis hue. ]
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.
Regards,
Gerhard
--
Gerhard Fuernkranz
nospam456@xxxxxx
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
Other related posts:
