You know, subpixel layouts aside, all this preset probably needs is an increase in Saturation to look good.
It should be able to easily match the screenshot from CRT Guest Advanced below it.
Sorry about the pictures thing, it takes a lot of physical energy for me to do that with the way I have my setup (+old) and it’s basically waiting for the stars to align on physical energy + working on shaders at the same time.
2 Likes
It’s okay man. I know there must have been some good reason. No pressure.
In hindsight, just the one white subpixel.
1 Like
I’m new here. My JVC CRT recently died, so I have re-entered the world of emulation. I am amazed that we now have phosphor-level emulation. I have a Trintron here for comparison, and shaders like Megatron and Royale look just like the CRT when I look closely as the phosphors.
So, thanks to everyone involved with making this dream come true.
Also, the discussion here is fascinating. It has warned me to never buy a panel with a white sub-pixel! I currently use a QD-OLED that works perfectly with these types of shaders. I am considering a new monitor but will wait for RGB stripe or a newer QD.
I haven’t noticed any macro shots of the shader running on a QD-OLED, so I’m curious if anyone can link some. These labels use a triangular sub-pixel formation. Has this been known to cause issues? Did development of these shader take this into account? It seems that the origin of these shaders assumed the striped pattern of LCD displays.
1 Like
You havee this mixed up. You should read more then you’ll see where we “solved” the white subpixel issue and that QD-OLED turned out to much worse than originally hoped when it actually landed. QD-OLED is the worst current display techology fror subpixel emulation because it’s triangular subpixel layout doesn’t in any fashion lend well to 1:1 mapping with a CRT’s vertically striped RGB phosphor patterns unlike every other modern display technology, including WOLED with the white subpixel. The original issue is that none of these things were documented until through sheer trial and error and determination by members of this community, we figured out how OLED subpixels work and how to get great CRT emulation out of them (at least the WOLED ones). QD-OLED will never be accurate in it’s current form, there’ll always be a little “bobble” or something worse.
Second thing is brightness, Only the highest end OLED displays of any kind can compete with even good midrange miniLED TVs on the market when it comes to Peak and especially when it comes to sustained full screen brightness, which is a staple of accurate CRT emulation, especially if you want to improve motion clarity by the use of BFI.
You’ll have to ask the CRT shader enthusiasts who also use QD-OLED for that. The only one I can identify is @MajorPainTheCactus. Striped QD-OLED just like regular triangular QD-OLED remains to be seen in order to be proven worthy.
In all of the promotional material, it shows the red stripe being taller than the green one and the green one being taller than the blue one. How that would work or map to RGB phosphors which are supposed to be of the same height, only time will tell.
I took some macro shots of my 32" 4K QD-OLED monitor. At extremely close distance, the camera can see the individual dots. So, for example, a green “phosphor” which would be a solid stripe on CRT is comprised of several tiny green vertical dots. That said, using my actual eyeballs at a distance of six inches or more, I can no longer see the dots. It just appears to be a solid stripe.
The only real “problem” is the triangular format. I’m not even sure it matters for 480i/p content or lower. The virtual phosphors will be large enough that the sub-pixels aren’t visible. This is all in regard to the extreme pixel density of a desktop monitor. I suspect it is a different story on a large OLED TV. I also suspect it would become visible if using a more detailed CRT mask (rather than aperture grille).
It also depends on how pedantic or picky the user is or their particular goals.
We can always accept compromises but if someone wanted the display with the ideal subpixel structure or characteristics for CRT emulation, QD-OLED would be very low on the list if not off of it completely, especially given the fact that there are already superior alternatives (in this niche of a context) which are readily available on the market which would provide that near 1:1 mapping between modern display subpixels and emulated CRT phosphors as intended by the CRT shader.
Even on any other display type using the wrong mask layout for the subpixel layout may not cause highly obvious appearance issues from typical viewing distances.
However, there would be anomalies caused by the inaccuracies regardless of how “acceptable” one may deem the output to be.
If you already have what you have then you can and should continue to make the most of it though.
I’m curious to know how QD-OLED will render something like this:
This is a test I made which you can run if you want to share what QD-OLED displays are capable of on the CRT-Shader emulation front:
I tested the latest nightly build last night and noticed that the Peak Brightness setting has made a return to the HDR settings menu. I took a look through the commits looking to see exactly when this was re-added to see if I could understand the reasoning behind it. I scrolled through about 1 months worth of commits but haven’t reached that particar one yet, although I have noticed that a lot of work has been done in the area of HDR within recent times.
Anyone else have any insights or opinions on this?
@Azurfel, @MajorPainTheCactus, @hunterk?
I personally don’t like the back and forth. Plus I appreciated the reasoning behind consolidating the Peak and Paper White Luminance into one HDR Brightness setting.
Can someone remind me how that was supposed to work again? Wasn’t the new HDR Brightness setting equivalent to setting the Peak and Paper White Luminance values to the same value?
Another thing that’s weird is that the values increment differently for both the HDR Brightness and Peak Luminance setting and they aren’t even one after the other in the menu.
Is this re-addition to the menu some sort of bug?
1 Like
Looks like it was this commit:
The “(HDR Menu) Brightness” setting in the appearance section is also broken now, but i don’t have enough builds to bisect if that was caused by the same commit.
1 Like
It is having zero effect on my HDR Guest Presets.
It’s doing nothing but should be making things brighter?
I don’t have any HDR-capable setups, but the guy who made the changes said it’s working fine for him in vulkan.
he asked me to share with you guys the roadmap he has planned for HDR stuff, if you all have any suggestions: https://github.com/user-attachments/files/31055976/libretro_hdr_metadata_implementation_plan_v2.2.pdf
EDIT: there’s also some stuff about color management in the pipeline. ACES 2.0, etc.
1 Like
You know, there’s a saying, if it ain’t broke, don’t fix it.
The old way of doing things - relying on RTINGS to determine Peak Luminance was flawed, confusing and now behind a paywall.
So the move to a simplified WYSIWYG actually did make things a lot simpler and the quality was there too.
At least @MajorPainTheCactus liased and actively sought the opinions of stakeholders here before doing anything major and he too had his plans for HDR going forward. So it would be nice if your contact would consider all of that while executing their vision that there are many users of these things who they need to consider, especially when it comes to stability and backward compatibility.
I know that everything wasn’t working properly in the HDR world like screenshots and the like, so focus on those low hanging fruit, but don’t unilaterally impose your vision on a community without first seeking their opinions.
I still need to dig into the pdf more, but my preliminary understanding based primarily on the commit is that this new setting is intended to support hypothetical native HDR cores, so it shouldn’t effect the brightness of existing HDR shaders.
2 Likes
There’s another saying: you can’t make an omelette without breaking a few eggs.
Unfortunately, HDR is still very much a technology in flux, so changes/breakages will happen if we want to keep up with it.
Yes, HDR cores are part of the changes, and the Peak Brightness thing is currently only hooked up for cores. Prboom and Doom3 on Windows with OpenGL (oddly enough) and Beetle-psx-hw with vulkan are all internally HDR now, so there should be a lot less quantization happening throughout the render process. I haven’t used it myself, but I assume this will make a big difference in the notoriously dark/can’t-see-shit Doom3.
1 Like
I read this:
“libretro HDR Metadata Consolidation Implementation Plan for RetroArch and the libretro API Consolidating experimental HDR environment callbacks into a single structured query + optional inverse-tonemap operator modes + related driver-side HDR metadata gaps + guidance derived from advanced HDR shader development (Sony Megatron et al.) Status: Proposal (Revised) | Date: 2026-08-14 | Scope: libretro.h API + RetroArch frontend (Vulkan / D3D11 / D3D12 / GL1 / GL2 / GLCore / Metal) 1. Motivation and Current State The libretro API currently exposes five separate experimental environment callbacks for HDR presentation state: • RETRO_ENVIRONMENT_GET_SCREEN_10BPC_CAPABLE (88) • RETRO_ENVIRONMENT_GET_HDR_PAPER_WHITE_NITS (89) • RETRO_ENVIRONMENT_GET_HDR_EXPAND_GAMUT (90) • RETRO_ENVIRONMENT_GET_HDR_OUTPUT_MODE (91) • RETRO_ENVIRONMENT_GET_HDR_MAX_NITS (92) These values are tightly coupled. A core or shader emitting RETRO_PIXEL_FORMAT_HDR10_2101010 (or the equivalent slang #pragma format A2B10G10R10_UNORM_PACK32) almost always needs several of them at once when rebuilding colour tables or deciding ownership of encoding. Separate calls risk inconsistent snapshots if the user changes settings between queries, and they burn environment command IDs for what is logically one presentation contract. Key fact: As of August 2026 these callbacks are only used by RetroArch-internal code. No external cores have shipped against them. This remains the ideal window to consolidate and remove the individual experimental entry points without breaking the public ecosystem. However, the practical consumers of the HDR presentation contract are no longer limited to internal code. The multi-year development of high-fidelity HDR CRT shaders (most notably the Sony Megatron Colour Video Monitor family and its derivatives) has made the need for a clear, versioned, and reliable contract acute. Shader authors repeatedly encounter: • Double application of inverse-tonemap / paper-white scaling when a shader already owns absolute PQ luminance. • Confusion between RetroArch menu HDR settings and per-shader parameters (users and authors both). • Lack of a single authoritative snapshot of output mode, expand-gamut policy, and whether the frontend will leave the frame alone. • Linux Vulkan presentations that ignore static HDR10 metadata, producing over-bright / incorrectly scaled results (issue #18186). • UI / menu content that shares an incorrect tonemap path with game frames when HDR is active. The consolidation proposed here directly addresses the first three points and provides the foundation needed to make the remaining driver-side and UI issues solvable without further API churn.”
It sounds like it was written by AI. The main problem is a lack of consultation with the people who actually work closely with HDR on RetroArch. MajorPainTheCactus already did a major rewrite of RetroArch’s HDR pipeline earlier this year and addressed some of those same things stated in the design goals. Why the overlap? What’s wrong with @MajorPainTheCactus’ work? He definitely consulted us here. Who is this mystery developer? Why aren’t they commenting here? Did they even read what was done with HDR this year and what was still needed to be done? There are changelogs right here in this thread.
There’s something about the way this has been done and is being done that’s leaving a bad taste in my mouth. Can you ask your user not to interfere with the hard work that @MajorPainTheCactus put in this year to improve HDR in RetroArch please?
1 Like
I’d rather talk about whether the proposals are right — that’s the only thing that matters here. It’s a working technical document, an RFC and a roadmap, and it’ll keep being updated as feedback comes in. That’s what I posted it for.
On the bigger concern, I think there’s a misunderstanding worth clearing up. Publishing this and asking hunterk to post it in this thread is the consultation. The alternative — the one I deliberately didn’t take — is pushing straight to a branch or master and letting everyone find out afterwards. You’re the audience I wanted eyes on this from.
None of this is aimed at undoing @MajorPainTheCactus’ work — his rewrite was a big step forward and it’s the foundation the roadmap builds on. The overlap in the design goals is there because those goals aren’t finished yet. HDR is still broken in a lot of places: Android, Wayland missing the metadata extension, and so on. There’s information a core currently has no way of obtaining at all — maxfall, maxcll — plus more operators than we expose today, and potentially colour management on top. I could write a book about the gaps.
Worth saying plainly: most of what’s in that PDF won’t affect shader authors at all. The parts that would touch you, like PASSTHROUGH, are the ones designed to help — and nobody has commented on those yet. Most of the rest is about accommodating true HDR cores and making the frontend play ball with them. If it lands well, a preset maker in your position shouldn’t notice much of it.
There’s something about the way this has been done and is being done that’s leaving a bad taste in my mouth. Can you ask your user not to interfere with the hard work that @MajorPainTheCactus put in this year to improve HDR in RetroArch please?
I’d rather have the technical conversation than that one. “Don’t change anything” isn’t something I can act on, but specific objections are — if there’s a proposal in there you think is wrong, or a regression risk I’ve missed, tell me which one and why. Genuinely, that’s the most useful thing you could do right now.
Timeline so nobody’s caught out: I move to implementation on 1 September, targeting mid-September for the work itself. Whatever feedback lands before then shapes what gets built. Happy to walk through any section of the document in more detail if that helps.
2 Likes
To be fair, I’d have to read the entire pdf document before I comment on any of that stuff but I know that MajorPainTheCactus had already implemented mechanisms for users who wanted the legacy behaviour - which is the Peak and Paper White Luminance settings being exposed in the shader and overriding the HDR Menu’s settings. To do this one has to append the hdr_config.slang file to any shader / shader chain.
He also made another slang available, which would add inverse tonemapping to any shader but not expose the Peak and Paper White Luminance settings and uses the HDR Menu’s settings for HDR Brightness.
Do what you need to do then, I trust that you would have already read the feedback and changelog in this thread during the HDR pipeline upgrade to be able to understand MajorPainTheCactus’ vision and the views of others’ here which were taken into consideration before arriving where we are or were before the recent changes.
I understand now that the scope of this is much wider than where things were and even more stuff might have to be changed in order to accomadate. The one thing that probably freaked me out the most and made me think that MajorPainTheCactus’ work was being reversed was the re-addition of the Peak Luminance setting in the HDR Menu after spending the last few months getting used to it’s simplicity and enjoying it. It’s not really that simple for users to calibrate things using separate Peak and Paper White Luminance values when there is no real point of reference for those values and the fact that they aren’t absolute since they can be easily skewed by things like Gamma adjustments and the like, not to mention that Peak Luminance varies by content and measurement window size.
All of the things would have contributed to use confusion and in one fell swoop, HDR Brightness solved all of that. All users have to do is load there preset and if it’s tpp dark, increase the HDR Brightness, period.
So when I see talk about user confusion and stuff like that still being mentioned in your document, it lead me to wonder if you would have been party to all that went on here within the past few months.
So please forgive my tone if I came across a little strongly. It is not that I am against change and progress. In addition to that, I am about to release my first shader project so it is imperative that things are relativey stable on the HDR front and I thought that we had reached to that point with respect to the vast majority of the Settings Menu options.
It would have been nice if one of the builds before these new changes to the HDR Menu and system could have been declared a stable build and given a new version number.
That would make it so much easier than keeping track of which nightly worked and which nightly broke this or that. It’s been too long and users need a milestone build and feature freeze before moving things too far forward in my opinion. What buil am I supposed to recommend my users who need to use the new HDR stuff? I can’t recommend the last stable so I have to recommend a nightly, but which one exactly? So you see my delimma.
I’m currently using one from around 15/04/2026.
Even this build as well as the latest nightly leave stuff to be desired as many of my Mega Bezel presets which have very long filenames and paths don’t load anymore. There seems to be some new character limit being enforced which was lower than what was there before. I do appreciate the multi-threaded shader loading though.
So yes, I do or at least did see the reimplementation of Peak Luminance in the HDR Menu as a regression.
Interesting, can you report this in a Github issue in more detail? It can be dealt with then
1 Like
It really was just a stopgap for cores until we have proper metadata reporting in. Don’t be surprised if it goes away again. That is why time is crucial for the HDR implementation plan. The longer we wait finalizing the new spec, the more you run the risk that old habits will die hard in the future if people start designing their cores around what currently exists for HDR. Right now there is still the window of opportunity to nail it down correctly once and for all and then be able to consider it done for the next few years as far as the core-to-frontend information exchange goes
1 Like