Displaying images. Colour management, sRGB and ICC. And when something fails.

Update This post started as description of a problem with displaying some files in FireFox and Chrome, but has been transformed to a more general post about sRGB, ICC, CMS and what happens if the browser gets it wrong…

It all started when I detected that most colours in some web-files got severely distorted when displayed in FireFox and Chrome on my system. Both JPG and PNG files were affected


If you see the first one of these two squares blue_1 and blue_1_removed_srgb substantially different from the second clear blue, your CMS system have similar issues…
The first one is supposed to be a standard blue, the second is blue LEDs on your monitor only.


We all know (I hope) that the eyes can be tricked to believe it sees any colour, if presented by a suitable combination of Red, Green and Blue light.

And this is exactly what a digital display does. But the big issue is WHAT Red, Green and Blue colours the LED used have.

To make things look the same sRGB (s=standard) have been created. The point with this is not to describe how much each physical LED shall be lit. Instead it describes a colour that is desired to be displayed. So when a screen has a different colour space than sRGB, it will take a transformation blending the LEDs in a suitable combination to show the sRGB colours as good as possible. Assume a wide gamut display with the Blue LED beyond the sRGB, then a little green and or/red LED light would be needed to get the standard Blue that was intended.

To this transformation the screen manufacturer deliver a “Display Profile” (that is an .icm file) that is used in the transformation.

Any difference you see in the two blue squares blue_1 and blue_1_removed_srgb reflects exactly this. The first is tagged as sRGB, the second request your display to turn on the Blue LED only. But IF a wrong transformation is used you will get weird results for the first one, with a too big difference, and that was what I had.

At first the two colour-charts in the above image might look close to identical, but if you click to enlarge, you will see that especially Blue got Magenta

Under each colour in the original to the left is in black printed the RGB value of the colour (in hex)

The few colours that were NOT affected in the right image are marked with green, all the other have the RGB of the transformed colours in red, under what the sRGB value was.

Almost all colours were altered by the transformation, but many really substantially.
The black to grey were ‘only’ modified in brightness, and almost all only slightly.

Here are the colour-chart as two test-files, with and without the sRGB tag. If you view them in a system that does not support sRGB (or on an exact sRGB display) they would look exactly identical, but if you view them in a system with a CMS (Colour Management System) that should handle sRGB they will look slightly different. But if the transformation does not use the correct display profile, they might look VERY different


Here is a way to create them:

  1. Open MS Paint, Select New.
  2. Draw (or paste in) any image, and Save As a PNG (This is the sRGB tagged file)
  3. Save As a BMP 24 bit (File not used)
  4. Save As a PNG again to another name (This file is without the sRGB tag)

Here are two two tiny 16×16 pixels squares samples made by this recipe: blue_1 and blue_2 that be used to dig into the difference.
If I simply remove all the 13 bytes for the sRGB tag from the first I get this one: blue_1_removed_srgb that looks exactly like the second one (though not binary identical as a file)

Note also that a file created with .NET standard bmp.Save(fn, System.Drawing.Imaging.ImageFormat.Png) has the sRGB tag set by default.

The conclusion of this:

If you want to display a colour in an exact way, it could be a good idea to use sRGB. But if you just want to have clear colours that might differ between monitors, you should omit the sRGB tag, as these files are faster to handle, and also works with older programs ignoring or not supporting sRGB. As an example my eye-resolution test. Here the actual colours are not that important, but it is important that it turns on exactly one colour LED to get crisp lines.


What was wrong and how to fix it

I was very puzzled that sRGB files on my system were shown wrong in both FireFox and Chrome, but was displayed correct in e.g. Edge/IE11 and “Picture Viewer”

After a long road of searching (see over at https://bugzilla.mozilla.org/show_bug.cgi?id=1135380), it turned out to be some issue in Windows where FireFox (and Chrome) did not get the correct info on the display profile to use on sRGB (or icc) taged files. They used something with a much wider gamut, and the blue LEDs much further from the sRGB blue than they actually are on my display.

The solution was, from FireFox

about:config , accept the warning and find and change
gfx.color_management.display_profile to the relevant string for your monitor, default blank
(Close and reopen browser)

And it was fixed!! Now the two charts display with a SLIGHT colour difference as would be expected.

Actually even setting it back to blank it still works, and even more surprisingly it got fixed in Chrome too, so it must be something that was wrong that got right in windows by this?!?!?

You MIGHT also need to fiddle with the display profile in windows, I tried that yesterday, to no visible effect even after booting, but it might be the combination that solved it…

I can see that in my system, the icm is now referred to in four places in the registry

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ICM\ProfileAssociations\Display\{4d36e96e-e325-11ce-bfc1-08002be10318}\

If this might help anyone having the same issues.


Here is how I see the result after the fix, note that the sRGB 0000FF clear blue get a bit of Green and even less Red added to it 0921FD
And yes it is the Faithful Ricoh that has done the macro again – Click to see the full crop (sorry about the dirt on the screen over some of the second square).


So after the fix, the chart is transformed like this (and looks fine on the monitor). As you can see by expanding there are still changes almost everywhere, but less drastic changes.




Note that this is NOT just an academic issue. I have found that a big site like dpreview.com have problems with their galleries ALL the way back to year 2000!! The problem is that they tag their reduced files as sRGB even if the original is not, so these might display with substantial difference – especially if your browser gets your profile wrong, or the monitor got a wide gamut range.

Here a screenshot of what started the whole thing. Chrome with reduced file and loupe-inserted part of the original, and another with the full image


(These are taken from the gallery from the article on samples from the Google Pixel camera, Here the original from google)


Apart from the sRGB profile, a specific colour profile (ICC) might be specified in the file. And if your viewer does not have a CMS these could be displayed very very wrong…
Here is a test page to check if your browser has a CMS and the display profile in use for your monitor is reasonably close to correct

After the issue has been fixed, FireFox, Chrome and “Windows Photo Viewer” shows the yellow car identically. And Skitch Tool Agrees with Edge on a slightly more vivid red banner.

But Irfanview (that is supposed to support ICC), MS Paint as well as MS Photo display it as purple.



I’m on a Thinkpad Yoga (type 20CD) with a Intel HD Graphics 4400, and I had the issue on both the build in FHD monitor and the external QHD Phillips BDM4065UC connected through a OneLink Pro using DP1.1. I’m on Win X AU [Version 10.0.14393]. Though the issue was most clear on the external.

The colours printed in red in the chart are probed programmatically from a screen dump from the external monitor.

The monitor allow individual RGB adjustments, and if I tone down Red and Green to 80%(!) of the blue the distorted colours in the chart begins to look less crazy (though of course with a wrong white point), so a profile with a much wider gamut than both sRGB and the monitor must have been assumed.