Color Gamut in Smartphones: Why Bigger isn't Always Better
by Joshua Ho on March 3, 2014 9:22 AM EST- Posted in
- Displays
- Smartphones
- Mobile
Post-MWC, with the launch of at least two of the major high-end flagships in the smartphone space, the basics are becoming increasingly easier to get from OEMs like high DPI displays, the latest SoC, and a plethora of RAM. Therefore, other pieces of the smartphone become increasingly important. One of the most misunderstood parts of the smartphone is a display’s accuracy. Much of this can be chalked up to a lack of existing literature on the subject when it comes to smartphone display quality, which made it easy for subjective evaluation to be the rule.
Of course, even in the PC display space, good displays were incredibly rare because of the race to the bottom for cost. Because reviewers simply didn’t highlight display quality/calibration quality in any objective manner, PC OEMs could cut costs by not calibrating displays and using cheaper panels because people adapted to the color, whether it was accurate or not. The end result was that the early days of the smartphone display race were filled with misinformation, and it has only been recently that smartphone OEMs have started to prioritize more than just contrast and resolution.
Perhaps one of the greatest misconceptions in evaluating display quality is gamut. Many people associate larger gamut with better display quality, but taking this logic to the extreme results in extremely unrealistic colors. The truth, as always, lies somewhere in between. Too large or too small of a gamut makes for inaccurate color reproduction. This is where a great deal of the complexity lies, as many people can be confused as to why too large of a display gamut is a bad thing. This certainly isn't helped by marketing, which pushes the idea of greater gamut equating to better display quality.
The most important fact to remember is that all of the mobile OSes are not aware of color space at all. There is no true color management system, so the color displayed is solely based upon a percentage of the maximum saturation that the display exposes to the OS. For a 24-bit color display, this is a range of 0-255 for each of the RGB subpixels. Thus, 255 for all three color channels will yield white, and 0 on all three color channels yields black, and all the combinations of color in between will give the familiar 16.7 million colors value that is cited for a 24-bit display. It's important to note that color depth and color gamut are independent. Color gamut refers to the range of colors that can be displayed, color depth refers to the number of gradations in color that can be displayed.
Reading carefully, it’s obvious that at no point in the past paragraph is there any reference to the distribution of said colors. This is a huge problem, because displays can have differing peaks for red, green, and blue. This can cause strange effects, as what appears to be pure blue on one display can be a cyan or turquoise on another display. That’s where standards come in, and that’s why quality of calibration can distinguish one display from another. For mobile displays and PC displays, the standard gamut is sRGB. While there’s plenty to be said of wider color gamuts such as Adobe RGB and Rec. 2020’s color space standards for UHDTV, the vast majority of content simply isn’t made for such wide gamuts. Almost everything assumes sRGB due to its sheer ubiquity.
While it may seem that a display with color gamut larger than sRGB would simply mean that sRGB colors were covered without oversaturation, the OS’ lack of colorspace awareness means that this isn’t true. Because the display is simply given commands for color from 0 to 255, the resulting image would have an extra saturation effect. Assuming that the saturation curve from 0 to 255 is linear, not a single color in the image would actually be the original color intended within the color space, and that’s true even within the color space. This is best exemplified by the saturation sweep test as seen below. Despite the relatively even spacing, many of the saturations aren't correct for a target color space.
On the flip side, another issue is when the display is constrained to sRGB, but the OEM applies a compression of saturation at the high end to try and make the colors "pop", even though it too reduces color accuracy of the display, as seen below on all but the magenta saturation sweep.
Ultimately, such quibbles over color gamut and the resultant color accuracy of the display may not be able to override the dominant discourse of subjectively evaluated color in a display, and many people prefer the look of an oversaturated display to that of a properly calibrated one. But within the debates that will undoubtedly take place over such a subject, it is crucial to keep in mind that regardless of personal opinion on display colors, color accuracy is a quantitative, objective analysis of display quality. While subjectively, one may prefer a display that has a color gamut larger than sRGB, objectively, such a display isn't accurate. Of course, including a vivid display profile isn't a problem, but there should always be a display profile that makes for accurate color.
57 Comments
View All Comments
Darkstone - Monday, March 3, 2014 - link
Are you sure about the browser support? The following site has a few images with different color spaces:http://diglloyd.com/articles/guides-howto/howto-co...
Both firefox 27 and IE 11 display all tagged images correctly.
User.Name - Monday, March 3, 2014 - link
Yes, most browsers will now support tagged images. (though I'm not sure that they all support ICC v4 yet? http://color.org/version4html.xalter )The main issue is that they display untagged images and HTML colors at the display's native gamut, when the rendering intent for untagged images or HTML colors should be sRGB.
Firefox has a preference which enables this ( gfx.color_management.mode = 1 ) but no other browser does, as far as I am aware.
JoshHo - Monday, March 3, 2014 - link
The hardware should be capable of supporting larger than sRGB gamuts, but after calibration for sRGB mode it should be constrained closely to sRGB.JoshHo - Monday, March 3, 2014 - link
I do agree that it's time to start moving to larger color gamuts but it's important that it's standardized. The current situation with wide gamut panels in mobile is anything but standardized.User.Name - Monday, March 3, 2014 - link
We already have a solution. The web is effectively designed for sRGB and should be treated as such. Anything using a wider gamut should be tagged with the appropriate color profile. (Adobe RGB photos etc.)bengildenstein - Monday, March 3, 2014 - link
The Galaxy S5 purportedly has a dedicated image processor (presumably ultra-low power) specifically for this task. It is used to modify the gamut to improve perceived colour stability in response to coloured ambient light. As with the Galaxy Note 3, I suspect that the S5 is also much more sRGB accurate than its predecessors using an OS settable mode.The negative reporting of large gamut on mobile is no doubt in direct response to Samsung OLED screens, which historically haven been over saturated. Ironically, it seems that Samsung is actually doing something about it, but these improvements get virtually no attention in the press. Additionally, other aspects of mis-calibration (ie. media creation) go entirely unmentioned.
vdidenko - Monday, March 3, 2014 - link
Kind of expected for Android, given Google attitude towards color profiling even on a directly commercial venue - YouTube. While at Google I/O'13 I did not find anyone at the YouTube stand (talked to 4 people) who would understand why is it needed. And path-to-profit with YouTube proper color supposedly very direct. And yet another question is how the remote display options, like Chromecast should receive and treat profile information.Stuka87 - Monday, March 3, 2014 - link
So then is this true for all phones?It would seem some phones must support it. Because in phone reviews, some phones have horrible color accuracy (Like Samsung Phones), while some have pretty good accuracy (Like iPhones). Is this because the displays have different gamut ranges, or because the OS's handle them better?
LordOfTheBoired - Monday, March 3, 2014 - link
Two different issues. Gamut and accuracy are not the same thing.You can have a small gamut display that's incredibly inaccurate, or a wide gamut one that's spot-on.
Gamut is how much range there is in the colors you can ask of the display, accuracy is how close the color you ask for will be to the one you get.
The original Macintosh has an EXTREMELY limited gamut, as it can only do solid black and solid white. But it's also extremely accurate. Blacks are black, whites are white. No one ever asked for black and got a gray instead.
But whatever the display, the software needs to know how it behaves so it knows what to ask of it.
And that's where we are now. Android has no idea there ARE different kinds of displays. Accurate or inaccurate, wide gamut or narrow gamut, it just sees a display.
And then manufacturers intentionally mess up the accuracy to get brighter colors.
(Which still pisses me off. I had a quite nice phone display, and when I upgraded, I couldn't get a phone that wasn't oversaturated and cartoonish.)
SeannyB - Monday, March 3, 2014 - link
As a wide-gamut user on a Windows desktop, you'll get plenty of angst from me on the state of "color-awareness" on part of software/OS. The Windows shell itself isn't usefully color-aware... ideally it would render at sRGB, and force all non-color-aware software to remap to sRGB as well. Firefox, as mentioned elsewhere, is the only browser that's renders the web (CSS, untagged images, etc.) at an "assumed" sRGB, with exceptions for tagged graphics (e.g. AdobeRGB JPEGs), but unfortunately this is a hidden toggle and not the default. MPC-HC and Irfanview are color-aware if I manually load my monitor profile into them. For Android, we know that color management simply doesn't exist on it, which is a shame because Android is at the front of the OLED evolution. It's doing it wrong and setting a bad example.