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 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
As Iām not involved in the soft-proofing process of RT I only told you about the conversions in pipeline before soft-proofing (the part of your question I quoted in my answer)
My understanding is that CMYK
here indicates the color model of the image data after the conversion, and not an additional conversion. In other words, Marti is assuming that the printer profile is a CMYK profile (which, as you correctly pointed out, is not always the case, as printer profiles can also be RGB).
Then the data is converted back from printer to CIELab.
Again, my understanding is that the last RGB
is not an additional conversion, but just a āreminderā that the output of the conversion to the monitor profile is in RGB space.
Clearly, this view of the soft-proofing chain is very printer-centered, and does not consider other output media (like web publishing in sRGB colorspace). Again, Elle already pointed this out.
Another point that should be made clear is that soft-proofing can be very misleading in some situations, at least unless you have an high-end wide-gamut display. Modern inkjet printers can output colors well outside of the sRGB gamut. So, if you are soft-proofing to a standard sRGB display you will actually never see ALL the colors of your final print. For example, your printer will likely output highly saturated greens and yellows that your monitor is not capable of displaying. In such a situation, soft-proofing is unreliable .
However, there is another tool that can give you good guidelines independently of the display you are using: the gamut warning. This tool usually displays with a uniform solid color (gray for example) the colors that are outside of the gamut of the proofed profile. This can be used as a guideline to further edit the image and bring the over-saturated colors back into the output gamut, if that is what you are aiming for. And the feedback you get is much more accurate that the visual output of a soft-proofing chainā¦
EDIT: 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ā¦