So to 1) changing the beam spot size isn’t increasing the TVL at all, although I can see it having the effect of doing that. Your TVL is basically fixed to the number of phosphor triads you have and that can’t change. Changing the spot size effectively makes the beam more reactive to the current phosphor and underlying image giving a sharper image.
With shaders you can do this way more accurately as can be seen especially in Reshade where you can have effective TVLs of 2160p if the underlying content is 3840 horizontal resolution.
Basically we change the spot size already and you can change that with the horizontal (and vertical) attack in the Megatron.
TVL is the count of vertical lines across the screen to the height of the screen across i.e a square. That’s why we just use the vertical resolution.
Adding to what MajorPain just stated, total TV lines was used by some TV manufacturers like Panasonic and JVC, since more = sounds better. Some CRT spec sheets of monitors on the other hand state a line count for center and another for corners.
If you read the thread, the author actually states TVL is a stupid metric after adressing exactly the confusion with total lines by another poster on page 4, but there are also statements of why it can be useful and other things that factor in and what the author was trying to accomplish.
Updated my AutoHDR ReShade addon to work with ReShade 5.4.2 and Sony Megatron for ReShade to latest Retroarch version. You still have to faff about in the fx file to set the right resolution for the intermediate buffers if you want something different to 240p but that’s where ReShade is right now.
There’s an updated core that builds from latest upstream git, it’s just not on the buildbot (yet). You can get it (and the required helper files) from https://github.com/hunterk/libretro_builds
No they’re of my LCD. That I suppose is something to say I think my LCD is pretty comparable to the QD-OLED to be honest - just it’s on a smaller scale. Not sure about ReShade and Scummvm - my AutoHDR plugin works with both D3D11 and D3D12.
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.
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.