Yes Ill look into it!
1 Like
These covers are off the libretro thumbnail database. Depending on the UI style you choose they are displayed in playlist with corresponding game.
yes, it is present in all main drivers. Some drivers the distortion is different.
2 Likes
I’m still intending to add decoupled as a separately maintained shader in the ntsc section, i was just waiting until @guest.r’s newest updates were filtered into the main repository.
Let me check in with him and see if he is okay with me doing that now.
3 Likes
Hmm, @MajorPainTheCactus visually it seems to be the same issue that has been occurring on Linux and Android since before the updates to HDR. I showed videos of it here (second and third videos in the comment): https://github.com/libretro/RetroArch/issues/18186#issuecomment-3203048683
Since you are apparently using Windows, which didn’t have these problems before, something also must have broken on it with the recent updates to HDR.
2 Likes
On Win10, i know that the RetroAchievements game startup popups have displayed in the wrong colorspace when using Megatron for ages. Let me check which versions of RetroArch i have installed do what in this regard.
2 Likes
Thanks for the info, before posting that comment a few months ago, I did some research and didn’t find anyone reporting these issues in the Windows build, so I just assumed it was working fine on Windows, my bad 
1 Like
I haven’t spent much time with the update to notice much and I don’t use RetroArch to launch titles at least on my main system. As a matter of fact, I deleted all of my playlists recently so I don’t have anything like box art in RetroArch and stuff like that.
However, screenshot thumbnails have always looked weird in RetroArch and in more recent times but before Megatron v2, they’ve appeared dark as well as very saturated but I mostly use Shadow Play to take my screenshots .jxr format. I’m just mentioning this just in case it might be related in the slightest bit.
2 Likes
Here’s an excellent guide:
1 Like
No worries! I also didn’t realize that this was potentially related to a Linux problem, or i would have said something sooner.
3 Likes
Okay, i’m putting most of this behind spoilers by version, because it’s a wall of text.
All tests performed using vulkan.
RetroArch 1.15
With HDR on, no content loaded, thumbnails in the “Images” submenu tonemap correctly.
When you load a core/rom with no shaders, they still tonemap correctly.
When you load Megatron v1, the tonemapping for all thumbnail images, including popups for screenshots breaks.
If you disable shaders entirely after you have loaded Megatron v1, the tonemapping of the underlying image is also broken.
In 1.16.0, disabling shaders after loading Megatron v1 does not break tonemapping for the underlying image, but aside from that, all of the same issues are present.
1.20.0 behaves identically to 1.16.0.
1.21.0 behaves identically to 1.20.0.
1.21.1 (stable)
Apparently there was a related regression in 1.21.1: that bug from 1.15 is back, where the tonemapping of underlying content is broken if you disable shaders after loading Megatron v1 or Megatron v2.
As it turns out, this is the bug i mentioned finding on older versions in the most recent AzMods post.
Megatron v2 actually works without issue on 1.21.0.
1.22.1 stable, which is the last version i have from before the HDR “v2” revamp, behaves identically, including the regression bug from 1.21.1.
And finally the HDR v2 revamp:
RetroArch1.22.2-20260121 always has broken tonemapping for thumbnail images, in both the menus and popups, when HDR is enabled, even without ever loading Megatron.
But the regression bug seen in 1.15, 1.21.1, and 1.22.1 was resolved by the revamp, so there is that.
3 Likes
Until now I thought that this was due to the missing HDR metadata on Linux, which MajorPainTheCactus said would add later, but since it also happens on Windows, so probably it’s something else and the missing HDR metadata is only causing that brightness issues on Linux/Android.
The tests I had done were with the background image because I don’t use playlists/boxarts, but I imagine it’s exactly the same issue that happens to the boxarts (Linux, RetroArch with Vulkan and HDR enabled, Sony Megatron HDR shader loaded):
2 Likes
Does actual content get blown out colors like that DKCR image? Fully loaded images with the image viewer, games, etc? Or just backgrounds and thumbnails?
I use a very minimalist theme, so i am not sure if background images and such are effected, let me check on that in one of the old versions.
The thumbnail in this screenshot gives some idea what the thumbnail bug looks like on Win10, tho it is limited in accuracy to reality due to being an SDR screenshot of an HDR image:
2 Likes
Okay, so it looks like in any case where thumbnail tonemapping is broken by HDR, it is actually the tonemapping for the entire UI that is broken. I just never noticed because i use a hyperminimalist transparent ozone UI, so the issue is effectively invisible if i have a game running.
2 Likes
No the colors, but the content has wrong brightness/over brightness.
With HDR enabled only in RetroArch, the content looks like this:
With HDR enabled in both the system settings and in RetroArch settings, the background image doesn’t get that wrong colors (I hadn’t realized that before 
), but the content looks like this:
In SDR mode (i.e., HDR disabled in the system and RetroArch), it looks like this:
No matter what I tried, during gameplay using the Sony Megatron the brightness or colors were always incorrect/wrong with HDR enabled. @Cyber tried to help me a lot on the RetroArch subreddit until I realized something was wrong, and I had assumed until now that it was the missing HDR metadata, now I’m totally unsure.
2 Likes
I think this is two separate issues. Most likely the problems you are seeing with content brightness and such is related to the lack of metadata, while the UI/thumbnail tonemapping stuff is the same issue as the one i can replicate on Win10.
3 Likes
Just for the sake of accuracy, just now I realized that image #2 I posted above was the wrong one (it was meant to be HDR enabled in both the system settings and in RetroArch settings, but I only enabled HDR in the system settings). I can no longer edit the post, but the correct image with both HDR settings enabled still has the over brightness, so I’ll just leave it like this.
1 Like
From just the image I’d say both the shader and the internal scanline generation is on - although when you load a shader it turns off the in built menu HDR scanlines you can turn them on after the fact and maybe thats happened here somehow. Anyway regardless just make sure Scanlines is switched off under the Settings->Video->HDR menu.
Sony Megatron V2.6.2 - Code Refactoring Update
So I’ve just submitted a pull request (#840) for Sony Megatron v2.6.2 that focuses on code refactoring and maintainability improvements. This is purely a technical update with no visual changes to the shader output.
Its mainly for the likes of @Azurfel who was wanting HDR to convert from DCI-P3 etc. Well now separately to the sony megatron there is a hdr-v2.slangp preset that uses the hdr-v2.slang shader that you can drop in at the end of any preset for a full HDR replacement of the internal hdr shader.
I’ve also create -config versions of sony megatron to allow people to store off paper white, max nits on a per preset basis.
What Changed?
Major Code Refactoring:
- Extracted common shader code into reusable header files
- Created dedicated include files for different shader passes:
-
hdr_pass_v1.h/hdr_pass_v2.h- HDR processing logic -
sdr_pass_v1.h/sdr_pass_v2.h- SDR source processing -
sony_megatron_v1.h/sony_megatron_v2.h- Main shader implementations
-
- Added new configuration variants for easier customization
- Net Result: Reduced code duplication by ~2,400 lines (3,087 additions, 2,317 deletions)
Bug Fix:
- Fixed broken reference path in
crt-sony-megatron-gba-gbi-hdr.slangpthat would have caused the preset to fail loading
Why This Matters
This refactoring makes the Sony Megatron shader codebase much more maintainable:
- Easier to update: Shared logic is now in one place instead of duplicated across multiple files
- Easier to customize: New shader variants can be created by simply including the appropriate header files
- Less error-prone: Bug fixes only need to be applied once in the header file
- Cleaner codebase: Easier for contributors to understand and modify
Technical Details
The shader code is now organized into a modular structure where each .slang file defines its parameters and configuration, then includes the appropriate header file for the actual implementation.
For Users
There are no visual changes or functionality changes in this update. If you’re currently using Sony Megatron shaders, they will continue to work exactly the same way. This is purely a behind-the-scenes code cleanup and functionality addition for power users.
4 Likes
Just to add the hdr-v2 shader supports colour conversion (and boosting) from DCI-P3, NTSC, PAL and AdobeRGB directly to rec2020. This should cover all @Azurfel bases. I will in a future update add this support to Sony Megatron but its a bit more tricky because of how it deals with NTSC PAL etc gamuts already.
2 Likes
Thanks for all this its greatly appreciated.
This all boils down to where we inverse tonemap and convert to BT2020. When the menu is up we need to go back to the old way of having a post process rather than doing it as part of the scale up to desktop resolution. Either that or do it properly and make the menu actually HDR aware which Im guessing is far more work but would fix the super bright whites.
1 Like