Sony Megatron Colour Video Monitor

[MajorPainTheCactus]

@Azurfel

By your wording, you may be considering this to be a distinct issue, but just in case: i am still seeing the inaccurate colors with impure primaries compared to the shaderless output with matched gamut.

OK great so I need more info than that - what are you viewing? with what settings scRGB/HDR10? Can you taken a screenshot of both and tell me what colour values are off?

So in HDR there is no such thing as shaderless - we dont directly write to the back buffer, theres a shader in between (that could be at fault as well) so are you comparing SDR mode to HDR mode?

I bet even then you’ll see difference because of luminance differences caused by the scanline simulation but lets figure out what you’re seeing and where it might be coming from first.

@Azurfel

Shouldn’t that be “(0.00, 0.0, 0.0), (0.33, 0.92, 0.09), (0.0, 0.0, 0.00), (0.0, 0.0, 0.0)”?

Sure you can do that - its what we had in fact but that breaks the CRT mask: we want one sub pixel in each pixel to represent one phosphor of the CRTs phosphor triad i.e:

Red: ((0.63,0.00,0.00),(0.00,0.07,0.00),(0.00,0.00,0.02),(0.00,0.00,0.00))

Green: ((0.33,0.00,0.00),(0.00,0.92,0.00),(0.00,0.00,0.09),(0.00,0.00,0.00))

Blue: ((0.04,0.00,0.00),(0.00,0.01,0.00),(0.00,0.00,0.90),(0.00,0.00,0.00))

Yellow: ((0.96,0.00,0.00),(0.00,0.99,0.00),(0.00,0.00,0.10),(0.00,0.00,0.00))

Cyan: ((0.37,0.00,0.00),(0.00,0.93,0.00),(0.00,0.00,0.98),(0.00,0.00,0.00))

Magenta: ((0.67,0.00,0.00),(0.00,0.08,0.00),(0.00,0.00,0.91),(0.00,0.00,0.00))

White: ((1.00,0.00,0.00),(0.00,1.00,0.00),(0.00,0.00,1.00),(0.00,0.00,0.00))

Black: ((0.00,0.00,0.00),(0.00,0.00,0.00),(0.00,0.00,0.00),(0.00,0.00,0.00))

From these original r709 colours in r2020 space:

Red: (0.63,0.07,0.02)

Green: (0.33,0.92,0.09)

Blue: (0.04,0.01,0.90)

Yellow: (0.96,0.99,0.10)

Cyan: (0.37,0.93,0.98)

Magenta: (0.67,0.08,0.91)

White: (1.00,1.00,1.00)

Black: (0.00,0.00,0.00)

In our original colour setup as per your reply white would come out as:

(0.63,0.07,0.02), (0.33,0.92,0.09), (0.04,0.01,0.90), (0.0,0.0,0.0)

Which is wrong I think. White r709 in r2020 is still (1.0,1.0,1.0) as above

[Azurfel]

@MajorPainTheCactus

OK great so I need more info than that - what are you viewing? with what settings scRGB/HDR10? Can you taken a screenshot of both and tell me what colour values are off?

It’s the same issue i was talking about here. Nothing has changed since then. Literally all colors have been clearly incorrect on my display using every version from Megatron 2.6.5 on, regardless of settings.

I have generally been using test images from the SNES version of the 240p Test Suite for testing purposes.

@MajorPainTheCactus

So in HDR there is no such thing as shaderless - we dont directly write to the back buffer, theres a shader in between (that could be at fault as well) so are you comparing SDR mode to HDR mode?

If i toggled shaders off and on with Megatron 2.6.2, the colors approximately matched. Shaders toggled off also approximately matched RetroArch running with shaders toggled off in SDR.

Colors aren’t even close to matching when doing this with any version of Megatron from 2.6.5 on.

@MajorPainTheCactus

Sure you can do that - its what we had in fact but that breaks the CRT mask

Define “breaks the CRT mask” in this context please. Because i’m starting to suspect that may be what i consider correct, hardware-accurate behavior.

That is: if only the pure primary color red (255, 0, 0) is on screen, only red phosphors should be lit, right?

[MajorPainTheCactus]

@Azurfel

It’s the same issue i was talking about here. Nothing has changed since then. Literally all colors have been clearly incorrect on my display using every version from Megatron 2.6.5 on, regardless of settings.

So how I test the Sony Megatron and the internal hdr shader (and vice versa) in HDR is to turn on off shaders to compare the internal shader Ive written with the Sony Megatron and I always make sure they match. So in order for that to match though the correct version of Retroarch has to be the same as the correct version of the Sony Megatron. At the moment the very latest version of Retroarch and the very latest slang shaders as per github would be needed. Im not sure if you just get latest nightly and download the slang shaders in Retroarch you would get the latest sony megatron so make sure youre getting the shaders from slang_shaders github repo directly.

We should definitely get to the bottom of why we’re seeing differences: another test is to switch on/off scanlines in HDR10. Switching on/off when no custom shaders are applied will allow you to match the internal shader with and without scanlines (this will allow us to find issues excluding the sony megatron in the scanline generation). Then turn on scanlines and turn shaders on/off with the sony megatron in default settings - this should allow you to match the sony megatron identically with the internal shader. This should pin point whete any difference youre seeing are coming from.

[Azurfel]

@MajorPainTheCactus

another test is to switch on/off scanlines in HDR10.

Switching scanlines on/off doesn’t work for comparisons, since the Luminance settings need to be substantially higher for scanlines/Megatron than they should be for baseline output.

I consider our baseline for “correct” HDR output to be shaders off, both Luminance settings at 100, Colour Boost to Accurate, and scanlines off. Those settings are a (color) match for Retroarch in SDR with shaders off using Windows’ SDR to HDR conversion (but not a gamma match, because the Windows SDR to HDR gamma is wrong on purpose.)

Alt tabbing between one instance using those settings, and another instance with the internal scanlines on and the Luminance settings at 670, the internal scanlines have the exact same color accuracy issues as Megatron 2.6.5-2.8.0 with equivalent settings.

@MajorPainTheCactus

At the moment the very latest version of Retroarch and the very latest slang shaders as per github would be needed. Im not sure if you just get latest nightly and download the slang shaders in Retroarch you would get the latest sony megatron so make sure youre getting the shaders from slang_shaders github repo directly.

Straight along, all of my testing has been done using the latest nightly build unless i specifically stated otherwise, with shaders downloaded directly from the github repository and placed into renamed folders for versioning purposes (so Megatron 2.8.0 is hdr280, for example).

[Azurfel]

@MajorPainTheCactus

In our original colour setup as per your reply white would come out as:

(0.63,0.07,0.02), (0.33,0.92,0.09), (0.04,0.01,0.90), (0.0,0.0,0.0)

Also, thinking on it, i’m pretty that was the correct behavior? We aren’t trying to pass-through the Rec2020 white, we are simulating the phosphors of our target gamut, which additively cause us to perceive the balanced combination of red, green, and blue as white.

[Azurfel]

To give another example of hardware accurate color primary behavior, @Hyllian posted a useful image of Sonic the Hedgehog running on a Sony 21FS140 here.

Note that in Sonic’s right shoe, and in the darkest patches of grass, only a single color of phosphor is illuminated. The unlit phosphor colors are visible only due to reflected/refracted light (which is why they are unbroken lines with no scanline gaps).

If we look at a direct capture from the game (using Genesis Plus GX):

we can se that Sonic’s right shoe is a pure red (239, 0, 0), and the darkest patches of grass are a pure green (0, 101, 0):

In Megatron 2.6.2, the resulting simulated phosphor pattern was more or less identical to the one seen in @Hyllian’s photo (aside from the unlit phosphors, which Megatron currently has no option to simulate, nor am i convinced that one is needed in practice):

In the portions of the image with a pure primary color (the shoes and the darkest patches of grass), only “phosphors” of that primary color are illuminated, just as was the case in the 21FS140 photo.

Megatron 2.8.0 instead illuminates literally every single simulated phosphor to one degree or another in every part of the image that isn’t full black:

which seems like the expected result of the “Mask Accurate” methodology as it has been described to me (that is, if a pure red is split across all three “phosphor” colors, it makes sense that all three “phosphor” colors would be lit up).

I am not certain this is solely responsible for the color inaccuracy i have been observing in Megatron 2.6.5-2.8.0, but it has certainly made me strongly suspect that “Colour Accurate” also had the more accurate masks all along.

[hunterk]

I think you might have it backwards. AFAIK, “mask accurate” should be the one that ensures that the right number of subpixels are lit, so you have the right mask, even if the colors are wrong at a macro level, while “color accurate” ensures you have the right colors at a macro level but the mask is going to look wrong because the subpixels of the host display are not the same color as the phosphor primaries.

If I’m the one who has it backwards, or I otherwise misunderstood the topic of discussion, please disregard

[Azurfel]

@hunterk

I think you might have it backwards. AFAIK, “mask accurate” should be the one that ensures that the right number of subpixels are lit, so you have the right mask, even if the colors are wrong at a macro level, while “color accurate” ensures you have the right colors at a macro level but the mask is going to look wrong because the subpixels of the host display are not the same color as the phosphor primaries.

That was what i had assumed was the case too, until recent discussions suggested otherwise.

I’ve always found that the “Mask Accurate” setting had the same issues Megatron 2.8.0 has for me, with inaccurate colors and all simulated phosphors being lit up even in primaries. That is part of the reason i always recommended Colour Accurate.

[Cyber]

@Azurfel

I’ve always found that the “Mask Accurate” setting had the same issues Megatron 2.8.0 has for me, with inaccurate colors and all simulated phosphors being lit up even in primaries. That is part of the reason i always recommended Colour Accurate.

Not looking to get into any long debate about this here but upon finally getting proper RWBG/WOLED support in Sony Megatron Colour Video Monitor, which was something that I had advocated for after experiencing it long before in CRT-Guest-Advanced via Mega Bezel, WOLED users including myself noticed additional subpixels being lit in our photos virtually every single time, so we’d see maybe orange or yellow (or sometimes other colours) in between the R-G-B and could never get proper R-G-B triads despite supposedly finally getting support for the subpixel layout and mask that had worked for years before when using CRT-Guest-Advanced.

This predates your arrival to this thread. If you go back and read the old posts and view the photos which document the history of the RWBG implementation, you will see that the original Colour Accurate Mode always looked wrong in WOLED users’ photos.

Unfortunately MajorPainTheCactus didn’t have such a display to test with, so he relied on our reports and testing.

I complained about that issue and he implemented the Mask Accurate Mode, which resolved it. I have been grateful for it ever since.

You came along a while later and when you tested my Preset on your OLED TV, things looked very off to you, unlike anything I had ever seen or any other user of my Presets or Sony Megatron Colour Video Monitor had ever reported or posted before. That is also documented here.

Almost immediately upon your arrival you’ve been advocating for Colour Accurate Mode to be used and that Mask Accurate is unnecessary, not accurate and should even be removed.

Just stating what has been observed and documented here but I do implore you to go back and see why we needed a Mask Accurate Mode in the first place.

For LCD Displays it wasn’t necessary and the comparison photos taken using those didn’t exhibit the same additional subpixels being inserted into the mask like the WOLED Displays’ photos were.

[Azurfel]

Ah, so that is what Mask Accurate was supposed to be doing. Colour Accurate has never done anything like that on my LG C1 with a WBE/“Evo” panel (a WOLED). Colour Accurate always had masks that look much like 2.6.2’s masks for me, and Mask Accurate’s masks always looked like 2.8.0’s masks. (See this post for closeup photos).

Perhaps it only happened on the 2016-2018 or 2019 models? Further testing would be required. (You observed this happening on one of the 2016 WOLEDs, correct?)

@Cyber

You came along a while later and when you tested my Preset on your OLED TV, things looked very off to you, unlike anything I had ever seen or any other user of my Presets or Sony Megatron Colour Video Monitor had ever reported or posted before. That is also documented here.

That was the result of a bug introduced in the 2022.10.25 build (i still have the old versioned folders that i used to bisect) that was causing near-black colors to significantly overshoot their target luminance. Others verified that it was happening to them as well, and you yourself eventually found that it was happening to you, and you had just calibrated some of your presets around mitigating and minimizing it.

The bug was fixed and Megatron was better for it. If this is meant as an argument that i should assume that my entire setup is giving fundamentally invalid results and i should stop testing and posting about issues i notice, then i honestly can’t say that you have convinced me.

@Cyber

Almost immediately upon your arrival you’ve been advocating for Colour Accurate Mode to be used and that Mask Accurate is unnecessary, not accurate and should even be removed.

I have never said I thought any option should be removed. I have consistently advocated for as many useful options as possible, and even added additional options myself in the AzMods fork of Megatron, without ever removing a single one. If I had wanted Mask Accurate gone, I could have very easily removed it from those AzMods versions.

If you are referring to this post, you suggested that no WOLED user ever said anything about Mask Accurate having color accuracy issues. At which point i, a WOLED user, pointed out that I had, in fact, found that to be an issue. That seemed like very relevant information in my opinion, and it certainly wasn’t a suggestion that i was glad that the option was gone or anything like that.

[Azurfel]

Relatedly, i have made a preset pack to facilitate properly testing this issue on other displays:

~2.8.0 color and mask accuracy testing

This includes presets with matched settings for Megatron 2.6.2 and 2.8.0, along with matching AzMods20251218 Megatron v1 presets for Colour Accurate and Mask Accurate.

The matched settings are derived from the 2.8.0 defaults, with the RBG “WOLED” subpixel layout selected. The included Megatron 2.6.2 is also a modified AzMods version, because the original Megatron 2.6.2 no longer loads on current nightly builds, due to changes made during the recent scRGB updates.

Please see this post, and if possible, use that same scene in Sonic the Hedgehog to test and take pictures, since we have a good photo of an actual Trinitron to compare our results with (thanks again to @Hyllian).

[Cyber]

@Azurfel

I have never said I thought any option should be removed. I have consistently advocated for as many useful options as possible, and even added additional options myself in the AzMods fork of Megatron, without ever removing a single one. If I had wanted Mask Accurate gone, I could have very easily removed it from those AzMods versions.

If you are referring to this post, you suggested that no WOLED user ever said anything about Mask Accurate having color accuracy issues. At which point i, a WOLED user, pointed out that I had, in fact, found that to be an issue. That seemed like very relevant information in my opinion, and it certainly wasn’t a suggestion that i was glad that the option was gone or anything like that.

Okay, my apologies I think I was mixing up what you were saying about Vivid Mode vs Original Colour Mode. It seems like you were neither a fan of either Vivid Mode or Mask Accurate Mode.

I’m glad you were able to review the history and original purpose of the Mask Accurate mode.

I could have sworn I read a little back and forth between you and MajorPainTheCactus concerning the fact that the Mask Accurate Mode in the new Sony Megatron is also supposed to be Colour Accurate, so I interpreted that as you having an issue with the Mask Accurate Mode in general, both in the old and in the new Sony Megatron Colour Video Monitor.

Anyway, I trust your judgement and measurements in most cases so I trust that there really is some sort of issue with the lit subpixels not matching the real Trinitron Photo when using Mask Accurate Mode.

It’s good that we have people like you around to provide proper testing and constructive critism in order to ensure that the quality of what we’re doing here is second to none. I just feel bad for @MajorPainTheCactus sometimes for all the work that he has to do and also when we and others may not fully understand his vision.

@Azurfel

Please see this post, and if possible, use that same scene in Sonic the Hedgehog to test and take pictures, since we have a good photo of an actual Trinitron to compare our results with (thanks again to @Hyllian).

Are you suggesting that I test this on my 2016 WOLED? If so, that display is no longer in service and I have since moved on to miniLED.

@Azurfel

Perhaps it only happened on the 2016-2018 or 2019 models? Further testing would be required. (You observed this happening on one of the 2016 WOLEDs, correct?)

Yes, if you check back in the posts and photos from myself and other users, you will see that it was present in all of our pics. However in some of my very early photos where I had things deliberately setup incorrectly, the extra subpixels were not lit. I think that was when I was using an HDR Preset in SDR mode and HDR was off in RetroArch Video Settings. Once HDR was On and I was using an HDR preset, the problem persisted.

Will now go back to check and verify this.

Here are the relevant posts showing the correct era and the settings where the issue was noticed and other related posts:

Sony Megatron Colour Video Monitor

Sony Megatron Color Video Monitor, Aperture Grille - RRBBGGX LG 55OLEDE6P [20220813_202609] [20220813_202930] [20220813_203008] Any questions?

Sony Megatron Colour Video Monitor

Greetings @MajorPainTheCactus, I hate to be the bearer of bad news but something seems amiss in the new OLED Mask Layout. I noticed it when I tried the 8K, 600TVL Mask before you made your adjustments but I thought I’d wait until you updated and tested before saying anything. So I tested the 4K, 300TVL using the Sony PVM 1910 HDR preset and these are my results. [20220824_001757] Another CRT Shader in RRBBGGX mode [20220823_202702] Old modified version of Sony Megatron Color Video Monito…

Sony Megatron Colour Video Monitor

It’s the only one that supports HDR. I tried the new version using the Sony PVM 2730 HDR Preset and I was able to reproduce my “correct” looking results from 10 days ago. Basically I had to use that preset and reproduce my settings for RetroArch HDR and Megatron SDR for it to look the same. I’m sure it might look similar with RetroArch SDR and Megatron SDR. When both RetroArch and Megatron HDR are on with that preset it doesn’t look as bad as the Sony PVM 1910 in HDR mode using the new OLED L…

Sony Megatron Colour Video Monitor

Family comes first! No pressure! I’ve been following this and I’m looking forward to redoing my OLED Mask tests to see if there’s an improvement after the fix. Remember us OLED users have been getting similar strange colour anomalies when HDR is enabled but things look pretty clean in SDR mode. Thanks @rafan, @GPDP1 and @MajorPainTheCactus! Keep up the great work!

Sony Megatron Colour Video Monitor

Excellent! Looking forward to testing this! You’re most welcome! Wow! Those “phosphors” look like phosphors!

Sony Megatron Colour Video Monitor

CRT-Sony-Megatron-Sony-PVM-2730-HDR HDR On in RetroArch/Windows, HDR On in Preset RWGB (OLED) Subpixel Layout, 300TVL, NTSC-U [20220922_051024] Note: the dark grey horizontal line is from the shader parameters menu. [20220922_050923] RWGB OLED Photos: Samsung Galaxy A71 Camera: Pro Mode, ISO 100, WB 5000K, Aperture Speed 1/60, Manual Focus. Oh yeah, it’s fixed alright! Next stop, verifying if the Slot Mask presets work fine with OLED and if not designing one that does?

Sony Megatron Colour Video Monitor

I’m not going to argue with you but this is certainly not where I started. I went through all sorts of combinations of lower, higher and in between values for the settings you have mentioned to arrive at this point but I don’t mind following your instructions and advice in order to attain the proper settings once and for all. It might take some time between me trying your recommendations and bringing back results though but I think it would be worth it. Here is what RTINGS has to say about my …

Sony Megatron Colour Video Monitor

This is the way. I just swapped out the old NTSC Adaptive for the updated Guest-Advanced-NTSC version and came up with a new mind blowing (at least to me) Sony Megatron Color Video Monitor preset! It’s really seems better in every way than the old NTSC Adaptive while maintaining similar functionality as well as usability. Too bad sharing a regular screen shot isn’t going to convey how awesome this preset looks in person. There must be a way to capture proper screenshots using RetroArch in H…

Sony Megatron Colour Video Monitor

Subpixel Accuracy! [20230915_175622] [20230915_191525] [20230915_175639] [20230915_191622]

Potential Spoiler Alert

<a href="https://ibb.co/xJMnLHF" data-bbcode="true">[image]</a> <a href="https://ibb.co/7rSF8Bs" data-bbcode="true">[image]</a> <a href="https://ibb.co/pn3KnCc" data-bbcode="true">[image]</a> <a href="https://ibb.co/CVJdN2j" data-bbcode="true">[image]<…

[anikom15]

Sounds like the parameter descriptions need to be more specific.

[Azurfel]

@Cyber

Are you suggesting that I test this on my 2016 WOLED? If so, that display is no longer in service and I have since moved on to miniLED.

I think it would be helpful see how all display types behave in this regard, so whatever you are currently using, if you feel like it, do check and see how each of those presets looks, and how their phosphor layouts compare to that photo of an actual Trinitron. (Currently, you will have to change the display type/subpixel layout of the presets manually. I should probably just update that pack with presets for all 3 layouts.)

@Cyber

Okay, my apologies I think I was mixing up what you were saying about Vivid Mode vs Original Colour Mode.

Oh! That was when @MajorPainTheCactus was talking about keeping the HDR options menu in RetroArch itself as minimal as possible. My personal preferred option was and is exactly what ended up happening, with multiple “Colour Boost” options to cover various use cases, or a HDR shader with additional advanced options (and @MajorPainTheCactus ended up giving us both of those things, which was even better.)

@Cyber

It seems like you were neither a fan of either Vivid Mode or Mask Accurate Mode.

Not personally, no. But the more options the better so long as they aren’t causing issues for those who don’t want to use them. I actively loathe edge enhancement/sharpening as an effect, but i would never in a million years remove it from the decoupled versions of crt-guest-advanced-ntsc i’ve been making for the sake of my personal distaste.

And i’ve still found that the old “expand_gamut” function that the Original/Vivid parameter used is the best way to add additional gamuts to Megatron. You never know when it will turn out that an option can be expanded into something bigger.

[MajorPainTheCactus]

@Azurfel

Switching scanlines on/off doesn’t work for comparisons, since the Luminance settings need to be substantially higher for scanlines/Megatron than they should be for baseline output.

Look you need to trust what I’m saying to you - yes there are overall luminance differences but at the peak (middle) point of the scanline there aren’t. So if you can ignore the sony megatron for the time being (which is a far more complex shader) and see if you can see the issues between HDR output with scanlines off and the HDR output with scanlines on we can start to figure out where youre seeing differences.

[MajorPainTheCactus]

So you’re comparing an SDR image with a HDR image but what youre not taking into account with the above comparisons is the colour of the actual light emitting hardware - the red phosphor in the former case and red OLED sub pixel in the latter case. Both red’s at full red (1.0, 0.0, 0.0) will look totally different. In order for full red in the latter case to look like full red in the former case we need to transform it i.e apply the r2020 transform matrix to the full red i.e SDR r709 (1.0, 0.0, 0.0) == HDR r2020 (0.63,0.07,0.02).

This becomes even more odd with pure green SDR r709 (0.0, 1.0, 0.0) == HDR r2020 (0.33,0.92,0.09) Notice how much red is turned on - you will see that red sub pixel.

BUT if you took a step back from a certain distance the two reds (or two greens) will look identical Your OLED screen will look identical to your Sony 21FS140.

So there’s an important lesson here HDR will ALWAYS look different in terms of its close up phosphor pattern to SDR. If you want accuracy on this level use a CRT or an OLED with an insanely bright SDR. But if you want the brightness of HDR to accurately match in colour the SDR then you are going to have to put up with a different sub pixel pattern BUT it will look the same.

The important point to note is that the mask does not effect chromacity whether you do it this way:

Mask BEFORE transform: (0.63,0.07,0.02), (0.33,0.92,0.09), (0.04,0.01,0.90), (0.0,0.0,0.0)

or this way:

Mask AFTER transform: (1.0,0.0,0.0), (0.0,1.0,0.0), (0.0,0.0,1.0), (0.0,0.0,0.0)

Both display the exact same white as both r2020 and r709 share the same D65 white point.

The latter however is more accurate to how a CRT would work when an OLED uses a CRT mask which after all is what we’re after.

[MajorPainTheCactus]

Just to add I will investigate if these differences are to be expected or there is a genuine bug in here so fear not but I am trying to make you aware that differences in pixel patterns are to be expected but not chromaticity from a certain distance away.

[Cyber]

By the way folks, some news about RTINGS:

Revamping Our Membership Program

[Azurfel]

@MajorPainTheCactus

Look you need to trust what I’m saying to you - yes there are overall luminance differences but at the peak (middle) point of the scanline there aren’t. So if you can ignore the sony megatron for the time being (which is a far more complex shader) and see if you can see the issues between HDR output with scanlines off and the HDR output with scanlines on we can start to figure out where youre seeing differences.

As i said, the internal HDR menu scanlines display the exact same color inaccuracies as Megatron 2.6.5-2.8.0.

I have additionally been mentioning the old Mask Accurate/Colour Accurate setting, because the inaccurate colors in 2.6.5-2.8.0 are inaccurate in the exact same way that i found Megatron v1 had inaccurate colors with Mask Accurate selected, and, as far i understand it, the 2.6.5-2.8.0 methodology is effectively a re-implementation of Mask Accurate.

@MajorPainTheCactus

BUT if you took a step back from a certain distance the two reds (or two greens) will look identical Your OLED screen will look identical to your Sony 21FS140.

The color inaccuracy remains unchanged even from 7’ away.

That said, i think it’s best i be upfront and forthright about this: i sit about 3-3.5’ away from my 48" C1 that i use as a desktop monitor, and that absolutely isn’t changing. If the colors don’t look correct at that distance, then i fundamentally will not ever consider the result to be usable.

If you consider that to fall outside of valid use cases for some reason, that is your prerogative, but i am seeing these color accuracy issues at my normal sitting distance, not by pixel peeping.

@MajorPainTheCactus

But if you want the brightness of HDR to accurately match in colour the SDR then you are going to have to put up with a different sub pixel pattern BUT it will look the same.

This is the part i am genuinely not understanding: 2.6.2 demonstrably had the more hardware accurate simulated phosphor patterns, and, as far as i am seeing, also has more accurate color? So i’m not seeing what the upside is meant to be.

Like, perhaps this is a WOLED/C1 specific thing, but having looked through the old posts that @Cyber suggested i take a look at, you originally added the Mask Accurate/Colour Accurate toggle in the first place because you noticed what sure sounds like these exact same color inaccuracies that i am seeing now.

You said that the 2.6.2/“Colour Accurate” method “destroyed the mask being correct”, but i’m still not understanding what you mean by that when directly comparing 2.6.2 and 2.8.0 with matched settings. All three simulated phosphors always being lit for every color but full black in 2.8.0 is the main difference i notice in the mask, so i thought that may have been what you meant. But the individual simulated phosphors don’t look any different. What am i supposed to be seeing here?

[PU786]

We should just meet up at RetroCon (RetroArcCon?) and get to the bottom of the differences between what we’re all seeing, learn from each other the deeper aspects of making presets and scripting shaders, and actually get to share with each other so we can all see what the other is seeing.

Cyber/Guest/Cactus heading up a CRT Shaders panel sounds epic. And possibly like a total headache for them.