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.
1 Like
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.
1 Like
hi,
the culprit is the “TRC rebuilding” code I linked earlier. disable that and the two srgb profiles match. dt doesn’t have that code, so no surprise it matches. did you try with a v4 profile in dt perhaps?
From what I can tell the only difference between the v4 and v2 curves is that the v2 curve has an added “+0” at the end of its function.
Yes, RTv2 and v4 look the same when output from dt using the same rendering intent.
thanks for testing. then there might be something fishy in how RT uses LCMS – I’ll try to investigate when I have some time
1 Like
bingo! That’s exactly what it was. Or actually, a leftover from when I implemented some basic support for “no clipping” in the RT pipeline. Essentially, the old v2 profiles were always clipping the output, whereas the new v2 (enhanced by RT) and v4 are not clipping (they make LCMS work in “unbounded mode”). In the latter case, there was some clipping applied by RT before converting to 8-bit output, but that clipping was not the same as the one used by LCMS. This was not by design, it was just my mistake 
Here’s a patch that should solve the problem:
diff --git a/rtengine/imagefloat.cc b/rtengine/imagefloat.cc
--- a/rtengine/imagefloat.cc
+++ b/rtengine/imagefloat.cc
@@ -141,9 +141,9 @@
float ri = r(row, i);
float gi = g(row, i);
float bi = b(row, i);
- if (ri > 65535.f || gi > 65535.f || bi > 65535.f) {
- Color::filmlike_clip(&ri, &gi, &bi);
- }
+ // if (ri > 65535.f || gi > 65535.f || bi > 65535.f) {
+ // Color::filmlike_clip(&ri, &gi, &bi);
+ // }
if (bps == 16) {
sbuffer[ix++] = CLIP(ri);
sbuffer[ix++] = CLIP(gi);
If someone can open an issue on github, that would be very appreciated 
(otherwise, I’ll try to do it myself, but don’t hold your breath…)
3 Likes
Glad I am not crazy: knew something was up.
Please do. My back has been hurting so much lately. Don’t feel like doing it. Armchair commenting is enough for now.
Nice findings guys. Keep up the good work.
I hope this fixes some od the issues i had seen lately with my photos