I’m sorry - now i did.
No, absolutely not. No changes in color picker values, when changing output profile, and not when switching soft-proofing on or off. Only image getting brighter, when switching on - but the same “getting brighter” independent of the output profile.
That is indeed strange. The image I am using is one of an X-Rite Color Checker Passport. When I place several color pickers on various patches the values change significantly with changes in output profile. The values are not affected by switching soft-proofing on/off.
As I noted before, my eyes cannot detect any change in the color of the patches when switching output profile. I am using a well profiled and calibrated wide gamut monitor but I can’t say much about my rather ancient eyeballs
I also note that when I turn on the “out of gamut” indicator, several patches show the grey areas (indicating out of gamut). However there is no change in this indicator when switching output profile or, for that matter, no change when switching the printer profile in Preferences>Color Management. The latter is particularly strange since out of gamut indicator should be very dependent on printer profile.
It is possible that altering the printer profile in Preferences does not take effect until the program is closed and restarted. Does anyone know?
hi there. Are you expecting the preview image to change when changing output profile? If so, why?
On my RT (5.0 R1, Ubuntu), the preview changes when I change printer profile; and with no need to re-start RT.
Hi Andrew.
There is still some confusion about how to display a soft-proof image in preview. It is generally agreed that the printer profile must be entered at Preferences>Color Management. There is still some question about what profile should be selected in Color Management tool>Output Profile. RawPedia suggests that the latter should (also) be the printer profile; although with my version of RT (win7 RT-5.0-r1gtk3) it is not possible.
Note, that while the preview image does not change with output profile, when I place several color pickers on various patches, the values change significantly with changes in output profile. Thus it seems clear that the choice of output profile does affect the preview image, in spite of the fact that my eyes do not detect a change.
Hi @mikesan
I have been following this thread, but have been reluctant to join in, because my information on this is only from following the discussions in github etc, not through actual use. My understanding is…
The output profile does not affect soft proofing, it defines the profile that is used for the final tiff/jpg.
Depending on how you are printing, dictates whether you should use the print profile for the output profile.
If you are printing and your print program is responsible for converting to the print profile, then assign an output profile that is larger than the print profile.
If you are printing, but your print program does not let you select your special custom print profile, then set it as your output profile, and make sure your print program is configured to print without assigning a profile.
If you are sending off to a print service online, set the output profile to whatever they say. If they don’t say, then they probably want sRGB.
Just because the numbers are different, doesn’t mean that the colours are different. The same colour is represented by different RGB values for different profiles. From what you describe, it sounds like the colour picker is showing the numbers for the final output file, rather than the soft proofing profile, the working profile, or the monitor profile.
Perhaps @Hombre can clarify?
I’m having a further go at sorting the confusion you mention @mikesan.
hi James.
I am hoping you are correct about the output profile not affecting soft-proofing. As for sending to a commercial printing service, I would not use one which did not provide a print profile that I can use for soft-proof and I prefer those that accept the image converted to their printer profile with my chosen rendering intent.
I think you are correct. Changing the output color space should only change the numbers but not the way the image is displayed. On the other hand, changing the printer profile should result in a change in how the image is displayed in preview; otherwise how would one be able to edit the proof for different printers? Curious why T70 does observe a difference but I don’t.
Well something does have to give. First one has to ensure that the monitor’s gamut encompasses all (or most of) the colors that the printer can produce. This is usually possible with a good wide gamut monitor. If the soft-proof indicates that some colors in your image cannot be reproduced by the printer then one has the option of editing the image to bring it within the printer’s gamut. That, for me, is the whole point of soft-proofing; to accomplish WYSIWYG.
I agree 
Correct, but it depends on the rendering intent, black point compensation and and whether the image contains out of gamut colours, and even then it might be quite subtle.
@T70 The first post of @mikesan perfectly explained how RT works for soft-proofing
@mikesan I confirm that the output profile does not affect soft-proofing. For those who can read the code.
But in RT apparently the output profile isn’t used as the source profile for soft proofing, which seems a bit odd but perhaps useful in the context of overall RT functioning.
Do not think that the developer of the softproof feature (i.e. me) is a master in color correction. That’s why I asked Marty Maria (developer of lcms2) to jump in our discussion in issue 3406. I’ll emphasis 2 things he said :
To implement proofing, lcms as most CMM does this chain:
Input image → Input profile → CIELab → Proofed [printer] profile → CMYK → Proofed [printer] profile → CIELab → Monitor profile → RGB
There’s no place for the output profile in his typical chain, that 's why I’ve done it that way. I’ve first tried to make a double conversion : Working → Output (including change of bit depth) → Printer (soft-proof) → Monitor. Marty replied that bit-depth was part of the hard-proofing process, not soft-proofing.
The second thing is :
BTW, using softproof to preview the effect of working spaces or gamma curves is pointless. The use for soft proofing is to emulate printers. To some extent it may work for other usages, but this is not the goal of this tool.
Gamma curves can be changed to the user’s convenience for the output profile, hence my question to Marty on how to deal with this. his answer is that’s it’s not the purpose of soft-proofing.
Your advice are of course welcome, but at some point I need to see the light in the night of color management 
.
As for the values from the Navigator and the Color Pickers, they are either the one from the Working profile (direct conversion from Lab to Working profile (e.g. AdobeRGB)) if checked in Preferences / General, or the Output profile (direct conversion from Lab to Output profile) if unchecked.
Do not confuse between :
PS : what you see as preview image is a direct conversion from Lab → Monitor profile (if soft-proofing is disabled, of course), so you won’t notice anything when using one or the other option for this checkbox in Preference.
Many thanks for this informative post; even though most of it is beyond my limited understanding of color management. I have taken the liberty of picking through this information and re-formatting it in a manner that I can (perhaps) better comprehend. Please check it for errors of fact and/or interpretation.
Input image (?RGB) → process image using Input Profile → CIELab
CIELab → Monitor Profile (RGB) → Preview Image (soft-proofing disabled)
CIELab → Printer Profile (CYMK / RGB) → CIELab → Monitor Profile → Preview Image (soft-proofing enabled)
CIELab → Working Profile (RGB) → Color picker values (RGB) (option in Preferences / General = checked)
CIElab → Output Profile (RGB) → Color picker values (RGB) (option in Preferences / General = unchecked)
CIELab → Working Profile (RGB) → used by some tools for internal calculation.
Conclusions:
To the extent that my synopsis is correct, it is clear that the Output Profile plays no role in soft-proofing,
If “use working profile” is unchecked (Preferences > General) the values displayed by the color picker, but not the appearance of the preview, are affected by the choice of Output Profile.
If “use working profile” is checked (Preferences > General) neither the values displayed by the color picker nor the appearance of the preview are affected by the choice of Output Profile. However the color picker values are affected by the choice of Working Space.
Alteration to the Printer Profile (Preferences / Color Management) do not affect the values displayed by color picker nor are they changed by enabling / disabling soft-proofing.
Alteration to the Printer Profile (Preferences / Color Management) will affect the appearance of the preview image only when soft-proofing is enabled.
The choice of Working profile does not affect the appearance of the preview image. (??)
Thanks. Now you (or someone) could do us all a big favor by editing the “Monitor and soft-proofing” section of http://rawpedia.rawtherapee.com/The_Image_Editor_Tab#Monitor_Profile_and_Soft-Proofing
In paragraph 2, remove all reference to “output profile”.
Thanks.
And in paragraph 3, could someone please change
and you have an ICC profile for your printer-paper combination you could set that as your OUTPUT profile,
to
and you have an ICC profile for your printer-paper combination you could set that as your PROOF profile,
No! See my previous post, point 3.
Andrew, you are right. I failed to follow my own map. I have corrected that post.
Thanks.
I’ve tried to ask the following question before, and maybe it was answered, so if it was already answered, my apologies!
In Marti’s chain of conversions, the first profile is the input image profile.
When soft proofing using RT, what is the input image profile? Some possibilities are:
Is the input image profile the camera input profile?
Is the input image profile the RGB working space that the user chose amongst the short list of allowed RGB working spaces (eg RT_Large, RT_sRGB, etc)?
Is the input image profile something else altogether, such as CIELAB, which would mean that RT immediately converts the interpolated raw file from the camera input profile to CIELAB for further processing? In which case what role does the RGB working space play?
The interpolated (or not interpolated, in case of pixel shift or foveon) raw file(s) go through some rgb processing where the RGB working space is used. For example tone curves in exposure tool are processed in RGB working space as well as channel mixer, Shadows/Highlights, RGB Curves from Colour tab, Film Simulations (though this get a special processing because clut profile and working profile rarely match) and some other tools too.
After these steps the image is converted to CIELAB and the further processing is in CIELAB space almost up to the end of the pipeline (except you use the CIECAM02 tool, then of course additional conversions between CIELAB->CIECAM02->CIELAB have to be made), where it has to be converted to output profile again.
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
