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!
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
@sankos the photo app in windows 10 is color managed as said by @gaaned92, I cross-checked with XnViewMP: same behaviour.
XnView 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:
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.
RVTv2_sRGB (version 4 = same result)
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):
@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.
with enhanced profile
with “normal” profile
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?
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. 
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:
@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.
Thinking about the problem a bit more, it might be code that is meant to tame out-of-gamut colours automagically. I am thinking that it might just be in the wrong place.
OK, I’ve downloaded the DNG file and loaded it to RT5.5 – I used the default RTv2 sRGB and RTv4 sRGB and I can see the problem you are talking about. It appears there’s indeed an issue with the two RT sRGB profiles because the output is different than the preview. It didn’t manifest in my own test files I used before but for some reason this file does create a problem with the two RT sRGB profiles.
what code are you talking about exactly?
Thank you Alberto.
Precisely: the enhanced profile brings down the brightness of certain yellow-tones, like in my example.
I understand I can’t tell what a color out of gamut should look like … otherwise it would be within the gamut. I can’t explain the difference given by the two sRGB profiles though. They should produce similar results on my monitor.
@afre LOL, I had in mind to make a gif as well 
And I actually did … but then I posted the comparison of the color pickers.
Don’t mind me. Just wild and hopeless speculation. There have been a few threads discussing ways to rein in out-of-gamut colours…
@afre, please do speculate 
my question wasn’t meant to be a criticism, sorry if it sounded harsh. If you have some ideas, please just elaborate… if you are talking about the “hack” in RT, its purpose is to avoid discretization issues in the generated TRCs for v2 profiles, as described in the first link I posted above (and related discussions on github). If you instead were thinking about some code inside LCMS, well if you have some hints please do share them (I don’t know that code, but I can still try taking a look at some point…)
EDIT: ping also @gwgill, your expertise would be welcome!
for curiosity: I exported the photo using the sRGB profile copied from the installation of digiKam (srgb-d65.icm): guess what … no issues.
The green channel is overexposed in the raw file (8.15% as reported by FastRawViewer):
darktable shows something similar with its raw overexposure indicator:
The problem for RT users is that the preview doesn’t correctly show the output, whereas in dt this is not a problem.
Here are the differences I was able to find Imgur: The magic of the Internet sRGB (Left) vs RTv4_sRGB (Right). The difference in matrices is almost negligible, though I suppose it could be doing something. I would think the function for tone response curve is well defined online, that in mind, I find it hard to believe that the response curve is the issue.
I’m unfamiliar with how LCMS works, so there may well be an issue there too.
It should be noted that RTv4_sRGB matches 100% with sRGB-elle-v4-srgbtrc (in this program, atleast).
Another experiment: I copied the RTv2_sRGB profile to darktable and used it over there. The result: no visual difference between its native sRGB profile and the RTv2_sRGB profile (relcol rendering). Conclusion – it’s the rendering problem in RT, not the profile.
