AdobeRGB has a much larger gamut than sRGB. Even if we can’t control the gamut on the Nixeus VUE 30, moving to a larger gamut target should result in smaller errors overall. If this improves things this might work well for those doing color work, as they may want the larger gamut anyway. For normal use like gaming or web browsing, very few applications use AdobeRGB so it won’t be improved.

  Post-Calibration, 200 cd/m2 Post-Calibration, 80 cd/m2
White Level (cd/m2) 199.7718 81.959
Black Level (cd/m2) 0.3455 0.1473
Contrast Ratio 578:1 566:1
Gamma (Average) 2.1975 2.351
Color Temperature (missing) 6521K
Grayscale dE2000 0.8217 0.8328
Color Checker dE2000 1.3821 1.5443
Saturations dE2000 1.5282 1.6211

Besides the gamut, I left every target the same as with our sRGB calibration. As we can see, we get far, far better results for the color than we did before. The performance for the 80 cd/m2 target has also improved a lot with the grayscale. That shouldn’t have been affected, but it could be a better calibration run, as sometimes the software does better than other times. The visible difference with an average dE2000 of 1.33 vs. 0.83 for the grayscale is pretty minimal and hardly noticeable in real life.

The big change is the colors. While Red still falls outside of the AdobeRGB gamut, Green, Cyan and Yellow all line up nearly perfectly now. Magenta is still affected by the Red, but even those two colors are much closer to accurate than before. A quick look at the saturations table shows that the dE2000 stays below 3, or the visible error level, for every color except for highly saturated Red and Magenta. The 96-point Color Checker chart shows the same results, with those highly saturated red shades providing the only errors that really fall into the unacceptable realm.

One key chart to look at that I’ll pull out here separate from the gallery is the Delta Color Error on the Color Checker chart. As you can see, the Red shades are highly affected by an over-abundance of color here. If I were to pull out the other charts that break down the individual color errors, Delta Luminance and Delta Hue, you would see that those errors are virtually non-existent. The issue is that red has too much saturation, but the light level and the tint on it is correct.

Moving to the AdobeRGB target really improved the performance of the Nixeus VUE 30, but that isn’t without a caveat or two. Most people don’t use AdobeRGB color, and most applications don’t support the larger gamut. For those applications you are still going to see overly saturated colors on a regular basis and this won’t correct them. However, for people that can use AdobeRGB, color accuracy might be more important to them than it would be for someone that doesn’t use it.

If you are only gaming or doing general office productivity on this display, you might not care about the over-saturated gamut. If you are going to be doing photo work you certainly would, and hence this AdobeRGB target might solve your issues. If you want to have accurate colors on the Nixeus, this is the only way you can really get there, and you’ll likely know if this will work for you.

sRGB Measurements Display Uniformity
Comments Locked

95 Comments

View All Comments

  • DanNeely - Wednesday, August 21, 2013 - link

    Read before you comment. This was answered above; there's no off the shelf hardware to do so at 2560.
  • Sivar - Tuesday, August 20, 2013 - link

    "Viewable Size 20""
    Typo -- please fix.
  • abhaxus - Tuesday, August 20, 2013 - link

    it's time to end this farce and stop posting input lag numbers that are not at native resolution. I've bought two monitors in the last 8 months (a 23" eIPS Asus and a 27" Qnix QX2710 from Korea) and got NO help from these Anandtech reviews, due to the ridiculous notion that input lag at 1080p is somehow comparable to what it would be with no scaling. Either don't put the number up there, or do the tests at native res.
  • JarredWalton - Tuesday, August 20, 2013 - link

    Unless the scaler totally deactivates and thus doesn't contribute to lag, running native won't be any less laggy. For most displays, the presence of a scaler is an all or nothing thing. The old Dell 3008WFP had much worse lag than the 3007WFP because it had multiple inputs and a scaler. Unless something has changed, I wouldn't expect native resolution to be less laggy.

    As I noted above, however, the problem is in testing for input lag at native. We used to compare to a CRT, which meant we were limited to CRT resolutions. Now Chris is using the Leo Bodnar lag tester...which has a max resolution support of 1080p. Until someone makes one capable of testing native 4K and WQXGA, Chris doesn't have a way to test input lag at native on these displays.
  • cheinonen - Tuesday, August 20, 2013 - link

    Adding to what Jared said, testing on displays that offer both 1:1 mode and a scaling stretch mode, I typically see only 1-2ms of delay difference between them.Most monitors are using cheap, fast scalers that doesn't add that much lag. Things like color management and other features, which you'll see in more displays now, add far more lag because that is more intensive work to do.

    Believe me, if someone makes a lag tester that does more than 1080p I'm buying it. Otherwise buying a scope for a single measurement is just cost prohibitive.
  • HisDivineOrder - Tuesday, August 20, 2013 - link

    Seems inevitable that the 2560x1600 will remain mostly niche with 2560x1440 becoming the go-to resolution in the post-4K world that we'll be soon living in. Monitor makers will be selling these 1440p displays hand over fist when people become convinced they want a high resolution display but find the pricetag on 4K to be out of this world and they come back down to Earth, still wanting a higher resolution display than 720p/768p/1080p.

    I doubt they'll make 1600p the go-to resolution, so they'll split the difference and go with 1440p to maximize profits (the exact reason they went to 1080p instead of 1200p).
  • Sabresiberian - Tuesday, August 20, 2013 - link

    Frankly, I think about sRGB the same way I think about TN and 16:9 - they are low-quality standards that I would like to see fade away from mainstream monitors. While I agree that any monitor aimed at said mainstream should be sRGB capable, I can't help but think it is really time for the standard to be raised. It is possible to give us full AdobeRGB without breaking the bank - as is proven here.

    This isn't an LCD thing, of course, sRGB pervades the industry all along the path of software and hardware. But, not many people are demanding higher quality color reproduction, so when is it going to change, if ever?

    Well, I'll say it - sRGB is a low-quality standard, and it is time we moved on.
  • JarredWalton - Tuesday, August 20, 2013 - link

    You're right, but of course 99% of laptops can't even do sRGB let alone AdobeRGB or NTSC, and laptops are now outselling desktops. I've been using a high gamut HP LP3065 for years, though, and while I notice the oversaturation at times, when I'm working with many imaging programs (Photoshop, even most browsers now, and MS Photo Viewer) appear to recognize AdobeRGB properly.
  • SeannyB - Tuesday, August 20, 2013 - link

    I hope some day we'll simply have color management on all OSes (namely Windows and Android), and not just OSX. I'm living with a calibrated and profiled extended gamut 1600p monitor in Windows 7, and it's tough. Windows 7 doesn't assume/remap its shell to sRGB, or any other apps. Only certain software like Adobe's, and a few others with effort (Irfanview, Firefox, Media Player Classic Home Cinema) are "color aware". Google Chrome remaps correctly when viewing JPEGs with colorspace tags, but everything else in that browser is oversaturated. (It doesn't assume sRGB from untagged images and web colors.)

    I think a future of ubiquitous color management will have to happen in a world of ubiquitous OLED displays. That's a future that continuously seems over the horizon.
  • ZeDestructor - Tuesday, August 20, 2013 - link

    There are preferences in FF that sets default colourspace to sRGB (I used it on and off, depending on my mood), so only correctly tagged pictures are rendered with wide gamut.

    For the windows shell, it doesn't matter, and lastly, for the programs, well, Windows' integrated picture viewer is colour aware, as I was surprised to discover. Its all there where it should be. You don't really care what your UI elements look like, but pictures and video you do care.

Log in

Don't have an account? Sign up now