Web browsers color management (solved)

It’s raining here, so I have some spare time :smiley:

I’ve opened the original PNG I uploaded to Playraw, and this are the results (again, with a system wide sRGB display profile):

Chrome rendering

RawTherapee rendering

Firefox rendering

I can’t see any differences between them all. @Morgan_Hardwood, you were right: when opening a non-raw file in RT, the preview shows the real image.

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:

I see too many reds there…

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.

  1. 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).

  2. When you use matrix profiles the relative colorimetric intent is used, no matter the setting.

  3. 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.

1 Like

I agree

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 :cry:

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.

My advice: edit for a colour-managed workflow.

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.

Have a look here Web browser color management guide and here Is Your Browser Color-Managed?

Those articles are almost a decade old, though.

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.

My original profile was a XYZ lut + matrix one, and there isn’t any information about tone response curves.

On the other hand I’ve just quickly generated a new curves + matrix one, and the way I’ve configured the Calibration tab, this is what I get:

  • Red tone response curve: ≈Gamma 2.66 100% (Δ 4.85%)
  • Green tone response curve: Unknown
  • Blue tone response curve: ≈Gamma 2.69 100% (Δ 4.63%)

Honestly I don’t really know what does it mean, but while a bit different from the original profile, Chrome keeps showing a darker image.

Thanks for the links, although they don’t answer my questions :blush:

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: plot y = x^2.2, y = x^2.7 from 0 to 1 - Wolfram|Alpha

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

1 Like

This is what I read in Displaycal website, and that’s what I followed:

So if you are displaying images encoded to the sRGB standard, or displaying video through the calibration, just setting the gamma curve to sRGB or REC 709 (respectively) is probably not what you want! What you probably want to do, is to set the gamma curve to about gamma 2.4, so that the contrast range is expanded appropriately, or alternatively use sRGB or REC 709 or a gamma of 2.2 but also specify the actual ambient viewing conditions via a light level in Lux, so that an appropriate contrast enhancement can be made during calibration. If your instrument is capable of measuring ambient light levels, then you can do so.

So I measured my ambient light and supposedly the program has adjusted the gamma accordingly.

Anyway, when I have a moment I will force it to follow a sRGB TRC, no matter my ambient lighting, and will see what happens


Well, it seems that an appropriate custom profile is what I needed, in the end.

I have just created a new profile (XYZLUT+matrix as curves+matrix wasn’t enough) with:

  • red transfer function ≈sRGB (Δ 0.97%)
  • green transfer function ≈sRGB (Δ 0.97%)
  • blue transfer function ≈sRGB (Δ 0.97%)

That’s not really a match with sRGB, but to my eye is close enough. I won’t bother about it, because looking at an image with a display brighter or darker than mine would cause a bigger visual change than those differences. So is it a success? I think so :smiley: The image looks almost the same in Chrome, FFox and RT with my latest custom profile set system wide.

The sad part is that in the end I’m using a color managed solution to reach a result similar to what Chrome stubbornly keeps rendering, no matter what.

I think about it that I’ve managed to get a custom profile like an sRGB one, but with my own primaries… :thinking:

Colored: custom profile
Dashed grey: sRGB

Note that some applications have issues with LUT+matrix display profiles – RT is fine with them, but there are image viewers/editors which do not play nice with them. Nowadays I use a Single Curve + matrix monitor profile so that I don’t have nasty surprises with some applications. I’ve never used Chrome on my desktop computer so I don’t know if this applies to your situation.

Incidentally I’ve just come across Bruce Lindbloom’s page containing some ICC profiles which allow you to test whether an application respects the vcgt tag.

And here’s some warning about trusting 2D Chromacity Diagrams. DisplayCal allows you to create a 3D rendering of the gamut plot (e.g. in HTML), and it also gives you info about gamut coverage, as well as gamut volume info (which gives another dimension to the depiction of your monitor’s gamut).

Up to now I haven’t seen anything odd in my system, and when I was looking for a color managed image viewer I installed a lot of them, and I ended up using Xviewer (default viewer of Linux Mint, and based on Eye of Gnome).

If I’m not wrong, Gimp is fine if you use an sRGB profile (and mine is close to it).

About browsers, the problem is (was, to me) that Chrome just loads the primaries of the profile, and then does what it wants. About Firefox, if you configure it properly (look at my first post), renders images the same as RT.

So I guess I’m fine right now. But I will take the advice into account. :blush:

Regarding Bruce Lindbloom’s website, I read it in full a few years ago. Really interesting information there. And it’s not too bad reading it again from time to time. Thanks for the links!

I was aware from the beginning that my profiles were not a perfect match with sRGB, and that my display is not a brilliant performer (far from it), but I wanted the most of it, even if there are colors that I’m unable to see onscreen.

I tried creating 3 different curve+matrix profiles, and none gave me a match as close to sRGB as the LUT+matrix I finally installed. Let’s say it from a practical point of view: RT and Ffox don’t render an image as close to that of Chrome without the LUT+matrix profile. The only other way to get an exact match to Chrome rendering is by setting an sRGB profile system wide.

My current profile has these values:

  • gamut volume: 102.7%
  • gamut coverage (sRGB): 94.67%

And here are 3 different perspectives of the 3D rendering of my gamut (colored volume) against sRGB gamut (grey wireframe):

As you can see I have an extended range of oranges, yellows and reds, while suffering a lack of the most saturated and brighter greens, blues and purples. Did I noticed that? No. And I don’t think I will ever notice it unless I put my display next to a proffesional, 100% sRGB coverage display.

And looking at it into perspective, in the image I chose as an example there is a good range of yellows and oranges, and maybe because of that I saw the differences so clearly.

Anyway, thanks for the info.