[Solved] Colors out of gamut

  • did you defined the color profile of your monitor in Preferences/color Management/Monitor?

  • What is the program you use to display photos? Is it color managed? Does it uses your monitor profile?

  • If your working profile is Prophoto for instance and you assign sRGB profile in output profile, you should not notice this kind of problem

  • left Rawtherapee editor, right photo viewed in a CM programm. prophoto and SRGB

No matter where in the processing pipeline, the following needs to hold true: The embedded/assigned profile needs to accurately describe the gamut represented in the image.

At output, if you really are ‘assigning’ a different profile to an image that was previously converted to a working profile, for internal use by RT, the output file won’t be correctly described with respect to its gamut. It needs to be converted to conform to that output profile prior to saving. RT is converting to the display profile for displaying; I’d bet the saved image is being viewed with the wrong profile, assigned at output.

@Elle schooled me here, in the difference between ‘assign’ and ‘convert’.

@paperdigits

I work in ProPhoto. I don’t see any difference with sofproofing on / off on my monitor (with the monitor profile). I observe the color shift though if I set the profile to sRGB or None (bottom bar):

sRGB_bar

@gaaned92

I defined the color profile of the monitor in the preferences and all the image viewers I use are colored managed. I work in ProPhoto and do notice the problem during export assigning the sRBG profile:

sRGB

Do you actually see any color difference in my first post ?
The pictures are obtained with the output profile set to that one of the monitor and RTv2_sRGB.

See the previous post: did I assign or convert ? :slight_smile: Considering the profile is applied at the output it should be a conversion. Otherwise I misunderstood the purpose of that option …

Yes, and that is why I asked you some questions.
What is your system and what is your viewer?

I understand that the display profile in preferences is your monitor profile and that the output profile is RTv2_sRGB.

Is it true that the display profile assigned in your viewer is your monitor profile?

RT converts the data from working profile to Output profile.

If you can upload the pp3, I will test here. What is the playraw?

@gaaned92

the play raw is this one (where you find the pp3)

I am using Windows 10, and the photo app to review the jpegs.
I use the monitor’s icm profile in windows’ color management.

left windows photo, right RT 5.5 editor with your pp3
I don’t see great difference

By the way, do you use the fast export?

I agree, in your screenshot the colors are close.
I use the fast export.

EDIT: I might have understood …

It looks like “RTv2_sRGB” and “sRGB Color Space Profile” give quite different results, the latter is correct. What do you think about it ?

It should be left as RTv2_sRGB, as the image will then be displaying in the sRGB colorspace (i.e. what your monitor is set to). Your monitor profile is used to correct the colors that it displays.

Your output colorspace shouldn’t matter so long as the device/software being used to view it has color management. The colorspace you define for the output will be picked up by the device/software, and then be transformed to sRGB.

The Photos app is not colour-managed (it doesn’t consider the monitor profile you set in your Windows colour management, and it assumes your monitor covers sRGB exactly 100%, which is a dangerous assumption). Windows Photo Viewer, OTOH, is colour-managed (but it doesn’t like LUT-type monitor profiles) – it’s not available on Windows 10 by default, though .

1 Like

I am on W10, but I never used those MS photos stuff as I am not at all confident in them. Furthermore, it is a real pain for me to use that.
What I can say is:

Photos Microsoft 2018.18091.17210.0
© 2018 Microsoft Corporation
seems color managed.

I don’t know if it is Photos app or photo viewer!

  • I tried with fast export but was not able to reproduce. I will check if the embedded ICC is the same.

edit: the embedded ICC are the same.(RTv2_sRGB)

It’s pretty easy to test the colour management of a program by using an image with a manipulated ICC profile embedded in it (this checks one aspect of colour management) and by using a monitor profile which differs considerably from your own monitor (ArgyllCMS and DisplayCal allow the creation of such profiles).

Here’s a popular set of images which one can test in the Photos app and in Internet Explorer / Edge browsers: DOWNLOAD PDI TEST IMAGE Photodisc Color Management Calibration Target Reference Image Baby Faces How To Achieve True Print Color

1 Like

@sankos the photo app in windows 10 is color managed as said by @gaaned92, I cross-checked with XnViewMP: same behaviour.

XnView settings:

settings

@sankos thanks, I visit later the link, perhaps it helps the troubleshooting …
EDIT: PDI target test PASSED.

Let me summarize the evidence once more.

I created in RT two versions of the same file, the first with RTv2_sRGB as output color profile, and the second with sRGB Color Space profile as output color profile (which happens to be IEC61966-2.1).

Everything else being equal (color management, monitor profile and rendering intent included) I should not see a significant difference in color rendition, but I do see it (whatever is the software).

EDIT: I just realized I never showed how bad is the out of gamut indication:

out%20of%20gamut

Soft proofing is off, so the indication refers to the monitor itself, not the output profile.

Are you saying that RTv2_sRGB has out-of-gamut issues while sRGB Color Space doesn’t? What I know about sRGB profiles is that there are many of them and that all of them are different interpretations of the sRGB ICC spec. Different yet similar. RT also has a RTv4_sRGB profile; give that a go as well. However, I don’t know why they would be as different as you have indicated. Could you export one of each so that I could take a look? Thanks.

I just tested all the sRGB profiles my RT 5.5 has access to, and my colour-managed viewers don’t show any apparent differences in the output (that’s on a wide gamut, profiled monitor).

OK, so what you’ve confirmed is that both Photos and XnViewMP can read the embedded profile. The other part of the colour management test is with the monitor profile. If you used e.g. a wide gamut monitor profile as your system profile while your actual monitor is close to sRGB (like your Dell appears to be), then you’d see a difference between XnViewMP and the Photos app because the former respects the selected monitor profile, and the latter doesn’t.

Anyway, this doesn’t help much with your OP issue – I just wanted to point out the importance of using a properly colour-managed and set-up photo viewer when troubleshooting issues of this kind.

No @afre, I’m only saying they look different and sRGB produces color equal to those I see in RT right before exporting.

RTv2_sRGB
RVTv2_sRGB (version 4 = same result)

sRGB
sRGB Color Space Profile

We likely have different monitors, so I can’t tell how they handle colors out of gamut with respect to one another. To me the two images above are quite different.

I assume (correct me if I am wrong) that if the difference resides in the color rendering of the monitor, than one should be able to pick a yellow-tone from the same spot of the two pictures and read equal RGB values … otherwise the difference is real and baked in the files rather than appearent, and one can or can’t see a relevant difference depending on the monitor gamut’s coverage.

The comparsion here below shows the difference in terms of RGB values for the same pixel using the two profiles above (in the same order):

color%20picker

1 Like

@sovereign I think you are right. In fact, I’ve noticed this myself. Recently RT introduced a sort of “hack” that is supposed to improve the quality of v2 profiles. Here is the comment describing the issue: New Output ICC profiles - from Elle Stone · Issue #4478 · Beep6581/RawTherapee · GitHub
and here is the relevant part of the code that implements the “enhancement”: RawTherapee/iccstore.cc at e1a467501d3705de2d1a0f6544b168c1b71fa901 · Beep6581/RawTherapee · GitHub

Unfortunately, it seems that this enhancement has some side-effects, and you have observed one. Here are two renderings of the flowers, that differ only in the output ICC profile. And what’s more, the two output profiles are supposed to be identical (they have been both generated by RT), with the exception that one of them contains some special comments that are detected by RT and cause it to apply the “enhancement” on-the-fly, before using it for the output jpg. Notice how the two renderings are substantially different, with the “non enhanced one” (IMHO) way more pleasing.

The two icc profiles used are available here:
https://filebin.net/skg0flix4aklwou6

Unfortunately, I haven’t been able to understand why the difference happens, nor to file a proper bug report (sorry!). Perhaps @jdc can take a look and shed some light anyway?

1 Like

I noticed this “sRGB Color Space Profile” is not part of RT’s bundle.
It is available inside C:\Windows\System32\spool\drivers\color.
For some reason RT is still able to make use of it.

I trust you about the color management stuff: I have no experience with wide gamut monitors.

In a properly colour managed environment, they should indeed look the same and have the same values. Maybe the enhancement is too much for our computers to comprehend. :stuck_out_tongue:

Joking aside, the fact that the values are different is an issue. If I use G’MIC to generate a GIF, disregarding the ICC profiles, I get this:

flowers

@afre note that if you replace the “enhanced” profile with a v4 profile, you still get the “bad” output. And in this case RT does nothing special, it simply calls LCMS. So this might indeed be a glitch in LCMS – I don’t really know yet.