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.
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.
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.
@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!
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.
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?
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…)
And I actually did … but then I posted the comparison of the color pickers.
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…)
(otherwise, I’ll try to do it myself, but don’t hold your breath…)