"SW: It has a Samsung WQHD AMOLED panel. We have spent a lot of time tuning the white-point and color gamut for these panels – hope you will enjoy the accuracy of the display."
"Yep, confirmed: Nexus 6P has the latest generation panels from Samsung. One of things we deeply care for is the quality and accuracy of the display through which all of us connect with the stuff we care about. We created a very tight spec (white-point temperature, delta-E variance, color-space accuracy, etc) for the 6P WQHD AMOLED panel, so it was important that we use the most cutting edge panel technology available."
That sounds good, and especially after +Dave Burke claimed on stage that the display was "very vibrant", this promise of color accuracy will need independent verification 😉
Note that this answer doesn't specify to which color space or white point they decided to conform.
This display will show near exclusively content encoded to sRGB standard (which specifies the white point and RGB primaries, gamut and electronic-optical transfer function – aka EOTF aka gamma curves).
In case the display colorspace they chose is wide gamut, any color accuracy claim is automatically moot given the fact Android doesn't support color any management at the moment.
There are various ways to calibrate a wide gamut AMOLED to conform to sRGB specifications tho: using the panel's factory calibration in conjunction with either:
– the panel's color tuning
– Qualcomm Mobile Display Controller image processing, with basic colorspace conversion or 3D LUT
– the GPU (which taxes some GPU power however)
#supercurioBlog #display #color #calibration #Nexus
Hi, I’m Hiroshi Lockheimer, here at Google with the team that build Nexus 5X & 6P…Ask Us Anything! • /r/IAmA
Yep, confirmed: Nexus 6P has the latest generation panels from Samsung. One of things we deeply care for is the quality and accuracy of the…
17 thoughts on “Nexus 6P AMOLED panel info”
Can't wait to finally have a true Nexus. No cutting corners. +Marques Brownlee will appreciate that camera, build quality, battery & screen on his review. 😁
I was waiting for your post on this matter. 😀
All I want to hear from Google is we calibrated for D65, 2.2 to 2.3 gamma and hitting accurate color points. Also hitting higher nits for daytime viewing. All this other stuff is fluff.
+Charles Sewell hehe exactly.
It's a very tight spec; but which are the targets in this spec? unspecified 😛
+François Simond Google is never clear when they mention something.
+Charles Sewell PR / Lawyer talk even by engineers yeah.
+François Simond Yup.
Nobody is going to calibrate to D65 by default. Normal humans just don't like it on a smartphone. 7800K has been the magic number for me in my recent adventures with a shiny new PR spectroradiometer, with D65 as a user selectable option. Most ODMs in Asia are going into the 9000K range which is worse IMHO.
+Steve Kondik content colors are encoded for D65 by content creators: photographers, movie studios.
Choosing another white point means breaking the math involved in the color science used to encode input colors into values, which are supposed to be decoded to the same colors as output.
Now, a lot of instruments get what D65 is completely off depending on the screen technology, due to different spectrum emitted and weakness of cone response characterization in old models.
The CIE 1931 color matching functions work for CRT monitors, and sRGB and it's white point have been modeled after them.
Thing is using the same color matching function on white LED LCDs or AMOLED can give completely different results.
D65 is fine because it really is "Daylight white", but most instruments in their default configuration are incapable of color matching white to look like this daylight white current screen technologies.
Find a good old CRT monitor and adjust it's white to measure at D65 and you'll see what I'm talking about.
I'm pretty sure that if you arrive at 7800K as sweet spot with your shiny meter, it's misleading you by a lot due to inadequate color matching function.
(if it's really shiny you can probably choose which kind of CMF to use)
Also, it's impossible to characterize a color by a single temperature value: a color is at leat yx coordinates.
A temperature is an infinite number of different colors on a linear axis on a Yxy graph (essentially, it tells how "warm" a color is but not which color it is, being very little influenced by the amount of green while green intensity is what our eye is the most sensitive to)
Oh no, I am calibrating to D65 in what I'd consider near perfection. Then manually readjusting the destination to a higher white point. Its less about science at this point than a "whiter white" which is what nearly every single person I've done an a/b test with preferred. I implemented a new feature which allows you to choose from multiple calibrations actually- the "perfect" one, the adjusted white point version, a "Samsung style" version with boosted saturation for people who like that, and a couple of other specialty modes (depending on device display gamut, etc). You'll see it on upcoming devices from us.
Everyone perceives the world differently. Still learning, but I've been geeking out over color a lot lately 🙂 Would love to get a certain device over to you to hear your thoughts as soon as I'm actually able to.
+Steve Kondik that perception of what's "whiter" will vary depending on indoor / outdoor, the weather, the time of day, elements around reflecting light, habits, age, mood, genetics, the influence you have on subjects..
That's why there's color science and standards defining this with math instead of a very subjective methodology.
Cameras encode real colors into RGB colors in sRGB which is based on the D65 white point.
This is why I said that the sensor, like every other out here (fancy or not) is likely misleading there.
On what you said there's two aspects:
– the color matching function, which transforms a spectral reading into XYZ values.
– the correlated temperature reading which transforms a CIE 1931 XYZ color into a 1 dimensional value, because 7800K is really cold already (and says nothing else about all the actual colors corresponding to 7800K)
Imagine you ask someone to calibrate your display's white to 7800K. This person could come up with completely different colors that would all be valid if the only metric specified is the CCT.
+Steve Kondik okay I just read your edit (seems you have the same habit as me, doubling the message length in the process 😉)
Yes it's possible to adjust the destination white point while keeping a perceptual color accuracy.
It can't be done by only changing the RGB components intensity, but a valid approach would be to, just like Photoshop does or DNG conversion color model describes, use the Bradford chromatic adaptation.
Yeah but our eyes don't work like cameras- they are really good at compensating for environmental conditions and are forgiving of imperfection. Cameras are not. And neither are photographers 🙂 My current research is around the use of actual RGB light sensors to affect display quality on the fly. Its been interesting and actually productive 🙂
But regarding calibration, the sensor and software isn't telling me that 7800K is correct. Quite the opposite. The adjustment is done with a 5×5 matrix that is based on data from the baseline profiling on top of the D65 calibration. Its a conscious, subjective change that purposely defies the science because humans think it just looks better. This is why I say that no vendor will ship a true D65 white as the default, people just prefer it a little cooler. Most say the "perfect" calibration looks washed out or too yellow. The science says they are wrong, and the "wrong" version is unsuitable for some applications, but that's why we have options 🙂
Samsung's "cinema" mode on the S6 got a lot of praise for it's accuracy, but most people did not prefer it to the default which at pure white sits at around 8000K. People are crazy. You have to deal with the human factor for a consumer product though.
+Steve Kondik I'm careful when anyone mentions D65 and white points now after realizing how wrong both my meters were on a few different displays.
My little story is that I implemented newer color matching functions – so what transforms spectrum into XYZ values, based on newer average cone response research in my software.
It should have solved the discrepancy issues I had when calibrating the white point of my various white RGB LCDs and desktop monitor using CCFL backlight.
Except it didn't, and color matching all of them is giving even more different white (really wayyy off) to my eyes with those "better" color matching functions than the old CIE 1931 one.
After this disappointing and inconsistent results, I can conclude that eight my i1pro spectro is off (it's old: likely) or that the color matching functions are not that great either (possible)
So as a result I went back to a CRT monitor as the whole current standard it bases on them, calibrated it to D65 with a X-Rite i1 Display Pro colorimeter and i1Pro spectro using CIE 1931 color matching and both are quite close.
Turns out D65 on a CRT is not warm. Like not at all.
Since then I'm calibrating whites to match this reference.
For instance, on a Nexus 5 the i1 Display Pro XYZ CCT turns into 7300K, and i1Pro 7500K.
That's why I get where you're coming from with your 7800K sweet spot. But if a bunch of people say it's the white they prefer, well the white you manufactured might actually be close to the real D65, who knows?
This should be simple but instead super confusing and there's a lot of experiments I'd like to do with a reference grade spectrometer and my own math to try to make more sense of all this.
Sorry if I didn't explain well in earlier messages.
My current stance is that D65 is likely the best choice, because it really does characterize and represent the natural daylight and all the color math of today's content encoding is based on it, so changing this reference breaks the math.
However I can only observe how incompetent every sensor I've tried so far is at color matching the white between a CRT, and today's display technologies, even with the latest and greatest academic research model or X-Rite/SpectraCal spectral corrections on the i1 Display Pro.
So what the hell! What are you supposed to do after proving that can't trust the instruments on this primary function 😛 turns out its not as simple as it's naively promised.
Too yellow: I see what you mean here as well, and those people are right eventually (and I was wrong before 😁) several sensors today calibrate for a white that's too orange / yellow several mobile LCDs, which doesn't correspond to natural daylight white or CRT D65 white.
And sure +Steve Kondik, you know my address, go ahead ☺
BTW I plan to make videos to talk about all this, as text doesn't really cut it and I'm sure you can all read my frustration with this, linked to so much inconsistency and lack of answers – for now ^^.
Same +Steve Kondik we could talk over voice or videos. It might work better than me trying to dump months of experiments results in this comment section ^^.
+François Simond +Steve Kondik thanks for the geek out session! Love reading in depth talk of displays and colour accuracy.
The instrument I've been using is this: http://www.photoresearch.com/current/pr655.asp
It's one of only two devices that Qualcomm supports with their new tools. The price tag is kind of scary but the results are really good. Only downside is that it has to be used in total darkness for profiling. In addition to the QC tools, I've got a growing stack of scripts that use Argyll to do things like generating backlight auto brightness ramps and CABC maps.
The results have turned out really good so far but I find myself endlessly tweaking things- especially when dealing with variable display brightness. You almost need to do an entire calibration pass at a bunch of different levels for some displays to get good blacks. I don't know a good answer to this problem 🙁
Definitely still learning though. A lot of it came into focus when I needed an algorithm to find the "perceptually nearest" color to another color- we have some devices with a crappy RGB LED that doesn't let you control the per-element PWM, so you can only get 8 colors if you want to fade/blink the thing. Since apps can set an arbitrary value, I needed to find the closest one that didn't freak out the hardware. Trying to do this with RGB was hilarious, but its trivial with XYZ! Simple, but an effective crash course to a lot of the theory behind this stuff.