I’m having a further go at sorting the confusion you mention @mikesan.
Following @gaaned92 's post, I thought you were going to try the latest RT. What happened? Are you still not able to set an RGB print profile as the output profile?
[quote=“mikesan, post:19, topic:3280”]
when I place several color pickers on various patches [/quote]
and so on. Surely what you’re observing by eye is correct, i.e. no change. An output profile defines what system of numbers will be used to represent your image, but it does not alter the actual colour that is represented. So an image output as 2 files, sRGB and ProPhoto, will contain different numbers, but viewing them (with profile-aware software) will give the same picture.
I was just experimenting with lockable colour picker, since numbers are changing for @mikesan but not for @T70. In general preferences, you can set whether the histogram shows working profile values or not. If ticked, I find picker values are independent of output profile, which makes perfect sense to me. If unticked, I find the values change dep. on output profile. Also seems very reasonable to me. So @mikesan, I think most of what you are observing is ok!
I think Rawpedia is a little misleading when it says “If you want to adjust an image for printing and you have an ICC profile for your printer-paper combination you could set that as your output profile, enable “Black point compensation” in Preferences so that the blackest black in your image will match the blackest black your printer-paper combination is capable of reproducing, then enable soft-proofing. You will see what your image will look like if you print it.” It seems to me mentioning you could set the print profile as output is not relevant - RT will show what the printed image will look like just dependent on Preferences.
re. [quote=“mikesan, post:10, topic:3280”]
Soft-proofing, as I understand it, is an editing process that allows one to produce a print matching (as closely as possible) the image seen on your monitor.
[/quote]
I agree with this up to a point, and sure colour management includes seeing the same colours on screen as are printed. But remember the gamuts of screens and printers are rather different, so sometimes the whole point of soft proofing will be to sort out how you want your very punchy photo blazing out of your wide gamut monitor to appear when it comes out of your relatively dull printer. That is, you don’t want screen and print to match, something has to give, and you can choose what that will be.
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.
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.
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:
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 :
the initial color space (PCS ?), which is Lab when the image is fully computed, just prior to any color conversion. This define the characteristic by which a color is represented
the Working profile (e.g. AdobeRGB), which is a profile used by some tools for gamut handling (e.g. Chromaticity) at their very own step. This represent a limit (gamut) in the color space.
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 → 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. (??)
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:
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:
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…
@Carmelo_DrRaw - thanks! I suspect your interpretations of the CMYK and the RGB are exactly right.
You are exactly right that the gamut warning is good for checking for out of gamut colors in the destination color space with respect to the image colors in the source color space. But LCMS internal soft proofing code has issues with generating correct gamut checks, having to do with things like unbounded and high bit depth linear gamma color spaces.
Marti has indicated that bit depth and “gamma” issues have nothing to do with soft proofing to a printer profile from a perceptually uniform color space. And of course this is true by definition. But again, that stance doesn’t solve the user problem of making accurate gamut checks to use when making editing decisions and decisions about output RGB color spaces (whether for display or for further editing in another image editor).
This is one reason why I’ve been asking what the source color space for soft proofing really is in RT. Apparently it’s CIELAB, in which case hopefully the “linear gamma issues” associated with LCMS soft proofing won’t come into play.
In any event, your soft proofing code also seems to generate better gamut checks than LCMS gamut checks. I say “seems” but I mean “does”, at least for all the cases that I’ve checked.
Could RT be improved by allowing other profiles, e.g. RT_sRGB, to be set as the soft-proof profile in Preferences, hence achieving a more general “gamut warning” rather than just a print profile indication? And rename it in Preferences to “Gamut Warning” rather than “Printer (Soft-Proofing)”.
(Side note - I’m reminded just looking at this that the tool tips for the soft-proof icons refer to output profiles, which of course is not how RT works. I’m guessing that at some point printer profiling was intended to be based around output profiles, and then things moved on.)
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).
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.
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.
Yes.
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.
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).
(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.
.
.