Sony Megatron Colour Video Monitor

[Azurfel]

I download the new versions of Megatron directly from the github repository and place them into versioned folders for easier testing and modification (hdr262, hdr270, etc.).

Both the 2.6.2 and 2.7.0 images are crt-sony-megatron-v2-default-config.slangp with the RWBG subpixel layout, 670 for both Luminance settings, 300 TVL, and both Colour System and Phosphors set to neutral/0.

@MajorPainTheCactus did change the scanline min/max/attack and beam sharpness/attack settings for that preset between the two, but those have no effect on what i was showing in those images (all three primaries being fully lit when they shouldn’t be.)

“Mask Accurate” always did the same thing on at least LG OLEDs, that is part of the reason i have always told people with LG OLEDs to use “Colour Accurate” (that is, “Mask Accurate” moved the simulated phosphor primaries to the Rec2020 primaries, caused all three phosphor primaries to fully light up even when they shouldn’t, and made colors notably inaccurate.)

[MajorPainTheCactus]

Although it appears we’ve lost those later images a bug very much has crept in - its basically in the conversion from XYZ to r2020 but Ive not been able to pin point the fix so far - I knock other values out, a bit like whack a mole. Bear with me it will be fixed.

[MajorPainTheCactus]

V2.7.1 Sony Megatron Shader

So this release adds support for scRGB as in 16bit HDR. As I’ve said in a previous post I’m not sure this is actually better than HDR10 because the hardware/driver still quantises down the signal to 10bit (rec2020 PQ) to send over the wire. But it is better if you’re using the DWM compositor i.e Steam overlay etc. So depending on your use case you may or may not see a benefit.

What this does show though is that you can have one shader that supports all three swap chains that RetroArch provides. Which is a good thing in keeping things simple.

I’ve also fixed the colour space menu option as the naming wasn’t making much sense and DCI-P3 and Adobe colour spaces were broken (r709|sRGB and r2020 were swapped around but working). This now also makes a bit more sense in the passes: SDR pass output SDR and the HDR pass outputs HDR (except for the PQ).

Anyway hopefully this fixes a few issues. I’m still a little concerned about the scanlines warping the colours (there maybe bug(s) still) but its also worth bearing in mind that a CRT also warped colours when the three beams diverged i.e transitioned (at different rates) to the next colour across - but this would be confined to small areas and the overall colours would be correct.

[anikom15]

Does it work on Vulkan or is it D3D only?

[MajorPainTheCactus]

Both! Just be aware if you’re using it on a phone or tablet with a high resolution that performance maybe effected. Id recommend sticking with HDR10 on anything that is power sensitive. Also if you want to achieve super high frame rates on integrated graphics again Id recommend HDR10. If you have a discrete gfx card fill your boots and go for scRGB as basically it doesnt matter what you do with Retroarch on them.

[MatheusWillder]

Just to report the current state of things on Linux, since “GLSL/HLSL/Vulkan: Fix ExpandGamut colour boost and HDR support flag” (in https://github.com/libretro/RetroArch/pull/18772) was merged, the option to enable HDR now appears in the AppImage build, so I was able to test the current state of things.

Now in the current nightly build in Linux, the colors are washed out when HDR is enabled, both in the UI and in the game.

Screenshots (current nightly build in Linux AppImage):

Before, it looked like this (stable build in Linux Flatpak):

I don’t know when this (new?) issue arose, since before this last PR, the option to enable HDR didn’t appear in the AppImage build, not even when I compiled the code myself, it only appeared in the Flatpak build, which is still stuck in stable.

Enabling or disabling HDR in the system doesn’t change this. Is this still due to the missing metadata, or maybe is a new bug on the Linux side?

[MatheusWillder]

Unrelated to the above, but I’m facing a problem and decided to ask here to see if anyone can point me to the source of it, but I’m almost certain the problem is with the monitor rather than the shaders.

When using shaders with a strong mask, such as Sony Megatron or CRT-Guest-Advanced with mask at 100% strength, I see an effect similar to moire, but only in blue areas in the game, where vertical lines with an lighter blue area appears. Even when I move the image to the right or left, they remain in the same place. It’s a little hard to see in photos, but I edited one of the raw images to point out each vertical line I identified in it, the raw images are below it:

!

While searching about this, I found some comments here about something similar, including this one by @Cyber (Sony Megatron Colour Video Monitor), but it don’t seem to describe the same thing I’m facing, so I’m not sure. Is this due to my current monitor?

I plan to buy a better one, maybe in some months, but before it I want try to understand in some way what’s going on here to avoid facing the same thing in the new one I’m going to buy.

Edit: my current monitor is a cheap LG UltraGear 24” IPS. Any hardware here where I live is very expensive, so the new one probably won’t be a premium one either, that’s why I want try to know what’s going on before buying another one.

[MajorPainTheCactus]

Ok thanks for letting me know - that looks like HDR hasnt kicked in. Have you got shaders turned off just to make sure they aren’t effecting things for the time being? So in your HDR menu options are you seeing Off, HDR10 and scRGB? I suspect something is broken when it cant support scRGB and so it turns off all HDR.

EDIT: ignore my question about the menu option - its in the screenshot now I look closer!

[MajorPainTheCactus]

This looks great @Cyber! Looking forward to it!

[MajorPainTheCactus]

If youre able to grab a screenshot and then look at the pixel values in a paint package - see if theyre there in the raw image or whether its just your monitor.

[Cyber]

@MatheusWillder

Enabling or disabling HDR in the system doesn’t change this. Is this still due to the missing metadata, or maybe is a new bug on the Linux side?

Have you tried changing the Colour Gamut/Colour Space in the Shader Parameters?

Try Rec.709 or sRGB instead of Rec.2020.

[MatheusWillder]

Yes, there were no shaders loaded when I tried it in the nightly build, I tried it on a live system with clean retroarch.cfg to make sure nothing would interfere.

EDIT: ignore my question about the menu option - its in the screenshot now I look closer!

But I really was seeing HDR Off, HDR10 and scRGB as options.

This cheap monitor barely supports HDR10 (it claims to, but all it seems to do is increase the brightness), but I made sure to test all the options, as well as the Colour Boost options.

[MatheusWillder]

Thanks for replying and all your effort to keep this up!

I tried using screenshots some time ago but they’re not there, I couldn’t identify the pattern when zooming in, nor when transferring the screenshots to the phone. Apparently it’s only on the monitor, so that’s why I took photos instead of screenshots.

Any idea what might be happening? I’m lost about this lol

[MajorPainTheCactus]

Ok so I dont have a Linux setup but I do have Android so Ill give it a whirl over there and see what happens - hopefully it exhibits the same issue and I can go from there.

[MajorPainTheCactus]

Have you tried changing the sub pixel layout of the shader?

[MatheusWillder]

Yes I tried that. It looks a little better at r709 if I also increase the Colour Boost a little (to ~1.50), but the colors still look wrong, just better.

[MatheusWillder]

Yes I tried that, I’m sure the monitor is RGB, but the pattern is visible in both RGB and BGR, and little visible in RWGB (but they are still there even in RWGB, it’s just harder to notice).

Edit: raw screenshot:

[MatheusWillder]

Thanks! Let me know if you need any kind of testing, now that the option to enable HDR is there when compiling or using the nightly builds it will be pretty easy to do some testing, the only problem is my cheap/low quality monitor, but I’m sure I can still help in some way.

[anikom15]

You can narrow this down by setting the scaling mode (either video card or monitor) to original and using a lower resolution. If the bars are present in the same location (relative to the monitor) then it’s backlight bleed. If it’s relative to the image, or not present, then it may be a different limitation of the monitor.

[MatheusWillder]

I just tried it, the monitor is 1920x1080, I tried at 1280x720 I couldn’t see the moire pattern, I also tried a resolution higher than what this monitor supports, 2560x1440, and the pattern didn’t appear either.

I had already considered the possibility of backlight bleed, but I did a test before and even setting the colors close to the sky color in Super Mario Bros. (where the pattern appears), I also couldn’t see the pattern.

Furthermore, in Sony Megatron when I set the Display Resolution to 1080p and the TVL to 800 or 1000, the mask disappears completely, and the pattern also disappears. I can only see it when there is a mask pattern on the screen.

This is bugging me for weeks lol, that’s why I decided to ask here, even though it’s not related to the shader.