EDIT: all what I’ve just said is nonsense the OLED had gone into some power saving mode! Anyway I’ll keep this here to embarrass myself and entertain you lot. I’ll redo this properly now…
Here you go @nesguy 40 year old CRT technology vs cutting edge QD-OLED. Id say it’s about 3-0 to the 40 year technology.
The difference in motion is of course night and day and STILL the OLED is no where near the brightness level of the CRT even if it feels really bright it’s still no where near as bright as the CRT.
Where I’d say the QD-OLED wins out is in size obviously and then if you go off piste with the colours - the QD-OLED can get incredibly saturated colours which is nice to look at in itself if not that accurate - same goes for the LCD.
Now have I got these two as accurate as I did with the LCD, no certainly not but my camera is maybe adding quite a bit of noise because it’s got to be further away than with the LCD because of the size of OLED.
Anyway an interesting test and maybe I can add accuracy a little more if I try out @rafan curves not sure but worth a punt (I’ve been working on something for you @rafan that I hope you’ll like)
You can probably use manual focus to get around this. It also happens to me, especially when using Auto Focus until I get the distance and angle right.
With manual it’s a bit easier but I can see the closeness of the fine details despite the colour not looking correct in the photo.
I tried manual as well before and my phone camera still does the same. In motion the CRT destroys the OLED in terms of clarity (I like the Megadrive’s Dynamite Heady first level’s foreground layer and try to read the signage) although I haven’t tried BFI yet as I haven’t found the option but seen as the OLED only just matches the CRT for brightness BFI will obviously unbalance that. I will try it though once I find it - game mode is currently borked appears as they are scaling the image from what looks like 1080p nasty - others must be complaining about this so I’m hoping it gets fixed in a firmware update.
Hmmm…did you change the input label on your HDMI input to PC mode? Also did you adjust your Sharpness setting? I was reading up about another recent Samsung set recently where they said that neutral Sharpness is actually at 10 and not 0. Or something like that. It shouldn’t be hard for me to find back the links. Links also talk about how to setup the TV for PC Monitor use.
These are for the Q70A but it’s possible that the same might apply to your set.
Ah just twigged what @Cyber was possibly trying to tell me - have the shot slightly out of focus with manual zoom mode - sorry I was just thinking of it always being in focus. Here’s the best I could take without it becoming a blurry mess and does bring out the colours much closer to what I’m seeing with the naked eye. Thanks Cyber!
Just as another take on this I have the PVMs in the same room as the QD-OLED and although not next to each other I can stand equi distance between them say 12 feet away from each and take photos in roughly the same lighting conditions (it’s day time with the blinds pulled) with the same camera settings 65K 100ISO 1/60 shutter.
Again in person they seem closer to each other. One is 65" and the other 27" so there is that.
Not, exactly. I was just trying to relay my experience. When I use Auto Focus, sometimes the colours keep shifting while I’m trying to get the shot. It could be the focus having to adjusting itself constantly possibly due to the slight movements of my hand or whatever it is.
I notice this colour shifting is a bit easier to control using manual focus. Using manual if the colour is off, I might just have to move very slightly forward or backward, or maybe tilt my device slightly but not enough to make things out of focus though even though this might be desirable at times.
So there’s a particular point and position that looks perfect both focuswise as well as colour wise.
This also applies to a situation where I see some distinct yellow looking “phosphors” between the primary phosphors. I’m not talking about extra subpixels here because if I move slightly forward or backward they also go away and all I see are the primaries.
When I say slightly I mean very minute movements.
I think after “investing” in such lavish TVs another great investment might be a decent phone tripod. Lol. That will take our pics to the next level. A macro lens is another thing.
These pics are awesome though! Glad you’re having even more fun with these things now and I guess you’ve put the question of QDOLED suitability to rest.
These comparisons are awesome, thanks for taking us along the discovery tour with your new TV!
One thing that would be a great addition to your comparison quoted below, is if you could do the exact same two shots, but while having the Megatron run in SDR using these settings:
HDR in Retroarch = OFF
set shader “SDR: Display’s Colour Space” to DCI-P3
I’m really curious what comes out of that comparison since your TV has 100% coverage of DCI-P3 space (which will be active in native non-HDR mode, at least my monitor is…). It could well be that you’ll get the colours to match better. Two reasons for this could be the DCI-P3 color space coverage is very good with your TV, so the sRGB gamut mapping in the shader may be more accurate for system end result, and/or being in SDR mode, you don’t get the “art” of inverse tonemapping from SDR to HDR possibly interfering. I know you’re a fan of the HDR mode, but this SDR test could prove worhtwhile for colour accuracy.
While we’re at it, I’m really curious as to the colour gamut primary values of your new OLED. For this, if you also have an interest, could you possibly do a quick run of “dxdiag.exe” on the windows command prompt and then on the screen that opens click “save all information”, open this text file and search for each of the two following lines separately and share the line -below- each that starts with “Color Primaries:” .
Display Color Space: DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020
Display Color Space: DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709
Regardless, good job on the comparison of side by side!
Thanks @Cyber - I’ve definitely been looking at investing in a macro lens for my actual digital camera - £70 which is not too bad for a macro lens but still quite a lot for something I’m effectively only going to use posting here - mind you £70 is probably peanuts compared to the time I’ve spent here so what the heck maybe a Christmas present
Hi @Rafan, so since getting the S95B and noticing those extra sub pixels lit up it has got me thinking about how a TV does actually support all these colour gamuts.
Let’s ignore the fact that the S95B only covers 80% of rec. 2020 and just imagine it fully supported it.
Pure green on that display would look very different to pure green on a rec. 709 display. So in order for that display to support both it’s got to make it’s pure green sub pixel elements (I’m talking about the physical hardware here) match that of the green in the rec.2020 and then match the rec. 709 green by turning on the red sub pixels.
As in the straight line (pure greens) from the white point to the brightest rec. 2020 green doesn’t go through the rec. 709 green.
So my guess is that any rec. 2020 ‘capable’ display will show rec. 709 content with these extra sub pixels on. Or no matter what we do from a PC perspective the TV is going to colour match as best it can by turning on these extra sub pixels.
So my guess is that pure masks are impossible on a rec. 2020 capable display. What do we think?
Getting back to the DCI-P3 stuff sure I’ll get some pictures and that information for you (my PC is back in the office). I’d be interested myself to see what it’s capable of.
However I will say that I’m not sure Windows really supports DCI-P3 natively. As in it doesn’t have a colour space for it - i.e the DXGI_COLOR_SPACE_ defines that you posted for rec. 709 and rec. 2020 colour gamuts.
What I’m trying to get at is that without that support how does Windows convey to the display that it should be interpreting the 10bit or 8bit channel buffer as values for the DCI-P3 rather than the rec. 2020 and rec. 709 that those defines do support.
Obviously the display can just warp/expand the rec. 709 colours out to DCI-P3 space or crunch down the rec. 2020 colours down to DCI-P3 but that just seems a bit off no?
Yes, I think you’re correct. If the green it’s trying to produce is not the same color as the green subpixel/phosphor, there is no physical way for it to produce that color without lighting other subpixels/phosphors.
We’re on the same page. Here’s my quote from our previous talk on the mask accurate topic:
In this regard you may want to look again at the CIE 1931 colour space I’ve been referring to in previous posts. It all makes more sense once you get grips with the colour gamut (the triangle) pictured on the horse shoe colour plane. If you imagine your monitor hardware gamut in this space, it makes sense it’s the final boundary. Any other gamut you simulate within this boundary is simulated by mixing any combination of the three primaries.
In the shader this is done through the colour gamut mapping RGB-to-XYZ and XYZ-to-RGB. This is all CIE colour gamut stuff but the end result is a new RGB variable. So if you feed pure green RGB (0,255,0) without any mapping, you’ll get the monitor’s native green with a location on the horse shoe that is your monitor’s native green primary.
So what happens with green when mapping 709 to 2020? E.g. for your monitor, native green will be close to DCI-P3 green coordinate, Xg=0.265, Yg=0.29. But the r709 primary is on location Xg=0.30, Yg=0.60. Looking at these coordinates in the CIE horse shoe plane you can see it moves to a different hue and/or saturation. In a paint package you can get an idea of what the CIE RGB-XYZ-RGB colour gamut mapping result will be for the RGB value, just set (0,255,0) in the paint package and then change the Hue “H” (in HSV) by say 10 degrees to a more yellowish green and you see it adds in red, e.g. 10 degrees move towards more yellow gives RGB value (42,255,0). So the hardware being fed this value will turn on the red subpixel slightly to give the visual perception of rec709 green on your wide gamut monitor.
So to come back to one of your previous questions, your shader does not output pure green in HDR mode when the raw input is pure green, but it feeds an RGB value after gamut mapping that considered/imagined in the CIE colour space of your wide gamut display will result in a perceptual r709 green by turning on the red subpixel. That is, IF your monitor actually has <deltaE 3.00 i.e. near 100% coverage of the space, or other wise the end (perceptual) result will be undefined after this colour space mapping.
Yes this is an interesting question. I think a “pure” mask discussion should probably separate out the discussion of mask simulation from having accurate colour mapping. The mask and display pattern of a CRT doesn’t change if you swap the phosphors in a CRT from EBU spec to SMPTE-C spec.
I think the question in your mind is: can we have a rec. 709 green phosphor simulated in a single wide gamut rec.2020 OLED green subpixel? The answer is no.
But that doesn’t rule out that we can have accurate mask simulation AND accurate colors. You just need the perspective of a real CRT on which through color mapping the output is changed. What happens in that situation, and can we simulate that?
First question is: IF it existed, can we simulate a CRT its mask if the CRT had a rec. 2020 gamut? Answer is YES. Just run the shader and disable the 709-to-2020 colour gamut mapping (or change the color conversion matrices to unity matrix) . This will result in properly simulated mask in monitor native 2020 colour gamut.
Second question is: Suppose we have this real CRT with a 100% rec.2020 colour gamut, but I want this CRT to correctly display my rec.709 pictures, is that possible? Answer is YES, just do the 709-to-2020 colour gamut mapping on the CRT. This will result in the CRT displaying for example the yellowy green of r709 by turning on slightly its red phosphor (parallel to the above discussed RGB-toXYZ-toRGB mapping, the RGB out value gets red added in and the CRT will turn on its red phospor slightly when simulating the r709 green).
Third question is: can I simulate a real CRT situation like the one in the second question? The answer is YES, just turn on mask accurate mode in the shader including the 709-to-2020 mapping. The LCD will do the exact same as the CRT with 709-to-2020 mapping will do: it will result in the LCD displaying the correct mask simulation, and within that mask simulation it will for example display the yellowy green of r709 by turning on slightly its red “simulated” phosphor
This way the mask structure is maintained correctly like a real CRT and colours are accurate because the colour mapping is done through the virtual/simulated phospors, just like colour mapping would work on a real CRT!
This is also my experience with running Megatron in SDR mode on my native wide gamut and having the DCI-P3 mapping on. It gives me super accurate mask structure (looked at through magnifying glass) and accurate colours.
Now my experience in HDR unfortunately is totally different. I’m getting very off looking colours. It’s difficult to explain really, they just look very off. Maybe it’s my monitor, maybe it’s the lack of proper rec.2020 colour gamut, maybe it’s the inverse tonemapping, who know’s?
Yes it will be interesting to see what comes out of your comparison. It will also be interesting whether your results in SDR mode will confirm mask accurate mode resulting in accurate colours, like it is for me.
Yes, it would be nice to know how that stuff exactly works. What I do know is that when I’m measuring my monitor with my colorimeter (an i1Display Pro and DisplayCal software) then in native SDR mode I’m getting an approximate match to DCI-P3 colour gamut.
My -assumption- is that the values reported under the 2020 line are actually the monitors native colour primary values as reported by the monitor. The 709 line has less value, as those seem to be the values the Windows desktop is mapped to when Windows has HDR turned on and is in the desktop?
So since you don’t have a colorimeter (it’s only double the price of the macro lens, hint hint haha ), the “poor mans version” of getting an idea of the native colour gamut would be via that dxdiag output. Again that’s my assumprion and I could be wrong here.
Yeah I’m fully aware that my shader outputs a slightly yellower green when in HDR mode for max rec. 601 green (which is the same as rec. 709 green) but what I’m saying is that in SDR mode the TV itself will be outputting a slightly yellower green because it’s a rec. 2020 screen (or near it). So essentially it doesn’t matter colour-wise whether you’re using SDR or HDR the end result is the same: that a slightly yellowey green (i.e red sub pixels will be on) will be output because we’re always trying to match rec. 601. What you get from HDR though is a brighter screen.
I disagree - a rec. 2020 display will never let you have a single channel mask because as we both agree that would output the wrong colour. You can only do that with a rec.709 display.
Yes that’s my point it doesnt at the moment - as can be seen in the photos above - we’re getting a slightly yellowey green and an additional bluey red resulting in completely broken colours on both my S95B and my Eve Spectrum. As I’ve said before I think this could be a bug in the swap chain of RetroArch DXGI colour space that I added not sure as it also occurs in the Vulkan driver that I also added rec. 2020 support to. But it maybe something TV side - the shader is definitely outputting the right values.
I think we both agree HDR mode is broken colour wise?
So is the next step then that you would want to test your shader in SDR mode, like we discussed? You seem very focused on the HDR version, while people have reported the SDR version working properly.
It’s not broken colour wise - at least on my displays.
Also I’m saying the end result of SDR and HDR is the same colour-wise on my displays: in HDR the shader outputs slightly yellowey greens and in SDR the TV outputs slightly yellowey greens. Slightly yellowey green being the correct green for rec. 601.
What is broken is the ‘mask accurate’ mode - it’s not working which is a HDR only thing.
Also to add I’ve tested it in SDR mode and it does what I’m saying but at a lot lower brightness levels. I am planning on going back to make sure my brightness level was at 100%.
So I’m really lost now. You say you’re getting the same colours in SDR as in HDR, saying the greens are correct. But if I look at the comparison you posted for HDR, they are VERY different from the CRT.
So the comparison you posted in this post. We can’t even speak of a color match, it’s dE > 10, just look at the blue water and the green grass, they couldn’t be any different.
In my experience SDR with mask accurate should be MUCH closer to r709 than the HDR comparison you’ve posted, which is very wrong colour wise compared to the CRT.
Something is off… Are you still willing/planning to post the SDR comparison? I’m quite sure SDR+mask accurate in SDR mode should be able to achieve a far better color match than the HDR comparison you’ve posted.
I suspected this was the case, yeah. There’s just a smidge of red added in on your shots, so at low brightness it would be hard to spot.
IMO, having some errant subpixels lit at the micro level to preserve proper color at the macro level is generally more important. It interferes with the super-close, real-vs-simulated money-shots, but whatever.
Some PVMs/BVMs can switch between 601 and 709, so they would have had the same issue, but nobody cared because it’s the overall color accuracy reaching their eyeballs that people want, not the individual phosphor behavior.
At the 4K mask level (e.g., RGBx or RRGGBBx), the TV’s physical subpixels don’t really matter for color, just for mask regularity/sharpness, and the mask pretty much disappears once you reach a certain distance from the display anyway.
So, in summary, I think a perfect one-size-fits-all solution is not possible and it’s good to keep a toggle for whether someone wants to do close-up mask/phosphor-pr0n or actually play games with proper color.
Those pictures are largely irrelevant to what we’re talking about here as they are where I was trying to colour match a 40 year old CRT by eye (that has all sorts of slightly off things given its age - I have two of the same model and they are slightly different in themselves) with the options I currently have available in the shader (no tint for example).
TLDR SDR and HDR would be equally out - it’s not the solution. You can also see in the CRT image the contrast is way lower too. I can also say they are way closer in person probably because the way the camera is picking up the different display technologies.
I think the problem here is that we’re both experiencing different things. What is the display you’re using and gfx card? (You’ve probably said before but I can’t remember)
As for the SDR comparison of course I will but my PC and TV are in different rooms and I have to move one into the other room which isn’t as straight forward as it would at first seem with a wife and two children watching it and a job and a numerous projects on the go on the PC that I need in the office - finding time is difficult. The pictures I’ve already got I’m not happy with as I think they’re misleading in the brightness levels and I need to re-check/play about with this.
I’ll redo this properly now…
), the “poor mans version” of getting an idea of the native colour gamut would be via that dxdiag output. Again that’s my assumprion and I could be wrong here.