Hi friends,
how can I control the oversatured colors (posterization…?) using the Standard curve.
With the “film like” curve this problem is gone but I prefer the colors of the Standard curve.
Is something wrong in my image edition?
One other question. How can I know wich colors are out of gamut in RT?
Here is a detail:
The whole image:
I have attached the CR2 file and the pp3
_MG_3029.CR2.pp3 (10.4 KB)
You can control oversaturated colors for example by using the CC (Chromaticity according to Chromaticify C=f(C) ) curve in the L*a*b* tools:
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
Also note that the “Before” view still does not use the monitor profile: In B|A mode, B doesn’t use monitor profile #3090, that is why no monitor profile is used in my screenshot.
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.
_MG_3029.jpg.out.pp3 (10.1 KB)
Steps
Highlight recovery and black point adjustment to gain some room at each end of the histogram.
Mixed lighting, red seems to be a bit of a problem so worked on the red curve - shifted it’s histogram plot along and adjusted it’s contrast.
Contrast and brightness adjustments
Reduced and sharpened - rad 2 degree 27 in Fotoxx. Done - about 5min.
I think more could be done in RT but if the background in the stall needed changing it would be over to the GIMP using 2 layers and brushes.
John
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.
Then brushes and masks could be used to limit the areas it’s applied to or any other process that has been applied but the layer mode would normally be normal in that case.
John
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.
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?
The PP3s for the two versions (rel.cal vs. percep) are here -
_MG_3029-Percep.jpg.out.pp3 (10.4 KB)
_MG_3029-RelCal.jpg.out.pp3 (10.4 KB)
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?!
Above with RT 5.2-5.
@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…
They are not out-of-gamut areas. They are areas where one or more of the channels are clipped. The level of grayness of the indicator shows how many channels are clipped. White = 3/3 clipped, light gray = 2/3 channels clipped, darker light gray 1/3 channels clipped. The indicators are affected by the “Use working/output profile for main histogram and navigator” setting "Use working/output profile for main histogram and navigator" affects more than that · Issue #4067 · Beep6581/RawTherapee · GitHub and only seem correct when that option is enabled.
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.
An old adage goes, “When in doubt, @Elle”
https://ninedegreesbelow.com/photography/icc-profile-conversion-intents.html
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…
The RawTherapee sRGB profile is a matrix profile.
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:
This pixls.us post/thread might be helpful:
Correct, only for printer soft-proofing.
Ok, so is it appropriate to raise some feature requests / enhancements? If so, I’m happy to create some. My suggestions would be -
Do these seem reasonable?
and so on. Thanks, that’s good to know. I tried the “use working/output profile…” setting and can see it makes a difference.
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.
John
Except if you use Chrome/Chromium, which is most people.
I couldn’t manage to read the whole thing, it was just too wrong.
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.
