Sony Megatron Colour Video Monitor

RetroArch Additions Shaders
#1221

So yeah that suggestion makes sense the only thing I’d say is that maybe it over complicates things? Mind you we’re over complicated as it is so what’s a bit more complication. Let me have a think about it I need to stream line the shader a bit now anyway as it’s getting a bit gnarly in my opinion.

With regards to what the old colours looked like sure it maybe a bit subjective but I do have two Sony 2730 PVMs so I’ll do a side by side and just check but I’m pretty sure they’re not as yellow in the greens. I’ll check though - I’ll post some pictures for you.

2 Likes
#1222

Just added another pull request for Sony Megatron V4.1 which adds a switch to switch between what I’m currently thinking is more colour accurate (soon to be proved/unproved) and what is mask accurate.

This lets you easily see the differences if nothing else. I’ve defaulted it to the shaders old behaviour (as in colour accuracy) right now but it’s totally up in the air what should be the default and whether it being ‘colour accurate’ is correct.

4 Likes
#1223

Hi @MajorPainTheCactus

I’ve been testing HDR mode a bit again and I don’t seem to be able to get as good/accurate a Gray Ramp in HDR mode compared to SDR mode. Where in SDR mode I can tweak the Gray Ramp pretty much too perfection, in HDR always something seems off, either the whites remain blown out, or I can balance the whites but then the whole screen is too dark etc. I’ve tried everything in the book (max nits, paper white, gamma, contrast).

Just to verify with you: are you able to get as well a balanced Gray Ramp in the 240p test suite in HDR mode as in SDR mode?

2 Likes
#1224

Maybe it’s because 240p test suite was designed for use in SDR mode?

2 Likes
#1225

In my understanding there shouldn’t really be any difference, as HDR mode does tonemapping that recreates the SDR luminance scale in HDR “space”. So basicly SDR images should be recreated in HDR space closely as they are seen in SDR hardware.

If I understood correctly from @MajorPainTheCactus then this inverse tonemapping isn’t without caveats though, so maybe he has something to say about this.

2 Likes
#1226

Closely but not identically. I’ve yet to see an image or asset that was designed for SDR look identical or even close to identical in HDR mode/colourspace on my Windows PC. So that might account for at least some of the difference.

The solution to this might lie in manual calibration and tweaking as you have embarked upon but with so many things there are tradeoffs.

Maybe if you had a brighter display things might have been better after calibration.

@MajorPainTheCactus seems to be getting stellar results on his hardware setup though but maybe his equipment might be not be representative of what the vast majority of users have access too.

I would like to see more feedback from users to gauge what kind of experience people are getting from this shader because so far it seems like some are getting great results, others not so good and for others something always seems to be missing.

Maybe part of the issue is that the expectations and standards might be a little different for this shader in a sort of uncanny valley kind of way.

The concept is sound and has been proven and the potential is there though but I think the userbase needs to grow so we can see what sort of awesome presets and photos other users come up with and start sharing with the wider community.

1 Like
#1227

So the first question here is: did this happen before the most recent changes of fixing the mask in HDR i.e if you toggle the accurate mask/colour switch introduced last night can you get a balanced grey ramp?

If it did then you are going to probably have some issues with the inverse tonemapping it’s not perfect. But let’s see what we can do.

If it didn’t happen before the mask accurate then I can completely see it not looking right given that we’re breaking out to virtual phosphors much like the colour issue we were talking about last night.

But let’s see if there are any bugs lurking in there.

2 Likes
#1228

I wouldn’t jump to these conclusions - we’re talking about reasonably minor complaints and considering everybody has been happy with blooms and blurs and the impact they have on image quality its not really an argument to ditch HDR. I mean feel free to go back to them but you’re going to get a better experience IMO with more luminance.

3 Likes
#1229

The toggle changes the gray ramp in HDR a tiny bit for the better, but it doesn’t come close to the quite perfect gray ramp I’m seeing in the SDR version.

Just for the record I’m super happy with the SDR version, so I (currently at least) have no real need for the HDR version.

Are you seeing any differences when looking at the 240p Gray Ramp in HDR mode and SDR mode?

2 Likes
#1230

That’s great to hear the SDR version is working for you. So I haven’t had a chance to compare but I’ll do it as soon as I get the chance. Hopefully there is something we can do to bring the two closer together in parity.

2 Likes
#1231

I don’t think I was making any conclusions. On the contrary, I would like to see more feedback, buzz and the community using these shaders grow. I know it’s early days still.

I wasn’t trying to be critical in any way. Just sort of summing up in a very simplistic way the type of feedback I’ve read and observed here so far. That’s why I was careful to qualify and quantify my statement using very general terms such as “some” and “others” which infers an unknown quantity or percentage.

I most definitely am not suggesting that HDR be ditched in favour of anything else or that it’s not already a successful endeavor.

I wasn’t referring to the shader when I said I never saw an image or asset designed for SDR look identical or even close to identical in HDR mode. The examples I was referring to actually excluded the shader because I was just wondering if that same phenomenon might have been also at play in the shader.

So it was more like a question, not a statement about the shader which is something that is new, being worked on, tested and therefore variable. So no conclusions there. Just a thought that came to my mind based on my previous observations of other things (besides the shader) and wondering if the shader is also at the mercy of the same phenomenon.

Also, I don’t think there is any issue of going back to anything.

I think one can use any shader and still want to see all of them improve and enjoy supporting novel and different approaches.

So please don’t get me wrong. I am definitely an avid supporter of your work and what you have created. I hope you don’t think that I’m amplifying any minor issues that a few users might be having here and there.

I was trying my best to communicate (not criticize) what I thought might have been obvious, which is that users’ mileage might vary depending on their particular setup (particularly in the brightness and calibration department).

No harm intended. You’re doing a great job and service to the community here.

Keep up the good work!

1 Like
#1232

This gray ramp issue may be the same issue that I reported several months ago. Glad I’m not the only one. Solving this would likely improve overall brightness as well.

2 Likes
#1233

With regards to color accuracy I was thinking we need to consider one other thing that may sit in the way of having accurate 709 mapping in 2020 space. It’s not related to the shader, but to the fact that HDR monitors don’t have full coverage of the Rec.2020 space themselves.

If you look at RTINGS.COM and add “Rec.2020 coverage xy” as a column in their table tool, the best monitor has a coverage of 84%, most others are in the range 55%-80%.

This implies native monitor primaries in HDR mode differ from the assumed theoretical Rec.2020 primaries, which the shader gamut mapping is based upon, and will result in a (visible?) color shift. How large this shift is would depend on each individual HDR monitor, and how closely it tracks 2020 color gamut.

Maybe this could be a factor also with the greens you’re seeing?

I think I’ve posted it before also, but if you’re interested to know the native primaries of your HDR monitor, run “dxdiag.exe” in Windows and Click on “Save All Information…”, search the log for HDR and there you’ll find the reported primaries of the monitor, such that you can compare them to the Rec.2020 specs primaries, and see how much smaller the monitors gamut actually is.

2 Likes
#1234

Yes but Id expect the monitor to be able to display rec.709 correctly otherwise everything would look odd and just that in that say 16% that isn’t possible it’s just clipped i.e it reaches max green the display can do and just stays there.

#1235

Definitely try latest and see what you think as I’ve solved a few bugs: one with precision and one with a bad DCI-P3 gamma calculation.

1 Like
#1236

So on mine I funnily enough see it the other way round HDR gives me the best ramp and SDR I have to really mess around with the gamma’s to get a fully balanced ramp. I guess this is just down to our different monitors? What exactly are you seeing wrong with your HDR ramp - black clipping, white clipping, both or something else?

1 Like
#1237

Some images to compare colour as discussed. I have to say these images seem to give the mask accurate a closer accuracy to the PVM than it actually is but in person I’d absolutely say it’s the colour accurate version is more accurate.

Having said that the darks are way to dark so I may have to adjust my gamma levels a bit to march my PVM.

Sony 2730QM PVM:

Screenshot_2022-09-23-23-00-57-77_92460851df6f172a4592fca41cc2d2e6
Screenshot_2022-09-23-23-00-57-77_92460851df6f172a4592fca41cc2d2e61080×2376 2.41 MB

Sony Megatron Colour Accurate Mode:

Screenshot_2022-09-23-23-38-00-85_92460851df6f172a4592fca41cc2d2e6
Screenshot_2022-09-23-23-38-00-85_92460851df6f172a4592fca41cc2d2e61080×2376 2.13 MB

Sony Megatron Mask Accurate Mode:

Screenshot_2022-09-23-23-38-57-08_92460851df6f172a4592fca41cc2d2e6
Screenshot_2022-09-23-23-38-57-08_92460851df6f172a4592fca41cc2d2e61080×2376 2.28 MB

All Photos: OnePlus 8 Pro Camera: Pro Mode, ISO 100, WB 6500K, Aperture Speed 1/60, Auto Focus, 48MPixel JPEG.

2 Likes
#1238

Hi @MajorPainTheCactus

Thanks for posting these pictures, let me first just say they look astonishing! I wouldn’t be able to tell the shader ones from real CRT if they would’ve been posted on their own.

The interesting and great part of course now is that you have the CRT for close inspection and comparison. As you mentioned the gamma part is the more obvious difference when comparing them side by side.

Do you have the ability to run the 240p test on your CRT and actually have the CRT placed side-by-side with the LED? I know you’ll have your own methods, but if I were doing the calibration I would do two things:

  • Run 240p test suite on both, go to the white screen, and make sure the luminance of the white screen on the CRT matches that of your shader output on LED. Note that is very valid to use the “Contrast” on the CRT to bring it in line with your shader output luminance on the white screen! You don’t have to do everything on the shader/LED side!
  • Run 240p test suite Gray Ramp test on both and make sure the darkest value bar (the “8,8,8” bar) is just visible when looked at in a dim room, while covering the bright bars with your hand or a magazine. Note again adjusting the “Brightness” on the CRT is equally valid. The goal is to have them both matched, so adjusting on both is a valid strategy.
  • Reiterate the previous two steps until both the white screen and the gray ramp look exactly the same on both the CRT and the LED with shader output. Of course this is only possible if you’re able to run the CRT and the LED/shader in a physical side-by-side comparison, so hopefully that’s something you’re able to do.

If after this process there’s still a difference then it could be an option to add the various Gamma Type functions on gamma_in and _out as parameters, as we talked about previously, to see if for example a change to power law from 709 or other combination of gamma function/type on gamma_in versus the gamma_out type function could “dot the i” :slight_smile:

It would be super interesting to see your three phothograps again after the CRT and shader have been matched on gamma! In any case great stuff already, thanks for posting the comparison!

3 Likes
#1239

Thanks for the calibration tips! So sadly I haven’t got them side by side as I haven’t been bothered to move my PC and monitor into the living room and I’m certainly not going to try lumping the 50KG PVMs into my office. :rofl: BUT I can see the two screens at the same time - just from a bit of a distance. I do have 240p t at suite on both and have done calibration comparisons in the past but I should do this again as it’s a long (development) time since I did it last and the gamma has all changed since fixing the precision bug and other things.

The main issue with luminance is that my 600-700 nit LCD monitor can’t reach the brightness of the CRT when the shader is on.

That’s actually a lot of the difference you see in the above pictures TBH as my camera doesn’t have low enough ISO to stop the CRT blooming and clipping the images and giving slightly false results. But then again phone cameras aren’t perfect anyway.

I’ll definitely calibrate the gamma again and post the pictures up.

2 Likes
#1240

I’m certainly not an expert on the subject but maybe you can temporarily lower the brightness of the CRT to match the LCD at least initially and do your calibration of your colours, gamma and contrast at that level, so you get the best case for the LCD, in terms of matching the CRT, then you can revert the CRT to the best case for that.

Normalizing the brightness of both displays to the lowest common denominator should also assist with your camera issues.

Again, I’m no expert, just a thought.

3 Likes