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.
Unbounded ICC profile conversions have made the concept of the source color space gamut somewhat suspect. I’ve asked about RT “clipping” from various internal ICC profile conversions, but so far if there has been an answer, I don’t remember what it was. Is there clipping when the image is converted from the camera input profile to the RT RGB working space (there used to be)? Is there clipping when converting back and forth (how many times is this conversion done?) between the RT RGB working space and RT’s CIELAB profile?
Anyway, in times past, the image color gamut was automatically no greater than the gamut of the color space in which the image was encoded. This is still the case with integer precision editing. But it isn’t the case when the image is at floating point precision unless the image editor is doing some clipping behind the scenes or using ICC profiles that don’t support unbounded conversions.
The RT-provided output profiles (used to - still?) have point TRCs, which automatically clip upon conversion even at floating point, and of course clip upon exporting to disk at integer precision. I don’t know what RT uses as the equivalent internal working spaces - do the built-in working spaces use point curve TRCs?
In the case of soft proofing at floating point precision when the source and/or destination color space (and file format, for exporting to disk) support unbounded conversions, the source color space gamut doesn’t really matter any more. The relevant question becomes “how to fit the image colors into the destination color space”.
Also one needs to know whether the user is really interested in the bounded or the unbounded destination color space? Not all TRCs that support unbounded profile conversions actually support negative RGB channel values. Converting to a true gamma profile other than a linear gamma profile does clip negative RGB channel values. And if the user’s goal is outputting in a file format that doesn’t support unbounded RGB channel values, then the user is interested in the bounded (clipping all out of gamut channel values) color gamut even if the chosen output color space does support completely unbounded profile conversions (sRGB does if the TRC is a parametric TRC).
For RT, another relevant question is "how do prior conversions and processing starting with the camera input profile affect the colors that survive all the way to CIELAB, where the soft proofing process begins? In other words, how much does the RT RGB working space choice matter?
From a user perspective, when soft proofing to a user-selected output profile, which might or might not be a printer profile, immediately there are two gamuts to consider:
The image color gamut -which thanks to LCMS’s very useful unbounded floating point profile conversions - might or might not be confined to the color gamut of the color space the image is encoded in, depending on the precision and the image color space profile.
The color gamut of the destination color space.
And then there’s the implicit 3rd color gamut, which is the color gamut of the monitor that’s being used to soft proof the image. You can’t see colors your monitor can’t display, even when the monitor is being used to emulate a printer/paper combination. But you can see gamut checks.
And then there is the fourth color gamut, which is the RT working space, the effects of which on the image color gamut haven’t (as far as I can tell) been addressed - does the user’s choice among the RT RGB working spaces already clip any input colors that might exceed the bounded RGB working space?
So there’s the fifth color gamut: the color gamut of the input image, which for raw files is determined by the camera input profile (and the scene that was photographed). So what about soft proofing from the camera input profile to the RT working space?
I’m no longer even sure what the OP for this long thread wanted to do. I think he wanted to know two things:
Do all the colors in his test chart fit in a given RGB output profile?
If so, when he saves the image to disk in the given RGB output profile, what would be the result of soft proofing from the output RGB color space to the printer profile.
So if this is what the OP wants to do, this really is stacking two different soft proofing “chains”: From RT’s CIELAB to the user-chosen RGB output profile, and then from the RGB output profile to the printer profile. Whether or to what extent RT should make this double-chain soft proofing easy, I guess that would depend on what various RT users would find useful.
Personally I "soft proof/gamut check/whatever you want to call it to avoid being told ‘that’s not what soft proofing is for’ " at several points in my workflow:
From the camera input profile to whatever RGB working space I want to use.
From my chosen RGB working space to my monitor profile (selecting the monitor profile as the soft proofing profile), just to get an idea of whether I’m editing/creating colors I can’t see.
Sometimes I change RGB working spaces, especially if I’m starting to work with colors I’m significantly modifying from what the camera captured (I use linear gamma Rec2020 for most image editing, but I use a custom working space for painting and recoloring), and so I soft proof from the first RGB working space to the second RGB working space.
When I’m done editing I soft proof to sRGB for the web and also to a couple of printer profiles.
I did this kind of “sequential soft proofing” way back when I used Windows and PhotoShop (except at that point I didn’t have any custom camera input profiles, and so soft proofing from the camera input profile to an RGB working space wasn’t an option), and I find it a bit frustrating that the same sort of soft proofing is not very easy to do using free/libre software.
There is no competition. The PhotoFlow soft proofing code very nicely sidesteps the very real restrictions on getting accurate gamut checks and soft proofing from the LCMS soft proofing code. The PhotoFlow soft proofing code works even in situations where unbounded high bit depth floating point linear gamma profiles are being used as the source and also possibly the destination color space(s). The code is free/libre/open source. If anyone wants to use the code, it’s there for the testing and taking and improving. That’s one of the nice things about free/libre software.
I don’t think @Carmelo_DrRaw is suggesting that people drop RT and use PhotoFlow instead. I think he’s saying “here is some code that answers some specific soft proofing problems, and maybe RT might benefit from incorporating similar code”. Personally I would like to see the same sort of code incorporated into GIMP. I’d like to see the same functionality in all free/libre image editing software because soft proofing is an essential part of image editing work flows.
Elle was quicker than me to provide this answer, but she is 100% right! We have spent a couple of months of trial-and-error tests and code improvements in order to build something that seems to be reliable and correct in all situations, and that can be used to check the output to a printer profile as well as a standard colorspace like sRGB.
Since we are all using the same LCMS framework for color management, the code should be relatively easy to adapt from one software to the other. And I’l be happy to give detailed explanations if needed…
@Elle Doing what you’re asking for require a CMM tab next to the History panel. That was planned but not started yet. Now that’s I’m lowering my contribution level, someone else will have to do that. Adding the output profile in the profile chain should be doable without this tab. I’m opening an issue on GitHub.
I see two common use cases, and I will not use the word “proof” to avoid the semantic politics:
User wants to see what the image will directly look like if it gets saved using some output color space and rendering intent,
e.g. sRGB/perceptual (squashing all the colors into sRGB).
e.g. JapanColor2003WebCoated.icc/relative colorimetric.
The output color space could be a printer color space.
The color pipeline would be: RT working space > RT ouput space (could be printer) > Monitor profile
User wants to see what the image will look like if it gets saved using some output color space and rendering intent and then subsequently will be printed.
e.g. saved to sRGB then sent to a printer which uses JapanColor2003WebCoated.icc/relative colorimetric.
The output color space would not be a printer color space.
The color pipeline would be: RT working space > RT output space (not printer) > RT printer space > Monitor profile
Basically step 2 is a shortcut so one does not have to save the raw image first to TIFF using a typical output space like sRGB and then having to open the TIFF and set the printer space as output and view what that would look like.
.
.