Does soft-proofing work without looking to the output profile?

[Hombre (Jean-Christophe)]

@Elle

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?

That’s right. And we use an CIELAB profile as input profile ( RawTherapee/rtengine/improcfun.cc at dev · Beep6581/RawTherapee · GitHub )

@Elle

Is the above something that RT does? Or LCMS internally?

LCMS internally.[quote=“Elle, post:35, topic:3280”]
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?
[/quote]

I guess it doesn’t. If the printer provide an RGB color profile while it uses CMYK inks, it means that the printer will do the conversion to CMYK itself, but the RGB profile is still relevant. However the softproofing will be suboptimal. LCMS can use an CMYK profile for soft-proofing, given that it convert the data back to RGB through the monitor profile (all in a single function as a developer P.O.V.). I don’t know if some color profiles can embed dual color space profiles, as I’ve read somewhere that some color profile could be flagged to be “for soft-proofing”. I can’t really be affirmative, I haven’t looked that out. If RT would support CMYK output data, we could set CMYK printer profile as output profile to send to the print service, but that’s not the case yet (and is not planned).

@Elle

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?

This is the standard Monitor profile that you have to use even without soft-proofing to have correct colors. It still have to be used in soft-proofing mode. That mode only add the printer profile in the conversion chain, but the last step of the CMM will always be the Monitor profile.

@Elle

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?

I’ll type Marti’s soft-proofing chain again, simplified :

RGB Input image → RGB Input profile → RT processing in RGB → [RGB → CIELab] RT processing in CIELab → [CIELab → CMYK or RGB] Proofed printer profile → (computing out of gamut map) → Proofed printer profile [CMYK or RGB → CIElab] → Monitor profile [CIELab → RGB] → RGB display

The bold steps are done by LCMS at the end of the chain. Steps in brackets are color space conversion, with my understanding of Marti’s explanations.

In fact RT can switch to XYZ color space as well during processing, but I wanted to keep it short.

@Elle

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?

Yes.

@Elle

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.

According to your comment (and extrapolated), RT should convert from CIELab to the Working Space, then the Output profile, then the Printer profile, then the monitor Profile (some of them done by LCMS). Am I right ? We could add the Working space to the actual chain, so you’ll be able to select a restricted space, but not the output profile. The Working space should also be optional, because some output profile (like ‘aces’) are wider than all the proposed Working space (I suppose). We should offer ‘aces’ as working profile, but that not planned.

@Elle

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.

So basically what you’re asking for is using the soft-proofing feature to simulate the output profile and not any printer profile ? And the possibility to cumulate both ? I could add a second “soft-proof” button next to the existing one. The first one would be for the output profile, the second one would be for the printer profile. I don’t think we’ll be able to ask for out of gamut pixels for both profiles. If both buttons are pressed, you’ll have the printer profile gamut, otherwise the gamut of the pressed button (i.e. output profile OR printer profile).

@Carmelo_DrRaw

in other words, if the goal of soft-proofing is to check if the image colors fit into the output gamut, then the gamut warning is way more accurate and intuitive than a soft-proofing setup. On the other hand, if the goal is to “see how the image will look once printed on a specific paper”, then soft-proofing is the way to go. However, in this case one most likely needs a wide-gamut display that covers a large fraction of the printer gamut, and additional options in the soft-proofing set-up. The “simulate black ink” and “simulate paper color” that are included in PhotoFlow’s soft-proofing code are exactly meant for this…

(oh man, why do I hate this competition world…?)

The gamut warning has to be done with soft-proofing enabled if you want to see out of gamut pixels from the printer rendering, otherwise you’ll see the out of gamut pixel of whatever else color space.