By the time an output profile “gets” data, it’s gone through the PCS and is in LAB. So if I’m understanding where you’re coming from, I'd say again that the output profile has no real idea what the incoming data is as far as the original RGB color space (sRGB, ProPhoto etc). ...
That is correct and completely understood. The final printer/media profile is “ignorant“, but the guys who construed the profiling SW + the implementation of the Perceptual intent are certainly not.
PCS Lab is huge, whereas printer/media profiles are small (deltaE3-wise). If you’d just scale down / compress the whole volume of CIE Lab into such a “poor” output space, all in-gamut colors would get altered and de-saturated in an unacceptable way. Therefore a nifty non-liner algorithm for compression is required.
In this context an assumption about the most likely source space is made (could also be more than one) by these guys. While collecting the colors from PCS Lab, all colors outside the range of this assumed source space are somehow clipped & merged in a RelCol manner. All colors ranging in-between this assumed source space and the output profile are gently squeezed in … AFAIK.
So my initial question was not rhetoric at all. If the Perceptual intent of a printer profile was not prepared for ProPhotoRGB, results are not much different compared to RelCol.
That’s at least what I see when working with quite saturated colors in a large working space. In both cases, Softproof as well as print show a lack of details due to posterization (unless some time is invested to tame these out-of gamut colors).
There’s only one rendering intent (actually one table, two intents) you can use with matrix profiles (Adobe RGB (1998), ProPhoto etc) and that’s colorimetric. ...
That is correct, but can be misleading. It is the reason why I added above reference to ICC White Paper #2 http://www.color.org/ICC_whi....ses.pdf
(of course I know yours, too).
A proprietary color management system (CMS) can / could anytime realize a Perceptual compression between two matrix spaces, such as the input profile of a Camera and the preferred output space like Adobe RGB. In all probability, that’s what happens “in-camera” when you shoot sRGB/aRGB/JPEG/TIFF … AFAIK.
I see no restriction in principle why a Raw converter shouldn’t offer such a perceptual rendering option (optionally). Minor tradeoffs would be acceptable if this saves me time. Current philosophy of “preserving everything in ProPhotoRGB” leaves the whole down-sizing / de-saturation to the operator or the printer profile. And here we are moving in a circle………
However, maybe we can develop something practical here. Would you have a suggestion how to deal with said out-of-gamut colors prior to print?
/> De-saturation by means of the Hue&Sat.-tool (in RGB mode) reduces brightness, too.
/> De-saturation by means of the Hue&Sat.-tool (in Lab mode) changes the hue.
/> The Channel Mixer was recommended elsewhere, but I'm not sure how to use it properly for that purpose.
Any “best practice” how to proceed?