As @Nesguy pointed out above, we can already do the hybrid approach with CRT-Guest-Advanced.
I’m happy for the addition of an RWBG OLED Mask, now it’s just to load up and fine tune those presets and enjoy some games!
My vote is for Sony Megatron Color Video Monitor to remain on this path of maintaining accuracy.
Hi DevonCM hope you’re well. So where I see this shader fitting in the ‘market’ so to speak is for it to give the best experience out of the box for 400-600+ nit range TVs (not exactly sure what the cut off point is).
That’s currently a huge range of displays because it includes a lot of laptop displays and is only growing.
I think Guest Advanced does an excellent job of covering the below 400 nit TV range and I’m not going to really be able to add value there - sure I might do it a bit different here and there but itd probably be a bit worse in certain things and a bit better in other things and I kind of don’t really see the need - it’s a great shader.
I kind of see this shader as dropping the baggage of all the blurs, blooms etc to focus on accuracy and performance (if we ever get to the point where high refresh rates are required) and keeping things simple (if that’s such a thing for a shader trying to emulate a huge range of CRTs).
Just a quick point on QD-OLED I think this shader will work perfectly fine on them with a very small tweak to the vertical deconvergence on the green channel to make up for the offset in this channel.
I’m not sure what the current state of Megatron on OLED is, but the recent few shots all have something amiss - either the green is too close to the red or the blue is too close to the green (which is as expected).
There were just some commits made to hopefully fix some issues with HDR via Vulkan, if anyone wants to give that a(nother) shot. The changes should make it into the latest nightly builds in a few hours.
man i cannot be thankful enough your hard work is greatly appreciated you saved me a ton of money and searching i wish i can help you in anyway like you did
Fantastic to hear, you’re more than welcome. Please share any photos or details of your display it’s greatly appreciated.
Hopefully it’s all ironed out in latest with thanks to @Cyber for persevering with me. There does seem to be a big issue with OLEDs and HDR though - some post processing kicks in, I believe, as both Cyber and @Wilch seem to have the same problem.
I just tried this shader (2730QM SDR preset) on a Philips 276e8v 27" 4K IPS with peak nits of 350 (SDR) in a dark room and although not the brightest it was definitely acceptable IMO.
Sorry for the delay. Honestly, I can’t see the artifact with the naked eye. The iphone does a lot of real time processing too. I also didn’t test the TVs sharpness setting while taking a macro shot, I only used my eyes, but couldnt detect anything, but I believe 10 is the default for LG OLEDs and any lower actually blurs it slightly. I’ll take some new photos using a third party app without processing later
Nice shots. What preset is this and what adjustments have you made if any?
Thanks for your work on the shader. Have been playing around with it and noticed that in the 240p test suite on SNES in the color bars and gray ramp tests that the darkest colors get cropped (they are black). Happens both with HDR in RA OFF or ON.
Any idea why this is happening?
Tested with latest RA from the buildbot and your latest shader updates. Everything in vulkan slang.
Hi @rafan, first of all thanks for flagging this. So what values are you expecting the darkest colours to be? I’m not up on the specifics of the test suite but I would’ve expected the values to go from 255 to 0 at the stepping rate the SNES could handle and so result in black at the farthest step.
Things you could try are setting all the brightness, contrast etc shader params down to 0. Also in SDR making sure your monitor matches the output colour gamut usually rec .709 or sRGB.
If possible some photos of what you would expect vs some of what you actually got. I’ll take a look my end but I’m away ATM so it maybe a while before I get back.
Oh, sorry! Busy month. Sure!
Hi @MajorPainTheCactus, thanks for the answer. I tried your suggestions but the darkest value remains cropped.
I’ll explain a bit what I’ve tested and what I expected versus what I’m getting.
I’ve been testing everything in SDR mode with your SDR shaders.
The Gray Ramp test in SNES 240p test suite has a number of bars, of which the most left is black (RGB 0,0,0) and the bar second to left starts with darkest grey (RGB 8,8,8) and then increments the bars at about RGB steps of 8,8,8 (so third bar is 16,16,16, etc).
On a CRT with RGB/SCART connection that has properly set brightness and contrast, ALL the dark bars are visible, starting with the second to left bar (RGB 8,8,8). This is assuming watching in a dimly lit room.
In below picture I highlighted the bar that is cropped to black in your shader, it’s the second bar with RGB value 8,8,8.
I’ve noticed that in some cases your shader is cropping more dark color bars, so then even the third and fourth bars (16,16,16 and 24,24,24) are cropped to black. Note that they’re really cropped (clamped?) to RGB 0,0,0.
If and when you have some time you could do the following:
run the SNES 240p Gray Ramp test WITHOUT shader, then make sure you calibrate your monitor such that you can see all dark bars including the RGB 8,8,8 one.
Then apply one of your shader presets an you’ll see the darkest bars getting cropped.
You can bind keys to “previous shader” and “next shader” (I think default are “N” and “M”). If you have an empty shader next to your preset, you can switch back and forth between the non-shaded and shaded output. Very helpful for seeing the difference, what’s being different and whether the shader output is gamma neutral.
In this regard I noticed that changing between “SDR: Display Color Space: 709 | SRGB | DCI-P3” makes a large difference in the amount of dark bars cropped.
Looking at your code I see you’re applying different gamma values here, but note that changing gamma by approx 0.2 shouldn’t result in cropping the darkest bars to black (it could make them at best a bit darker, but not crop them to black).
Thanks again for the marvelous work on the shader, apart from this dark bar(s) cropping everything is great!
Brilliant @rafan thanks for the detailed description of what’s going wrong. I’ll take a look and see what’s happening.
My guess at this point if everything is at a neutral setting is that because this shader only lights up a fraction of the sub pixels it needs an extremely bright monitor to see these dark bars.
As in the few sub pixels it is lighting up in the dark bars are of the correct values as in 8 but because they are surrounded by a sea of actually black pixels we perceive these bars as being black.
I don’t know if you’ve taken a screen shot and eveyballed the values in a paint package to rule this theory out (they would be value 8 gamma corrected). I’ll try and do this as part of my investigation bear with me.
@rafan Something to try is to remove the mask. This can be done by selecting 1080p and 1000TVL in the shader params. This won’t turn off the scanlines though so only a narrow set of pixels in the vertical direction will be at ‘full brightness’ but might help with the perception of darkness.
Thanks for investigating.
I tried your below suggestion, but it doesn’t make a difference to the “8” bar, it remains black. Even though all other bars (the ones 16,16,16 to 255,255,255) get much brighter.
I noticed a few things upon further testing. Just as an example, after loading the atomiswave SDR preset: If I lower “gamma_in” to a level of 1.76 or lower, then the 8 bar “pops” in. Or if I leave gamma_in at 2.02 (the preset default) but lower “contrast” to something equal or lower than “-0.26” than the “8” bar also “pops” in.
However when doing this the rest of the image gets washed out, so it’s not a solution. I would imagine this big a gamma change is unwanted and the bar should be visible when gamma values are near defaults for CRTs and LCD (say at least inside the range of 2.0 to 2.4.) But maybe this finding provides a clue?
Further I’m not really sure how important it is that the “8” bar is really visible, since the rest of the gray ramp seems fine? And because maybe such low RGB values like the 8,8,8 bar were never really used by gfx artists in video games?
I can imagine in daylight/arcade setting one would never be able to distinguish the 8,8,8 from black, so probably artists would go with darkest values like 16,16,16 and up that would be distinguishable from real black (0,0,0) in daylight setting? But that’s just guessing…
.
@rafan so you’ve definitely found an issue but I’m not sure what it is that’s going wrong. My feeling is that’s it’s something to do with the gamma in value.
As an immediate work around just tweak the gamma in to be around 1.8 maybe a bit lower - what we’re looking for is that the first bar has a value of 1,1,1 ((8/255)^2.2)*255) and the second bar has a value of 5,5,5 ((16/255)^2.2)*255) . The colour system should probably be set to rec.709 for this as it skips the white temp which biases against the red channel.
When I change gamma in though I’m seeing some very strange behaviour (as in the center of the scanlines go to black whilst the outside of them are brighter) and I need to investigate this.
Yes this matches up with my findings - something is going on at the low end - in the very darks. My guess is that there’s some precision issue or something.
Based on my testing below a gray ramp issue seems to be introduced with the March 14th 2022 release: commit 2237891
Hope this helps in pinning down the issue.
Did some random testing with previous releases and can report the following releases have no issues, gray ramp is fine from 8,8,8 to 255,255,255:
The following releases have issues:
I will update this post when I find others.
Edit: everything tested with shader parameters brightness, contrast, saturation (when available) and gamma (when available) at neutral