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.
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
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ā¦)
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