Compared to normal monitors, wide gamut monitors can display a wider range of colours; you get redder reds, greener greens and bluer blues. They’re useful for some people, because the real world isn’t limited to the colours that your computer monitor can display (and neither are printers).
However, for the majority of people who aren’t into calibrating their monitor with hardware calibrators and worrying about colour profiles when printing on $2000 printers, they have a major downside — the web.
If you have a wide gamut monitor and don’t adjust anything, the colours you see will be stretched to fill the wider colour space that your monitor supports. This might sound okay, but there are problems:
- It can be uncomfortable to view a page with a lot of bright colours — you might often be thinking the designers should have toned it down a bit, but in reality it’s your monitor that’s toning it up and making it much more vivid.
- You’re not seeing pages as the designers intended — they were probably working with a normal colour space (sRGB), and stretching the colours to a wider colour space can make things that were aesthetically pleasing to clash.
- Photos look wrong — the photographer might have a proper colour managed workflow and produces photos that are “just right” on his screen and any other screen that is correctly calibrated. Then you put it in a browser which stretches the colours to look quite different to what was intended.
- Support in browsers for proper colour management is limited, so even if you know what you’re doing, there will be problems.
On Windows, Chrome and IE ignore any colour profiles you might have, and stretch colours in the browser to the full range that your monitor supports, so a rgb(255, 0, 0) red is the reddest red that your monitor can display. The only exception to this is images in Chrome that have embedded colour profiles; Chrome honours these and displays them correctly.
Firefox, my browser of choice, is better, and has a
gfx.color_management.mode option that can be set to 1 to enable full colour management. This is almost ideal, except it doesn’t work perfectly — there are some bugs that cause some things to not be colour managed. Take a look at this:
These nine squares are made red in nine different ways (if you can’t see nine squares, you should update your browser). On my calibrated wide gamut monitor, with Firefox 21 on Windows 8, six of these are displayed correctly as normal red, while three are shown as the exceptionally red red. The ones displayed incorrectly are when the background is set by CSS using linear-gradient and radial-gradient (yet just setting
background-color works fine), and the canvas.
Here’s a screenshot of what I can see, with an embedded colour profile (these might all look the same on your screen):
Here’s another screenshot, but this time converted to a normal colour space (sRGB, but without an embedded colour profile). The colours aren’t the same as my monitor displays, but the difference between the two reds should be visible. Imagine that the three red squares are a really vivid red (as much more red as these ones are compared with the others), and the six dark orange squares are actually as red as those three red squares.
At the end of the day, unless you are paid to use Adobe software, you’re probably better off with a standard gamut monitor. Websites are designed for standard gamut monitors — they look better in a standard colour space — but there are currently no browsers that do colour management properly (Firefox is close).
February 2016 update: Firefox now colour manages the HTML canvas, so now only the CSS linear-gradient and radial-gradient boxes are displayed incorrectly (tested with Firefox 43 with Windows 10). Chrome still only manages the colours of images with embedded colour profiles, and IE/Edge still does nothing.