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

Hmm, yes, no, maybe.

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:

  1. 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.
  2. 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:

  1. From the camera input profile to whatever RGB working space I want to use.

  2. 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.

  3. 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.

  4. 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.

EDIT : see issue #3781.

@Hombre - thanks! for opening the issue on GitHub. Your summary of the issue is clear and concise (and I wish I had your writing skills).

This makes sense to me.

I opened issues for DCI-P3 and ACES inclusion:

I see two common use cases, and I will not use the word “proof” to avoid the semantic politics:

  1. 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
  2. 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.

@jdc might know.

:thumbsup: