Sony Megatron Colour Video Monitor

RetroArch Additions Shaders
#2924

Ah, yes, the “scale_type” bug causes broken 10000 nit tonemapping with blown out colors for SDR presets and shaders if they don’t include a “scale_type” for the final shader of the preset.

Tho upon thinking about it, you fixed the hdr.slangp and hdr-config.slangp presets wrongly being rendered in SDR by removing their “scale_type” lines… is RetroArch somehow treating the absence of “scale_type” lines in the final shader of a preset as a forced trigger for HDR, and stretching their output to 10000 nits Rec 2020 accordingly?

2 Likes
#2925

Either way, as of the latest nightly, the “scale_type” bug for SDR shaders appears to be resolved.

There is now a new bug that may be related tho:

The vulkan renderer now only works properly in HDR when certain shaders are loaded. Without any shaders loaded, the output is in the wrong color space (looks like Rec 2020 compressed down to Rec709. Just like the first bugged versions of the hdr.slangp and hdr-config.slangp presets did, as pictured here.

In many cases, loading shader presets fixes it. Seems to vary which shaders do and don’t work for this purpose.

At least some cores (bsnes-jg is the one i noted) display only a black screen in vulkan HDR without shaders loaded.

Again, loading many different shader presets fixes it, but it seems to vary which shaders do and don’t work for this purpose.

(Loading hdr-config.slangp, or appending it to end of any SDR shader chain seems to work as a quick fix.)

3 Likes
#2926

Well that was a quick turn around at least. The scale_type bug turned out to be a major fix so Im not surprised its broken other things.

So we’re saying when HDR is on and shaders are off in Vulkan its now broken? Is this in all drivers or just Vulkan.

2 Likes
#2927

Correct.

Just vulkan as far as i saw. d3d11 and d3d12 didn’t appear to have the new bug(s).

3 Likes
#2928

Great thanks, my suspicion is probably right that this is just a one line fix - thats my hope at least.

3 Likes
#2929

I just tried V2 updated version of Megatron and red color issue on aperture grille masks on AMD rx6000 series past 24.5 driver version we were talking about is not longer there. It is fixed in V2. In V1 version bug is still there but at least V2 is working properly now.

4 Likes
#2930

V2.6.5 Sony Megatron Shader

So last night after trying all my changes and fixes to HDR in RetroArch and this shader on my new OnePlus Pad 3 (great android tablet for retro gaming once a PS4 or PS5 controller is connected up with its 2400p - 10 pixels per scanline on 240p content - 900nits brightness and 144hz screen is great). I decided to do some major reworking of the colour pipeline.

The headline is that due to my changes to the inverse tonemapper that made it colour space agnostic I was able to move the internal colour space from SDR (r709) to HDR (rec2020) linear space throughout. This will knock on the head any banding artifacts and improve wide colour gamut support.

I also fixed a bug in my r709 gamma formula which might be why I was seeing issues with the fall off - I’m going to look into that a bit more.

Anyway this should provide for a much more colourful experience in HDR.

  • Rework colour pipeline to use Rec.2020 as intermediate colour space for improved colour accuracy
  • Add Adobe RGB as fourth output colour space option (alongside r709, sRGB, DCI-P3)
  • Replace ExpandGamut/colour_accurate with continuous colour boost control
  • Add Rec.2020 conversion matrices for sRGB, DCI-P3, and Adobe RGB output targets
  • Add V2-specific colour grading path with Rec.2020 luma-based saturation
  • Rework output stage with per-colour-space SDR and HDR conversion paths
  • Fix Rec.709 gamma formula operator precedence
  • Reorganize UI parameter layout for clearer grouping
4 Likes
#2931

Shouldn’t the “Display’s Colour Space” setting be inactive in HDR? Since by nature HDR is inherently a Rec2020 container and it is the display’s job to tonemap from there?

3 Likes
#2932

V2.6.6 Sony Megatron Shader

Its like buses: you wait all year for one update to the Sony Megatron Shader and then two come along on the same day.

This fixes the bug where we were transforming the output colour space after applying the mask - breaking both the mask and colours at the same time. I noticed the colours changing as I was testing them on the 240p Test Suite gray ramp test and that shouldn’t be happening - we should only notice colours changing in the colour ramps.

  • Moved colour space conversion from the output stage into the ColourGrade function for earlier pipeline application
  • Added Rec.2020-to-sRGB, Rec.2020-to-P3, and Rec.2020-to-Adobe colour space conversion matrices to colour_grade.h
  • Refactored HDR and source pass shaders to use shared include files ( hdr_pass_v2.h , sdr_pass_v2.h )
  • Simplified HDR output path by removing redundant per-space conversions from sony_megatron_v2.h
  • Added clamping to prevent negative values from breaking the CRT mask
4 Likes
#2933

Yes thats right but you can still do the math and it works out - notice in V2.6.6 that if you go on the grey ramp test and move between the output colour spaces in HDR nothing happens - its doing the math but the net result is nothing. The main problem here is that there is no way to ‘hide’ shader parameters, technically it should be set to r709 and hidden as you say for HDR but I cant do that and I figure it doesn’t hurt having the other options - call it a debug feature where I can check that its having no effect on a grey ramp. It having an effect lead me to fix the issues in V2.6.6. I suppose maybe the argument here is where we place it in the shader parameters list. It does have an effect in colour ramps in HDR so its not a null effect even if its not technically correct and so it being placed in the general area is why I moved it there.

EDIT: Ok maybe its a bit too strong to say ‘nothing happens’ there is a very small shift but largely its nothing which is the right behaviour. We default to sRGB which in HDR is identical to r709 so only users going up into DCI-P3 and adobe might hit an issue - they were on SDR DCI-P3 and switched to HDR and didn’t move to r709/sRGB and now they see small differences - hmm yes - it is minor though.

2 Likes
#2934

and now there is a ‘hotfix’ for V2.6.6 as I broke the default.

3 Likes
#2935

There is something going wrong with color accuracy in the color revamp, and i have a theory as to what that may be. (tested using 2.6.6h)

If you set “Colour System” to Rec709, “Phosphors” to none, and approximately match the brightness with the Luminance settings, the resulting colors should be a match for the shaderless output with “Colour Boost” set to Off, but that is decidedly not the case.

Looking with analysis tools, it looks like the phosphor primaries are always placed at the Rec2020 primaries, rather than at the target color gamut primaries? I suspect that is the main issue.

266h gamut test result
266h gamut test result3840×2160 430 KB

I think the reason this doesn’t work as a solution is two-fold:

  • Firstly, the phosphor primaries sort of “filter” the look of the final image, so they need to be placed at the target gamut primaries for the final image to look as it should.

  • And second: to the best of my knowledge, there aren’t any consumer displays that can actually display the Rec2020 primaries, so literally no consumer display is capable of actually displaying 2.6.6h’s output correctly.

In AzMods, i found that hijacking the Expand Gamut function to add additional gamuts actually moved the phosphor primaries to the target primaries, and, in combination with Colour System set to Rec709 and Phosphors to None, the resulting colors consistently match those seen using the same alternate gamuts in hdr-config.slangp.

I do think that the idea of having the whole pipeline in-between work in Rec2020/linear space has potential to improve things tho!

3 Likes
#2936

Yes there are two bugs one is fixed by the ‘hot fix’ - I didnt put the pass through mode at 0 and so were getting a conversion back to r709 by default. Then the other issue is the whole ‘mask accurate’/‘colour accurate’ bug - I thought I had fixed it but thats purely because there was a #define problem that silently failed (at least I didn’t realise) it had dropped through to the builtin shader making it look like everything was fine. Ive got a few things in my head to try today - I already experimented a bit earlier in the week. Fundamentally though I don’t think a strong mask should stop us getting accurate colours as we have four pixels per one crt pixel and so the correct colour should fall out.

2 Likes
#2937

V2.6.7 Sony Megatron Shader

Ok so hopefully we’ve fixed all the colour issues and made the masks accurate! This is actually the first version of Sony Megatron with fully accurate masks in HDR - something that has been bugging me for a while and is a major milestone.

I’ve also made the default presets ‘neutral’ they were using a phosphor set before and had a slightly larger red phosphor leading to people correctly identifying a red hue to images.

  • Reworked HDR signal pipeline : The HDR pass now encodes to a gamma 2.4 signal via LinearToSignal before CRT scanline simulation. The scanline generation pass no longer applies its own gamma correction (removed pow(1/2.2) ) and instead passes the signal through directly. The final output decodes back to linear ( pow(2.4) ) before encoding to the target colour space. This better models how a real CRT processes the signal.
  • Added output colour space and gamma parameters to the HDR pass shaders : Both config and non-config HDR pass shaders now expose hcrt_colour_space , per-space gamma output controls (Rec.709, sRGB, DCI-P3, AdobeRGB), and gamma cutoff parameters.
  • Added LinearToAdobe function for AdobeRGB gamma encoding and refactored LinearToDCIP3 to operate on vec3 directly.
  • Moved Rec.2020 colour space conversion matrices ( k2020_to_sRGB , k2020_to_P3 , k2020_to_Adobe ) from gamma_correct.h to hdr10.h .
  • Added new SDR preset : crt-sony-megatron-v2-default-sdr.slangp which defaults the output colour space to sRGB.
  • Updated default parameter values : Colour system default changed from NTSC-U to Rec.709. Default scanline min/max/attack values rebalanced across all channels.
  • Removed unused hcrt_expand_gamut from source pass config push constants and removed hcrt_new from HDR pass push constants.
  • Added HCRT_MAX_NITS define to config pass shader.
  • Removed legacy comment block from source pass v2.
5 Likes
#2938

Wow! What a laundry list of changes! Looks like you’re having a ball fine tuning things and getting them just right.

By the way have you updated the NTSC presets to use the latest decoupled CRT-Guest-Advanced-NTSC section?

1 Like
#2939

@guest.r hasn’t responded yet, and i don’t want to add a version of decoupled to the repository that is newer than the currently included version of CRT-Guest-Advanced-NTSC if i am not certain he is okay with that.

Excellent. Looks like the most recent Vulkan fixes were merged as well, tho i don’t know if they are in the current nightly. I’ll check on that and hopefully start testing things later today.

2 Likes
#2940

“Fixed HDR Vulkan bugs (#18658)” appears to have fixed most of the remaining known Vulkan bugs. The Image viewer works without shaders loaded again, and at least as far as i saw, no cores display a black screen without any shaders loaded.

I also found no trace of the “scale_type” SDR shader bug.

But there do unfortunately seem to be some remaining bugs with shaders. I started loading presets from the top of the list as a stress test, and “anamorphic.slangp” from the anamorphic folder displays a black screen. As before, this can be resolved by appending your “hdr.slangp” or “hdr-config.slangp” presets to the end of the chain.

Beyond Vulkan-specific issues, UI pop-ups for things like screenshots, RetroAchievements, fast forward, pause, and shader notifications still are not tonemapped correctly.

retroarch202602011413 2026-02-01 18-06-19
retroarch202602011413 2026-02-01 18-06-193840×2160 1.96 MB

retroarch202602011413 2026-02-01 18-06-26
retroarch202602011413 2026-02-01 18-06-263840×2160 1.95 MB

retroarch202602011413 2026-02-01 18-06-29
retroarch202602011413 2026-02-01 18-06-293840×2160 1.94 MB

retroarch202602011413 2026-02-01 18-06-49
retroarch202602011413 2026-02-01 18-06-493840×2160 1.95 MB

2 Likes
#2941

This is a substantial improvement in color rendition and accuracy compared to the “2.6.6 (hotfix)” build i tested yesterday (funny enough, your new defaults are actually very close to the settings i was using to test 2.6.6h.)

I do still notice some slight desaturation and off-notes in the colors tho. I continue to suspect that changing the “phosphor” primaries to match the current selected gamut could help with both of those issues, but you would have to try it to be sure.

But this is very definitely many steps in the right direction. The stronger phosphor masks look great!

2 Likes
#2942

Yes so the problem with all that stuff is that they are ‘widgets’ and there’s no easy way to tell if one is displaying or not - theres a ‘are widgets turned on flag’ but thats always on defeating the purpose of the flag for my use. I want a is any widget currently displaying like we have for the menu and overlays. Im guessing you’re going to have to live with that for a bit - unless someone knows how to tell any widget is on screen. As for that broken shader do we know if its cross driver or not.

2 Likes
#2943

Just vulkan as far as i saw. “anamorphic.slangp” seems to display correctly in d3d11 without appending “hdr.slangp” or “hdr-config.slangp”,

I suspected as much, and it isn’t a big issue by any means. I just wanted to be sure any issues i noticed were documented.

For the last few years, whenever i play a game that involves lots of fast forwarding, i’ve just been disabling that indicator entirely.

2 Likes