[argyllcms] Re: perceptual black too light

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 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 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.)

I fully agree, that a skewed gray axis from the device WP to a non-neutral BP is rather not desired (and as you know I was also one of the people who did complain about this behaviour on previous versions). But why is it better to inherit the gray axis direction from a given source profile? If the source profile is a working space like sRGB, then it's gray axis is indeed not skewed, but what if the src profile already has a skewed gray axis from WP to a non-neutral BP? Wouldn't then the device profile I'm generating again inherit a skewed gray axis? 

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'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. ]

Graeme Gill.




Other related posts: