Hi @rafan, so I’m yet to fully digest the above but from my tests of the green screen I’m definitely seeing another issue. I see the red channel appearing in all colour systems:
I’m going to investigate where this is coming from as I wouldn’t expect it. Maybe I just need to move this all before the mask and scanlines but not sure yet.
Yes the red channel appearing is also related to gamut mapping.
If you change Colour System from NTSC-J to r709 then the red hue disappears.
Ah actually the red channel is probably right as this is a RGBX mask. The NTSC-J is applied before and shifts the image to a warmer temperature which is correct.
I’m not sure I understand you. NTSC-J (9300K) is actually cooler than 709 (6500K), so how would going to NTSC-J shift the image to a warmer temperature?
Yes the slightly tipsy topsy world of colour temperature got the better of me where a hotter temp of 9300 Kelvin vs a cooler 6500 Kelvin results in a bluer image than a redder one which just trips me up sometimes. The maths is correct in respect - when you select NTSC-J it is a bluer image.
So going back to the red appearing it isn’t because of the colour temp as I had suspected. I’ll investigate further where that red is coming from but now I suspect the transform from Rec.601 space to XYZ rather than from rec.709 to XYZ.
Ah I see, yeah so we’re talking color temp.
With regards to the matrices, I would not be surprised if that’s all fine.
Could you possibly take me shortly through how the magenta-green mask application works, how/when does a subpixel get masked and does the magenta and green in the mask need to be fully saturated to work properly?
Hello,
Sorry if this problem has already been mentioned but I’m trying to use your shaders with my new Dell G3223D monitor and the latest stable version of Retroarch. The problem is that I have totally washed out colors with all your hdr shaders. Is this a known problem and if so do you have any idea of its origin?
Thanks for your help.
Hi yoZe that’s probably that you’ve not turned on HDR in Windows and/or RA (Settings->Video->HDR). Also try the SDR version see if that makes things better for you.
@rafan I tried moving the color space conversion to before the scanline and mask generation and have had some success. There’s a problem with HDR as the values are out of whack but I’m hoping I can fix this. This’ll definitely fix the issues you’re seeing.
Sony Megatron V4.0
Just submitted the fix for the primary colour transforms breaking the mask and muddying the colours in HDR and DCI-P3 modes.
Hopefully this should address @rafan issues and hopefully @cyber and @Wilch issues on OLEDs although this would have affected all TVs but maybe it was just more apparent on OLEDs.
I think this has brightened the image somewhat as possibly whites are a bit more white but not sure.
Anyway let me know what you think.
Thanks to @rafan (and hopefully @cyber) for his attention to detail in this as it’s really helped and is greatly appreciated.
Anyway before I jump the gun let’s see if it fixes a few things!
LCD Photos: OnePlus 8 Pro Camera: Pro Mode, ISO 200, WB 6500K, Aperture Speed 1/60, Auto Focus, 48MPixel JPEG.
Excellent!
Looking forward to testing this!
You’re most welcome!
Wow! Those “phosphors” look like phosphors!
CRT-Sony-Megatron-Sony-PVM-2730-HDR
HDR On in RetroArch/Windows, HDR On in Preset
RWGB (OLED) Subpixel Layout, 300TVL, NTSC-U
Note: the dark grey horizontal line is from the shader parameters menu.
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?
Great stuff! Thanks @cyber for confirming this. The trick was to separate out the rec.2020 primaries conversion from the ST.2048 PQ conversion doing the former before the scanline and mask simulation and doing the latter (ST.2048) conversion after it.
@Cyber slightly unrelated question: what game are your photos from - I kind of recognise that font.
Oh, that’s F-Zero, SNES.
So after a some side by side comparisons I think I’m going to add an option to move the HDR primaries before and after as there is a clear trade off between the two in terms of image quality. One (moving HDR primaries before mask and scanlines) gives a crisper more accurate mask however moving them after give more accurate colours and slightly softer look.
The reason for this is that in HDR to move for example green back to the hue it has in SDR you have to add red to it i.e make it slightly yellower which is the rec.709 green we all know and love compared to the greener green of rec.2020.
This creates a problem for our mask as the mask breaks out this red into its own virtual phosphor and has the effect of over emphasising it giving all the greens a slightly more yellower look than if you do this conversion after the mask has been done. You can see this clearly on the opening map screen of Super Mario World on SNES but its there everywhere when you look.
So you can mitigate this effect somewhat by changing the colour temp to being a higher temperature resulting in a cooler/bluer image. I’ve found around the 3000 Kevlin mark seems be a good spot but you could probably go higher. However this then gets away from accuracy of the colour system NTSC-U/PAL is supposed to use D65 (6500K) whereas NTSC-J is supposed to use D93 (9300K) and we’re effectively throwing that all away.
Anyway long and short I’m not sure we’re going to get around the fact we have to do this colour conversion for HDR to make it look right and that just doesn’t play nicely with masks. Possibly the best we can hope for at this point is really bright SDR displays but they don’t look like they will ever get as bright as their HDR counterparts.
Mind you having said all that its quite difficult to tell the difference unless you know what you’re looking for. I personally prefer the original more accurate colour with the ever so slightly softer mask but that will be display, mask and user dependent!
Yeah, I was thinking about this, as well. We’re ultimately constrained by the color of the LCD subpixels themselves, since they’re immutable. The only way to change a perceived color from the subpixels’ own color is to add another subpixel to it at some level of brightness, thereby polluting our pure, perfect mask.
Just to add that although the green axis is the worst (as it has the largest shift in rec.2020) the colour temp trick won’t work for the same problems found in the red and blue axis so I’m not sure how much runway that really has.
Hi and thanks for your answer. Except in the shader menu I don’t see any menu about HDR in retroarch. I tested by enabling hdr through windows and nvdia menus but without success. Concerning the sdr shaders, they are much too dark on my screen to really enjoy them.
If colourspace transformations are affecting the mask to the point of creating additional subpixels then how is this so much different from other shaders which deliberately affect the mask using effects like Bloom for example?
If the goal is to achieve an as accurate as possible solution, I think the mask needs to be static/untouched and whatever accommodations are required to have accurate colour from an output and visual perspective should probably be worked on and applied to the “video signal”/“electron beam” even if the current theoretical methods of achieving such might be inaccurate.
It’s good to have the option to have things either way though.
