-->To comment on my question: Yes, those silent assumptions exist, but ... “That is closely held secret by GMB. Likewise with Monaco/X-Rite. The color space assumptions in ProfileMaker differ based on the parameters used when the profiles are construed.” (by Ethan Hansen).
If anyone knows more, please post.
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). The conversion takes place like this; working space (let’s say sRGB for one file, ProPhoto for another) converted to LAB by the CMM. That’s the device independent color space used by the PCS. LAB to output profile now takes place. So the output profile has no idea if the LAB data came specifically from sRGB or ProPhoto RGB. Yes, the data is different for obvious reasons and yes, with some imagery, the smaller color space CAN be somewhat beneficial. But the CMS as yet has no provisions to know this. The output profile is simply getting LAB values to work with.
The opposite is the case with device links. I’ve never seen one that works RGB to RGB but haven’t really looked or tried to build an RGB device profile since I don’t know what that would bring to the party (and Photoshop and many other ICC aware applications can’t handle Device Links). But with a device link, the advantage is you can produce a CMYK to CMYK conversion without a trip into LAB; there’s no PCS in the process. This is useful when doing CMYK to CMYK conversions because you can retain the black generation. When you do this using ICC profiles, there’s a trip into LAB, the black generation is hosed. So with device links, there’s a direct relationship between source and destination but for a specific reason.
-->Today’s printer resp. printer profiles are not prepared for the case the we come along with a heavy-loaded file in ProPhotoRGB.
I don’t see it that way. It really doesn’t matter. The printer has a fixed gamut. The original data has a fixed gamut. You want (or maybe you don’t want but I do want) all the color the capture device was capable of producing. Printer A may be able to use 80%, printer B may only be able to use 60%. That’s just the facts of life and you either have a source space that contains the colors or you don’t. This isn’t going to affect the printer; a smaller source isn’t going to allow you do reproduce any more colors (only less). So I don’t see why originally containing less colors versus more is any way a factor here.
-->The mantra "use ProPhotoRGB to avoid channel clipping“ is akin of self-fulfilling prophecy, because ACR doesn’t support any other rendering option (yet). Hence, all the burden of a perceptual de-saturation is imposed either to the operator or to the printer profile….
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. If you’re asking for some kind of protectoral option, I guess that’s reasonable and I don’t know enough to say if that’s doable or useful. But the facts are, we have capture devices that can produce a very wide gamut of colors and tones we probably can’t output today and maybe never will.
-->Could the industry please kindly sort this out without involving us customers. Not everyone loves to fiddle with the Hue&Sat.-tool or the Channel Mixer to tame out-of-gamut colors.
Out of gamut colors are a fact of life and users need to decide how they wish to handle them. There is no one-size fits all conversion. That’s why we have different rendering intents, soft proofing and tools like Photoshop to attempt to produce a reproducing on a smaller gamut, lower dynamic range output device to fit our idea of what the image should look like.
We’ve never been able to reproduce the gamut and range of a transparency on print but that didn’t stop people from making beautiful representations of the film for years.
-->“Devices such as digital cameras and printers perform embedded (typically proprietary) perceptual renderings to and from standard color encodings like sRGB.
I’m not sure what that brings to the discussion. I suggest you read the white paper there (which I co-authored) which discusses the processes of in camera rendering and encoding. http://www.color.org/ICC_whi....ics.pdf