I don’t think you currently can
RawTherapee has the functionality to preview out-of-gamut colors, but that seems to be limited to printer profiles only - @Hombre ?
There is also this pending issue: Enhancing the CMM module #3781
It looks to me like you have a mixed lighting problem - a 2 fold one. The sellers area is darker and lit by light coming through the canopy. A very simple edit. RT but I resized and sharpened in Fotoxx - just because I always do. I like to see the result of the sharpening in the correctly sized image.
That looks a little flat. Vibrance etc could fix that. Another way that may give better results is to load it into the GIMP. Duplicate the layer and set the new top layer to softlight and then adjust it’s opaclty.
There was @stefan.chirila 's post recently here Help with over-saturated area? and now another one about saturation. I thought using Perceptual rendering should fix, or at least help, with these desired adjustments, so I’ve been trying it, but I’m left scratching my head.
I’ve taken the pic above, and increased the saturation outrageously with the intention of having a start point that is outside of sRGB. I’ve then saved to jpeg with a) relative colorimetric and b) perceptual, both with black point compensation. RT’s working profile was Prophoto. I was expecting the two to be different, but they’re the same.
Rel.Col. first, Perceptual 2nd.
Please can anyone explain?!
I believe monitor profiles are not relevant in this matter.
In addition, I’m uncertain what the under- and over-exposure buttons are showing. Here’s a screen grab showing under exposure. Note that there are areas that are nowhere near black showing up. Could these be out-of-gamut areas?
Finally, it would be great if RT could show out-of-gamut areas for profiles besides printer ones, e.g. sRGB. As a workaround, is it possible to make a printer profile that happens to have the same numbers as an sRGB icc?!
@RawConvert that is EXACTLY what I was saying in my post. Saving with different rendering intents makes absolutely no difference what so ever. I believe it should. Either we majorly misunderstand the purpose of this tool …or it is broken. I’d love it if someone who understands it could explain.
@RawConvert so I must conclude that in order for those differences to show, the eventual output profile needs to be very much smaller than the one worked in. Which still doesn’t quite make sense …since saving in sRGB _ is _ saving in a profile a lot smaller than ProPhoto which RawTherapee works in.
Well very similar yes! but there was also discussion of printer profiles and screen profiles and I think (rightly or wrongly) that complicates things. I thought I’d try the absolute simplest case, sRGB output jpegs…
Converting from the working profile to the output profile using perceptual rendering intent should prevent clipping and should look different than when using relative colorimetric if the profiles have the required conversion tables. Matrix profiles only support relative and absolute colorimetric intent mapping, while LUT profiles can support more. I don’t remember off the top of my head which profiles RT has.
Either this feature is broken, or the profiles are matrix, or the profiles are LUT and lack the table for conversion to perceptual.
As I already said in the other thread, and as @Morgan_Hardwood also stated, differences between relative colorimetric and perceptual intents will show up only if the output profile provides an appropriate gamut mapping table. Matrix profiles DON’T provide such tables, so choosing perceptual intent results in the CMS to fall back to relative colorimetric. I’m 99.9% sure that the sRGB profiles provided by RT are of matrix type…
In the article to which @Morgan_Hardwood linked in the previous post, I tried my very best to explain in as few words as possible why perceptual intent doesn’t work with matrix profiles. If anyone reads the article and has any questions, I’d be happy to try to answer.
In the meantime, here’s an article that shows an example of what “clipping” looks like when a very colorful ProPhotoRGB image is converted to sRGB:
Ok, so is it appropriate to raise some feature requests / enhancements? If so, I’m happy to create some. My suggestions would be -
RT should be able to show the user what out-of-gamut parts of the image are present in respect of the conversion from working profile to output profile, providing this profile is sufficiently complete e.g. has perceptual intent data. (The conversion from camera input space to working profile might also be relevant but I don’t feel qualified to propose anything on that).
RTs main output profiles, e.g. the sRGB and adobeRGB equivalents, should be enhanced to include all the data needed to support standard colour management and processing.
RT should not allow the user to specify rendering intent or black point use in the Color Management tool if the output profile chosen does not support rendering. In this case it should show Relative Colorimetric with Black Point Compensation? but with these greyed out. (What about the gamma items?)
Colour management is a difficult subject to get to grips with in some ways. One way of looking at it which might help is that it’s a mechanism that allows conversion between different colour spaces and intents.
One package all people tend to have now that is colour managed is a browser. If an image is loaded it will convert to sRGB providing there is a profile in it. It will use that profile to determine what to do. No profile then it assumes sRGB. It does that because of the millions of older photo’s on the web that don’t have a profile. There may be some new ones too. A web search can bring up pages of the same shot using the usual profiles sRGB, aRGB and Prophoto. They will all look the same if things are colour managed. The reason for that is pretty simple - no one in their right mind would produce a shot intended for the web that needed heavier saturation than sRGB can provide. There are some colours in say aRGB that are not reproduced that well but a casual viewer probably wouldn’t notice. I’m thinking of a teal colour in particular. Many monitors will be way out anyway.
RT uses a workspace ProPhoto colour space. The reason for that is that it has a greater bit depth so as tones and colours etc are shifted about they can be restored. If it was using sRGB and some one made a 1/2bit change it’s gone due to rounding errors so can’t be bought back.
On the other hand an sRGB images can be edited far more than many people suspect even in an sRGB colour space. There just isn’t so much scope. If people use the GIMP and look at histograms they will see gaps in them. Done properly this wont be visible when the shot is viewed. Push to far, make more and more re-corrections and it will be. The idea with the GIMP from raw was that ufraw would be used to produce a shot that the GIMP could edit further.
RT can set an output profile. I’ll assume that this could be any of the ones that are available. Say someone chose aRGB and also had an aRGB monitor. They wouldn’t normally adjust the view to the same level of saturation as they would for a print. The print needs it because it’s using reflected light which isn’t as “efficient” as a monitor. I’m not going to bother urinating into the wind on the subject of wider colour spaces - aRGB and sRGB. This link and one off it is a pretty extreme view but accurate if commercial printers are used or as I have found home sRGB printers. http://www.kenrockwell.com/tech/color-management/is-for-wimps.htm
RT only shows out of gamut colours when proofing prints. The best way I can explain how this is used came from some one who does use prophoto printers. Poor name really. They just have larger than normal printer gamuts. The saturation is simply nudged. Otherwise the print will look awful when it’s actually printed. This will have been on a set up for fully handling 10bit aRGB. The same would apply to proofing aRGB on an sRGB set up. A profile for the paper that it will be printed on will also be needed to cause the monitor to display correctly. It’s a process that needs some hands on experience.
People are also inclined to forget that all use mixes of rgb and have different colour step sizes and in essence some offer higher saturation levels than others.
When I can set an intent if I can I use absolute colormetric as I was advised to.
In fact, you can show out-of-gamut colors even if there is no perceptual intent table in the colorspace. Even more, the out-of-gamut warning will be more accurate when using relative colorimetric.
The way out-of-gamut warning is usually implemented (at least in LCMS and in my own image editor, for RT I’m not 100% sure) is to make a round-trip ICC conversion of the type working_ICC → output_ICC → working_ICC, and compare the initial and final image data. If there are differences, it means that some channels have been clipped in the first conversion, i.e. some pixels are outside of the output colorspace gamut.
If you use a perceptual intent in the first conversion, colors near the gamut boundary (but still inside the gamut) will be slightly distorted, and will give differences in the comparison which are somehow uncorrect - think of this as “false positives”.
If RT is providing, as I expect, well-behaved matrix profiles for output, there is nothing one can add to make them “support standard colour management and processing”. They already do, and perceptual intent is simply not foreseen for matrix profiles in the CM. On the other hand, matrix profiles provide the most accurate conversion between one colorspace and another, because the conversion is based on matrix multiplications and not on LUT interpolations (whose precision for example depends on the number of points in the 3D LUT).
This is a valid request, although black point compensation is not as issue and is supported for all profiles, so there is no reason for including it here. Standard matrix profiles usually have a black level at (0,0,0), so no black point compensation is needed when going for example from ProPhoto to sRGB.