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