Hey guys, I’ve got this image here, which I think turned out quite nice overall except for the red area in the kid’s nose. If I switch working profile to AdobeRGB or sRGB it fixes it but changes the other colours too. I like the other colours 
Why is this happening; any idea?
With ProPhoto:
PP3: ND7_8648.NEF.pp3 (9.7 KB)
A wild guess is that your monitor cannot display those red values so they end up saturated or clipped. It is hard to tell without knowing your full setup and color management. Why does it improve when you switch to another profile? It might be because the chosen intent allows values to be redistributed or dropped in such as way that the nose looks okay but everything else gets shifted.
@afre so you’re saying the inside of the nose doesn’t look clipped red to you? Hmm it might indeed be my monitor. I have an Acer which I calibrated, but I suppose I shouldn’t rely too much on it or put too much faith into it
As for BruceRGB I suppose it distributes the available colour values differently staying away from what looks like highly saturated values in ProPhoto. Also looks on average a tinge brighter. Hmm.
Another thing to mention is, I find changing the Rendering Intent in RawTherapee, whether in the Colours tab, or in settings, does not make a noticeable difference at all 
I am running version 5.0-r1-gtk2, haven’t updated to another due to the gtk2 aspect. I need to upgrade my Debian box to something more gtk3 friendly but I thought Rendering Intent wasn’t something that was broken in any version 5+.
The first question I would ask is: where is the working RGB color profile used in RT, and why going from ProPhoto to BruceRGB changes not only the saturated reds in the nose, but also the overall tint in the image?
Comparing your images, the BruceRGB version looks warmer in general (see for example the greyish dress of the lady in the background, which is shurely within the gamut of both colorspaces). IMHO, this should not happen in a color managed workflow…
BruceRGB reproduces the same colors as ProPhoto if they fit within its gamut (although the numerical RGB values are different), and clips one or more RGB channel if the color is out-of-gamut. Please note that BruceRGB has a much smaller gamut than ProPhoto, basically comparable with sRGB. So yes, it “stays away from highly saturated values” simply because they cannot be represented… however, you are not obliged to have highly saturated colors in ProPhoto.
What I would personally do is to bring the ProPhoto version into GIMP (or PhotoFlow 
) and locally reduce the saturation of the area in the nose, until the colors are brought back into the gamut of your display (or of sRGB) and start looking natural again.
Most likely this is because you are making a conversion between two matrix-type ICC profiles. Such profiles do not have any perceptual intent table encoded into them, and therefore choosing “perceptual” as the rendering intent will silently fall back to “relative colorimetric” without further notice.
Hope this helps…
@Carmelo_DrRaw This is helpful. The only think I did not quite get is when you talked about matrix-type ICC profiles
So basically, my question is, in what situation, would I see a change. What do I need to do, assuming I’m starting from scratch, just RawTherapee and a random Raw file. I’m asking because it seems that no matter what I do, changing the rendering intent does not change anything in the look (on screen or in the saved file).
As for the solution the issue, thanks 
, much appreciated, though it was more of a, “I’d like to know how to avoid this whole thing altogether,” than a “how do I fix it?” matter.
If I understand correctly, the rendering intent you mention, which can be set either in the Colours tab or in settings, is the one that corresponds to the conversion from the camera colorspace to the working RGB colorspace. As far as I know, RT then goes from RGB to Lab for the rest of the processing.
Unless you are using a special custom profile for your camera, the standard camera input profile is given in the form of a 3x3 matrix which allows to convert from an RGB triplet in the camera colorspace to an XYZ triplet.
Next, the ProPhoto or BruceRGB working colorspaces are also given as a 3x3 matrix that encodes the conversion from XYZ back to RGB.
All this transforms are linear, and they have no way to accomodate any gamut mapping (i.e. a “distortion” of the linear conversion which is stronger the more the color is outside of the destination gamut) as needed by the “perceptual” intent.
The “perceptual” intent has usually an effect when converting to a LUT-based profile, mostly used for describing output devices like displays or printers. Such LUT profiles provide internally a description of how to compress the input gamut such that it fits into the device’s one, although color fidelity is consequently not guaranteed at the gamut border if the perceptual intent is used.
What I am saying is probably not 100% correct from a technical point of view, but should give you an idea of why “perceptual intent does nothing different compared to relative colorimetric when converting to ProPhoto or BruceRGB”.
Oh I see. Thanks!
Now is there anything I can do to see some change happening ? For the sake of an experiment.
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.
thanks