As I said, this is with the system set to use an sRGB profile, and both RT and Firefox set to use the system profile. Chrome play solo
That was the first comparison I posted. Most probably you’re using a sRGB profile in your system (or close to it), and thus you see what Chrome renders by default (ignoring mostly everything you have set in your color managed workflow). Take a look at this comparison in a previous post.
As a note: I don’t really know if my screen currently shows the right colors, and I have no way of knowing it. But as far as I can tell, at least now I know that what I see in RT is rendered mostly the same in both Firefox and Chrome, and this means that (as a Firefox user) I’m not consistently underexposing the images I post (as most readers use Chrome, and it shows a darker image).
Will they see the images as I intended? I will never know, but at least now I won’t be systematically adding exposure errors.
EDIT: the server seems that doesn’t allow me to upload the Firefox rendering, I think because it essentially is the same as the Chrome rendering
The RawTherapee sample is vastly different from the other two. It’s not just a different rendering due to different primaries, it’s actually a different image - it has low-frequency halos the other images don’t, something which cannot manifest just as a result of broken color management as far as I know. I think your test case may be bugged…
To set your profile so that Chrome uses it, assign it to your monitor system-wide (how to do this depends on the OS but DisplayCAL can take care of it), and make sure that chrome://flags/#force-color-profile is set to “Default”.
Then, to see how far off Chrome is (at least within sRGB), you could use DisplayCAL’s verification tab with “Display” set to “Web @ localhost”, “Simulation profile” set to sRGB, and “Use simulation profile as display profile” checked.
(With Chrome’s color management enabled, DisplayCAL can only test how Chrome displays colors within sRGB because it sends its colors via CSS, which only supports sRGB colors until CSS Color Module Level 4 gets more traction. If the color profile in Chrome were set to “sRGB”, then it would pass the CSS colors to the screen unchanged, allowing DisplayCAL to measure the monitor’s whole gamut, but that’s not the point here: the point is specifically to verify how Chrome translates sRGB values into actual colors.)
Maybe it’s because those are screen captures and RT shows in the preview a close enough image to the real, exported image?
But even if I’ve made some mistake, or there is some setting incorrectly activated, the 3 renderings are much closer that those at the start of this thread.
I will look into that with another image, but will take me a few days
If you will allow a small tangent, I just remembered that I actually did something like that to test whether setting Chrome’s profile to “Display-P3” would be an acceptable substitute for a proper display profile on my phone, since Android does not allow the latter. And it turns out that it is! So I can enjoy normal colors when browsing the Web on my smartphone.
Yes, that’s probably it. To eliminate the difference you could export the photo from RT to say a JPEG file, then open the JPEG file in RT, and only then take the screenshot.
Well, even though after going back to my custom profile (system wide) we are back to square one (that is, the same differences clearly visible in my first post), I’ve tried the suggested procedure, and DisplayCal shows this report:
And the little colored squares comparing the expected colors with the rendered colors, shows that most of them are rendered far darker than expected. Exactly as the screenshots of my first post show.
With everything we have talked here, I guess that Chrome uses the primaries of the profile, and assign the TRC of a canonical sRGB profile. As my primaries are not exactly the same as sRGB, and probably the TRC of my display is quite different from a canonical sRGB one, the result is a complete mismatch. Yes, my reds won’t turn greens, but the image will not look as intended.
On the other hand, if I limit myself with an sRGB profile, I won’t have deeper shadows (it’s really noticeable when I change the profiles), and probably won’t have correct colors where my display can’t render the most saturated greens, blues and purples, but all 3 programs render the same image on display.
With the current state of color management in linux, I would say that’s a (minor) win.
All your colour-managed applications should consult the system-wide monitor profile when they create the preview. Forcing them to use sRGB doesn’t make much sense because if they are not properly colour-managed sRGB is what they assume, and if they are colour-managed they should use the custom display profile. To test whether an application actually uses the custom monitor profile, you could use swapped matrix profiles like the ones posted on the DisplayCal site (test profiles.zip).
After making a screenshot I go to my pixel editor and first Assign my monitor profile to the png/jpg, and then Convert to sRGB so that I can share it online. This is not necessary only if you use the sRGB emulation mode of a wide gamut monitor.
Except when we talk about the most widely used browser: Chrome. What if it uses the color primaries of the system wide display profile, and nothing else? What happens with all the other things inside an icc profile? What if Chrome assigns those other things with hardcoded defaults that most likely won’t have anything to do with your current monitor?
All of that has already been discussed in this thread, and up until now the only way to see something close to what the majority of viewers will see is by doing something that doesn’t make much sense. That is, I’m forcing RT and Firefox to use sRGB because it seems Chrome doesn’t understand anything else.
Again, this is what I see with my custom display profile set system wide and Chrome using the default system profile:
And to compare Chrome, Firefox and RawTherapee renders with a system wide display profile setting that doesn’t make sense, just take a look at the images present 2 posts above (Spoiler: all 3 images look the same).
It’s not that I don’t wish, or need a better approach. I really want a whole ecosystem of applications with perfectly good color management implementations.
But given that Chrome, with a gazillion programmers working on it, is not capable of handling a good color management (unlike most other FOSS programs do, with just a bunch of programmers), and given that it’s the most used web browser, I’m looking for a way to adapt my workflow and show that Chrome users at least decent images. I guess it’s not something to be blamed for.
If any of you have a better approach, tested and working, PLEASE TELL ME!
I was really really happy with my custom display profile
The Chrome version looks like your version2 pngs above, and although it doesn’t seem to have crushed shadows, it’s very dense. The RT rendering, which I assume is your intended look, has much more open shadows. Setting RT to use sRGB as display profile would probably mean that you’ll overcorrect your shadows, and they will end up looking even more open on colour-managed systems.
If you want to be sure of the TRC of your profile, you can use DisplayCAL’s “ICC Profile Info” tool and change from the default “Gamut” view to “Tone response curves”. It will show the curves themselves as well as a textual approximation at the bottom (like “averaged RGB transfer function ≈ sRGB (Δ 1.15%)” or “averaged RGB transfer function ≈ Gamma 2.20 100% (Δ 1.61%)”).
You could get closer to the sRGB TRC by calibrating to it (or to a gamma of 2.2) prior to profiling, if you use calibration curves or if your monitor has a gamma setting. Then, Chrome assuming that curve would be somewhat less of a problem.
Sorry everybody for these late replies. I was busy at work.
The Chrome version is the same in all the samples, because Chrome refuses to use anything but an sRGB profile. Well, to be more precise, and as it has been said, Chrome use my custom primaries if I have set a system custom profile, but with a hardcoded TRC, that happens to be the same as in an sRGB profile. As my custom profile is not that different to an sRGB profile, Chrome renders the image mostly the same no matter the profile I use.
And yes, the RT rendering was my color managed intended rendering. And it showed like that in Firefox (my main browser), so I take for granted everybody would see it that way. Wrong! Anybody looking at my processing on a Chrome browser will see an image that :
So what do I do now? Edit my images with overcorrected shadows (in fact, overcorrected global luminance) so more than half the viewers will see it as intended (because they use Chrome)? Or do I keep processing images for myself in the believing that someone that happens to have a color managed system and curious enough will load my .pp3 to see what I’ve really done (even it’s more than likely that he/she will be browsing the web with Chrome and will be looking at a dark, unpleasant image?
Those are the questions I’m trying to find an answer to.
That’s not very surprising since it doesn’t use that part of the profile. But what you can do is calibrate to a target TRC of sRGB or gamma 2.2 (they are not quite the same but they are close), which will affect all applications instead of just the color-managed ones.
As for what those values mean, they mean that according to your profile, the relation between the output luminance of your monitor (relative to its maximum) and the encoded values sent to it (normalized to [0, 1]) is approximated by the equation: out = in^2.7. sRGB is better approximated by 2.2 than by 2.7, which is why sending sRGB values to your monitor without accounting for that difference results in darker tones: https://www.wolframalpha.com/input/?i=plot+y+%3D+x^2.2%2C+y+%3D+x^2.7+from+0+to+1
Calibrating to the sRGB TRC would make your GPU transform every value sent to it so that the GPU+monitor combination effectively follows that curve. The profiling that would follow the calibration would (hopefully) measure a TRC very close to the target one, and so that’s what would end up in your new profile.
If you edit them in a color-managed workflow, the effective gamma of your monitor does not really matter because if your profile properly reflects your monitor’s behavior, then your editing application will account for it anyway. So what matters most is that you use an accurate profile when editing. Most users won’t themselves have a proper profile, but you can’t predict in which direction it will be wrong anyway (your monitor has a rather high gamma of ~2.7, but my old Dell S2716DG was closer to 1.9, for example, making everything too bright).
