So again looking at the soft proofing chain in LCMS:
Based on what you say, it looks like in RT the image is already in CIELAB when RT hands the image off to LCMS for soft proofing, yes? So LCMS might or might not do a NULL conversion from RT CIELAB profile to LCMS CIELAB profile?
And then LCMS does a conversion from CIELAB to the printer profile that the user has specified as the soft proofing profile. That brings us to this point in the chain:
Input image → Input profile → CIELab → Proofed [printer] profile
I’m not sure how to interpret the next steps in the chain, from the Proofed printer profile to CMYK to again Proofed printer profile and then back to CIELAB:
Proofed [printer] profile → CMYK → Proofed [printer] profile → CIELab
Is the above something that RT does? Or LCMS internally? How does CMYK get into the soft proofing chain if the printer profile is an RGB printer profile, as is likely the case with today’s photographic printers?
And I’m not clear about this part either:
CIELab → Monitor profile → RGB
The monitor profile already is an RGB profile as monitors are RGB devices, so what RGB profile is being used as the last “stop” in the soft proofing chain?
My apologies, I find this soft proofing chain of conversions very confusing. I’m not sure where the conversions explicitly done by RT leave off and the conversions done by LCMS as part of the internal LCMS soft proofing algorithms take over. Could someone please clarify? Maybe there is a typo in the quoted chain somewhere? Or maybe I’m somewhat clueless about how soft proofing is supposed to work?
In any event, it looks like what happens in RT is that the image that is sent to LCMS for soft proofing really is already in the CIELAB color space, yes?
It really does matter what color space the image is in when it’s sent to LCMS for soft proofing.
-
If the user’s workflow is to soft proof to the printer profile and then output the image in the printer profile to be printed by some other application besides RT, then that is one thing.
-
If the user’s workflow is to output the image to disk in some user-chosen RGB working space, with the intention of then printing the image using some other imaging application, then soft proofing in RT seems like, well, wasted effort, as the RT soft proofing chain does seem to start with the image in the CIELAB color space instead of in the user’s chosen RGB output space. And there is no guarantee that colors in the essentially infinite color gamut of CIELAB won’t be clipped by being saved to disk in the user’s chosen RGB output space.
I absolutely understand that Marti isn’t interested in using soft proofing techniques for figuring out whether the colors in an image in color space A (apparently CIELAB for RT) will fit into an RGB working space such as sRGB or AdobeRGB or Rec2020 or whatever.
That leaves people who want to output an image from RT in any given user-chosen output profile - without clipping any colors - with something of a problem. We might not be “allowed” to call it soft proofing if the destination profile isn’t an actual printer profile. But telling us that soft proofing isn’t meant to solve this particular user problem with mismatched source and destination color gamuts, doesn’t provide us with solutions to the very real problem of choosing an output color space that won’t result in clipped colors, before we actually save the RT-processed image to disk in a user-chosen RGB working space.
I think the PhotoFlow code mentioned in this post does a pretty good job at addressing the problem of mismatched color gamuts, even when the destination profile is not a printer profile: How soft-proofing is implemented in PhotoFlow