I think there is no way to “avoid” the problem. Color adjustments can easily push already saturated areas “over the top”.
An RT-only solution might be the use of the LCH curves, particularly the CC curve that allows to selectively reduce the Chromaticity (read: saturation) of highly saturated areas without affecting the colors with lower saturation. @Morgan_Hardwood can probably give a better explanation of this, or better suggestions…
If you have some printer ICC profile at hand, you can try to set this as the working colorspace. Then take a picture with highly saturated areas with some texture, and try to change the rendering intent. If the printer profile is of LUT type, you might see some visible differences: when the RGB channels are simply clipped by the relative colorimetric intent, the texture is probably destroyed or hardly visible. The use of a perceptual intent should allow to restore at least part of the original texture, because channel data is not simply clipped but modified in a more complex way.
Unfortunately I do not have a good sample image at hand to show what I am talking about…
Just FYI, I see what you are talking about, but the issue is much worse on my old laptop’s monitor (an 8-year-old T400) than on my work screen (a high-quality and relatively recent Dell). Both are calibrated to the best of my possibilities (i.e. not “professionally”, just using a colorhug2), but still I can clearly see a difference. Calibration can’t fully compensate for a poor screen…
@agriggio thanks for checking!
So basically the area is not technically “clipped” within ProPhoto …but if viewed on a screen that doesn’t support enough of ProPhoto it will look clipped.
Yes, that is what I was suggesting. I mean, how many screens support ProPhoto? Mine certainly doesn’t.
just to understand: are you using prophoto as an output profile? I thought you were using it as working profile, but then converted to srgb…
@agriggio I am using it as the working profile and then saving in RT_srgb or something (it’s in the pp3 file). So if I’m thinking what you’re thinking …exporting to sRGB should de-saturate the nose? …cause it doesn’t 
Most likely you cannot appreciate the difference, because you are looking at your image with a monitor that probably covers the sRGB gamut at best (unless you have an high-end wide-gamut display).
In other words, there is no way to “see” the highly saturated red tones that are present in the ProPhoto version, because your output device cannot reproduce such colors.
Therefore, the conversion from ProPhoto to sRGB will definitely de-saturate the nose, but in a way that is not visible, because the same de-saturation happens when the image data is converted to the display profile and then sent to your monitor.
One thing you might want to try (although it will not change your final sRGB image) is to change the “Default monitor intent” to “Perceptual” in RT settings, and see if the nose looks better. The result will change or not compared to the default “Relative Colorimetric” intent depending if your display profile is of LUT type and contains a perceptual intent table.
Now about SoftProofing 
Bit of a different topic but along the same lines I guess:
Alright so I have a calibrated monitor that I work on. I put the calibrated icc profile of the monitor in /usr/share/color/icc for Rawtherapee to see and I selected it in the soft proofing area (screenshots below). It shows a difference in the shadows. If I use the monitor’s icc as saving colour profile instead of the sRGB it saves it with the softer shadows as in soft proofing (proven by opening in Gimp).
What I’d like to ask is, why do I need to soft proof for this colour profile when the monitor is already using it ? Should I be saving my photos for it instead of sRGB? And also am I as stupid as I feel right now, because this stuff makes little to no sense to me.
In sRGB:
Here it is saved with RT_sRGB:
With calibrated icc in SoftProofing:
Here it is saved in the icc for the monitor:
Looks fine on my computer but when I upload it here it looks weird and purple. Now if I open it in Firefox, it shows up fine.
Please someone make sense of this
Guess y’all could use the file:
ND7_8483.NEF (24.1 MB)
PP3:
ND7_8483-1.jpg.out.pp3 (10.3 KB)
Soft-proofing is a different beast… shortly speaking, the purpose of soft-proofing is to simulate the way an image looks on a given output medium A, by using a different output medium B. Typically, you want to use your display to check how a photo would look like once printed.
Therefore, the ICC profile that you select at the bottom of RT’s preview window should correspond to the output medium you want to simulate, and not to your display device.
Technically speaking, in soft-proofing mode the image is first converted from the working colorspace to the soft-proofed profile (step 1), and then from there to the monitor profile (step 2).
Step 1 is where channel data might be clipped because out-of-gamut, and where you can eventually recover part of this clipping with the perceptual intent if the soft-proofed ICC profile supports it.
Notice that soft-proofing only makes sense if your display covers a gamut that is wider than the one of the soft-proofed profile. Otherwise, there is no difference with respect to going directly from the working profile to the monitor profile.
Notice also that modern ink-jet printers normally can exceed the sRGB gamut at least in some hue ranges, therefore you need a wide-gamut display if you want to get a meaningful soft-proofing of an ink-jet print.
Another aspect that can be emulated via soft-proofing is the black level of the final print. Assuming that the black level of your display is lower than the one of the ink-jet print (blacks are “more black” on your display compared to the final print), you can simulate on-screen the lower contrast of the final print that results from the higher black level.
For this, you have to enable the black-point-compensation (BPC) in step 1 (black in the working colorspace will be mapped onto the darkest color the printer is capable to generate), and disable BPC in step 2, such that the black level of the print will be “mapped” onto a RGB values above (0,0,0) in the data sent to screen.
I hope this has clarified at least some aspects, and not generated even more confusion…
You don’t need to. Who said you did? There are situations where that could be used, but they’re very uncommon and I won’t go into that here.
Related discussion with Marti Maria the LCMS dev: Softproofing branch · Issue #3406 · Beep6581/RawTherapee · GitHub
Absolutely not.
Firefox has/can have working color management, Chrome does not.
It only gets worse. There is a good reason that XKCD comic on color exists.
Not just a very slight oversaturation of red, but a very slight oversaturation of the blue channel as well. You can see the very slight increase of blue within the whites of the eyeballs. I think I also notice a slightly more red and more purple coat as well.
I’m using a Samsug Galaxy Tab S3 tablet having one of the nicer displays.
These over-saturation issues are always fun to detect, similar to working a word find puzzle. (And then I usually remember I’m using a night time blue channel remover for viewing my display at night time. And I just realized I’m using it now too!)
Upon switching off my blue-filter, I can also see a very very slight increase in the green channel. On the top photo, I see definite green shades between the two heads and the leaf to left of the baby’s head. On the photo with more normal colors, those same areas have much much darker shades of green.
Remember, photos will contain varying levels of channels of colors, making hunting for oversaturation even funner!
I believe the RawTherapee manual suggests using the ProPhoto color profile for the working color profile, and then saving/exporting to sRGB color space. Exporting to AdobeRGB only if you have hardware supporting AdobeRGB, such as a high-end printer. More likely, since you have a wife likely using the photos, sRGB will be best.
You stand a chance of correcting the redness with the hsl curves. They may interfere with the lipstick colour as well but if you keep the adjustment width small and narrow by adding “dots” each side of the adjustment probably not. They are tricky to use and often all 3 need adjusting to get the correct effect. There is a soft of eye dropper that can be used to scan an image and show the colours position on the curves. I often wish a click would retain it so best try to adjust and then use the eye dropper again to check it’s in the correct position and adjust etc. You may find that just saturation needs altering but probably not. Getting an exact match to say skin tone is likely to be too tricky.
Friendly advice - try not to take shots where the direction of view includes up some ones nose. There’s likely to be lighting variations etc.
This explains the HSL model. HSL and HSV - Wikipedia
John
Looks like a hue adjustment might do it but I haven’t really checked for effects elsewhere in the shot.
Quick pp3 that you can play with on the jpg that can probably be bettered.
547082c2c833e05d9fcdc5a9e9600431479c346b-1.jpg.out.pp3 (10.5 KB)
Following that correction you may want to make other basic colouration adjustments. I haven’t done a side by side comparison.
John
I don’t know if you run Linux or etc. Getting things to use a monitor profile can be tricky at times. In my case for instance profiles are user based and were system based previously. My answer is to use DisplayCal to profile and let it install it for me. It is a more complex package than those than come with typical colorometers and spectrometers though and that sometimes causes people to have problems using it. Currently a profile and verification for me can take an hour. Bit different to what usually comes with them.
Only problem I have now is a viewer - Gwenview on KDE refuses to use the colour management so have to use a different viewer.
John
@Ajohn I do use Linux and have my monitor calibrated with dispcalgui and have the icc profile loaded upon startup, have only one user on the machine
AFAIK that statement about Chrome is wrong. At least for the desktop version starting from version 24 or so. The android version has no color management. That statement is still true.
In the desktop version it might be necessary, depending on your OS, to add “–enable-monitor-profile” to the command line.
thanks