Help with over-saturated area?

[Carmelo_DrRaw]

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…

@stefan.chirila

As for BruceRGB I suppose it distributes the available colour values differently staying away from what looks like highly saturated values in ProPhoto.

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.

@stefan.chirila

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

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…

[stefan.chirila]

@Carmelo_DrRaw This is helpful. The only think I did not quite get is when you talked about matrix-type ICC profiles

@Carmelo_DrRaw

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.

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.

[Carmelo_DrRaw]

@stefan.chirila

The only think I did not quite get is when you talked about matrix-type ICC profiles

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

[stefan.chirila]

Oh I see. Thanks!
Now is there anything I can do to see some change happening ? For the sake of an experiment.

[Carmelo_DrRaw]

@stefan.chirila

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.

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…

[Carmelo_DrRaw]

@stefan.chirila

Now is there anything I can do to see some change happening ? For the sake of an experiment.

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…

[agriggio (Alberto)]

@stefan.chirila

@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

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…

[stefan.chirila]

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

[afre (Alan)]

Yes, that is what I was suggesting. I mean, how many screens support ProPhoto? Mine certainly doesn’t.

[agriggio (Alberto)]

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…

[stefan.chirila]

@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

[Carmelo_DrRaw]

@stefan.chirila

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.

[stefan.chirila]

@Carmelo_DrRaw sadly changing the intents doesn’t make a difference for me

[stefan.chirila]

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)

[Carmelo_DrRaw]

@stefan.chirila

Now about SoftProofing

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…

[Morgan_Hardwood]

@stefan.chirila

why do I need to soft proof for this colour profile when the monitor is already using it ?

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

@stefan.chirila

Should I be saving my photos for it instead of sRGB?

Absolutely not.

@stefan.chirila

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.

Firefox has/can have working color management, Chrome does not.

@stefan.chirila

I feel right now, because this stuff makes little to no sense to me.

It only gets worse. There is a good reason that XKCD comic on color exists.

[stefan.chirila]

Hahahaha XKCD thanks @Morgan_Hardwood I believe I get it a bit more now

[rogerx (Roger)]

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.

[Ajohn (John)]

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

[Ajohn (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