![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
About wide gamut - since some details posted went uncorrected..
Generally a standard gamut sRGB screen produces reds which are more orange, greens which are more yellow, and blues which are slightly more purple in comparison to a wide gamut display. The wide gamut screen has better colours, and it's particularly noticeable on the reds and greens. This is always a good thing. The problems come from how a wide gamut screen implements its work-arounds to display sRGB colours.
A wide gamut screen NEEDS a way to display sRGB colours accurately because almost all available content, whether it's games, movies, applications, or websites, are designed for an sRGB gamut since that's what the vast majority of displays use, and so that's the palette of colours they've come to expect.
Most IPS screens (including wide gamut ones) have 8 bit panels. This means they can display 256 unique colour values for red, green, and blue in their palette (256 x 256 x 256 = 16.7 million colours). The problem comes when an application tells your display to show a value of, for example, red 255.
Red 255 in a wide gamut displays colour palette is a much more vivid (almost glowing) red than red 255 on an sRGB screen. As said, the sRGB's red 255 also has a bit more orange in it. This means the wide gamut display can't just turn the red value down to be less bright, it must also change other values. That means that an SRGB value of Red 255 Green 0 Blue 0 might actually be shown on the wide gamut display as Red 220, Green 50, and blue 24.
Colour management is a way of trying to deal with this.. When you feed an application the correct ICM colour management profile it becomes aware of what range of colours your screen can actually show. This way, when it sees sRGB content, the application says "ok, you are sRGB Red 255, so I know that I should translated this to R 220, G 50, B 24 so that the wide gamut display shows the colour as it was intended".
Sounds good so far? Well, think about it - In order to display that Red 255 it had to chop off 35 red values, add 50 green values, and 24 blue values. This means that your 8 bit wide gamut panel (256 x 256 x 256) can't actually use all of those available values. It has to effectively reduce the bit depth of your screen when displaying sRGB content.
So, when viewing sRGB content from a colour managed application, your 8 bit wide gamut screen is actually using millions of fewer values than what it can display. It also means an ordinary sRGB gamut screen is showing all 16.7 million colour values when viewing sRGB content, whilst a wide gamut 8 bit panel must use millions of fewer colours in order to reduce its colour palette to make it look like the sRGB colour palette.
The wide gamut screen dropped some unique colour pixel information in this process and had to approximate it to the nearest value, since it's now trying to squeeze those 16.7 sRGB million values into a smaller colour space than its own 16.7 million wide gamut values.
Even though you will then have accurate colours, and it doesn't look too bad at all, it's come at a price - your wide gamut screen is now showing the picture with (used just for example) 12 million colours, whereas the sRGB screen sees all 16.7 million unique colours. Depending on the content, even when the emulation is done really well, I still think you can sometimes see a bit of difference. The emulated sRGB is somehow slightly more washed out. That's why you are better to avoid wide gamut displays when they contain 8 bit panels.
When a panel is 10 bit native things change. All of a sudden it has 1024 unique red, green, and blue values. This means, if you have to emulate a colour space like SRGB, you can squeeze the content into the smaller colour space but still retain 256 unique values for red, green and blue, just like an 8 bit sRGB panel has. Even though it's still using a smaller colour space than the display can show, because the display can show so many unique values (1024x1024x1024 = Over 1 billion values), it means that that squeezed colour range still easily has access to 256 values for emulated sRGB red, green and blue.
Of course, you're still at the mercy of how well a display might emulate the sRGB colours and, if using colour management, the quality of the ICM file matters a lot too, since that is used as the basis for how the application should translate colours. A poor ICM file will not only make images look worse, but may also introduce things like visible banding when emulating a smaller colour space. EG Dell initially had many problems with their early U2410 ICM files, which produced poor quality images and banding. However they really improved this with later versions simply by improving the quality of the ICM file.
The bottom line is, for most people, wide gamut should probably be avoided on 8 bit panels. On native 10 bit panels it becomes much less of an issue provided the display implements its sRGB emulation well, or the ICM file is of good enough quality that it allows colour managed applications to produce good results when emulating a different colour space.
I know all this seems confusing at first to some people, but it's not complicated when you get your head around it.
Generally a standard gamut sRGB screen produces reds which are more orange, greens which are more yellow, and blues which are slightly more purple in comparison to a wide gamut display. The wide gamut screen has better colours, and it's particularly noticeable on the reds and greens. This is always a good thing. The problems come from how a wide gamut screen implements its work-arounds to display sRGB colours.
A wide gamut screen NEEDS a way to display sRGB colours accurately because almost all available content, whether it's games, movies, applications, or websites, are designed for an sRGB gamut since that's what the vast majority of displays use, and so that's the palette of colours they've come to expect.
Most IPS screens (including wide gamut ones) have 8 bit panels. This means they can display 256 unique colour values for red, green, and blue in their palette (256 x 256 x 256 = 16.7 million colours). The problem comes when an application tells your display to show a value of, for example, red 255.
Red 255 in a wide gamut displays colour palette is a much more vivid (almost glowing) red than red 255 on an sRGB screen. As said, the sRGB's red 255 also has a bit more orange in it. This means the wide gamut display can't just turn the red value down to be less bright, it must also change other values. That means that an SRGB value of Red 255 Green 0 Blue 0 might actually be shown on the wide gamut display as Red 220, Green 50, and blue 24.
Colour management is a way of trying to deal with this.. When you feed an application the correct ICM colour management profile it becomes aware of what range of colours your screen can actually show. This way, when it sees sRGB content, the application says "ok, you are sRGB Red 255, so I know that I should translated this to R 220, G 50, B 24 so that the wide gamut display shows the colour as it was intended".
Sounds good so far? Well, think about it - In order to display that Red 255 it had to chop off 35 red values, add 50 green values, and 24 blue values. This means that your 8 bit wide gamut panel (256 x 256 x 256) can't actually use all of those available values. It has to effectively reduce the bit depth of your screen when displaying sRGB content.
So, when viewing sRGB content from a colour managed application, your 8 bit wide gamut screen is actually using millions of fewer values than what it can display. It also means an ordinary sRGB gamut screen is showing all 16.7 million colour values when viewing sRGB content, whilst a wide gamut 8 bit panel must use millions of fewer colours in order to reduce its colour palette to make it look like the sRGB colour palette.
The wide gamut screen dropped some unique colour pixel information in this process and had to approximate it to the nearest value, since it's now trying to squeeze those 16.7 sRGB million values into a smaller colour space than its own 16.7 million wide gamut values.
Even though you will then have accurate colours, and it doesn't look too bad at all, it's come at a price - your wide gamut screen is now showing the picture with (used just for example) 12 million colours, whereas the sRGB screen sees all 16.7 million unique colours. Depending on the content, even when the emulation is done really well, I still think you can sometimes see a bit of difference. The emulated sRGB is somehow slightly more washed out. That's why you are better to avoid wide gamut displays when they contain 8 bit panels.
When a panel is 10 bit native things change. All of a sudden it has 1024 unique red, green, and blue values. This means, if you have to emulate a colour space like SRGB, you can squeeze the content into the smaller colour space but still retain 256 unique values for red, green and blue, just like an 8 bit sRGB panel has. Even though it's still using a smaller colour space than the display can show, because the display can show so many unique values (1024x1024x1024 = Over 1 billion values), it means that that squeezed colour range still easily has access to 256 values for emulated sRGB red, green and blue.
Of course, you're still at the mercy of how well a display might emulate the sRGB colours and, if using colour management, the quality of the ICM file matters a lot too, since that is used as the basis for how the application should translate colours. A poor ICM file will not only make images look worse, but may also introduce things like visible banding when emulating a smaller colour space. EG Dell initially had many problems with their early U2410 ICM files, which produced poor quality images and banding. However they really improved this with later versions simply by improving the quality of the ICM file.
The bottom line is, for most people, wide gamut should probably be avoided on 8 bit panels. On native 10 bit panels it becomes much less of an issue provided the display implements its sRGB emulation well, or the ICM file is of good enough quality that it allows colour managed applications to produce good results when emulating a different colour space.
I know all this seems confusing at first to some people, but it's not complicated when you get your head around it.
