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.
