It’s maybe not your objective unless you use an OLED display. 
You should also look it trough the perspective of other crt displays, crt display settings, shader target displays and their settings and of course there is also a reasonable implementation issue. IMO static glow looks too distracting if not tempered or used properly, while contrast settings, black level etc. are able to works more convincing. The problem really lies in the fact, that what you are after is a more or less a dynamic process which is at best hard to evaluate and static patterns are sortoff deceiving. But nevertheless it’s a good thing too look a couple of years ahead and also consider other display technologies like VA, QLED, OLED, AMOLED, even plasma. I’m an IPS fan atm. for the record. It’s a good reminder though, but it’s unlikely this shader will recieve a dynamic implementation.
I think what he’s wanting can only be achieved by increasing the size of the kernel on the blur passes. What size kernel are you using now?
Currently it’s up to 61x61 original resolution pixels, with sigma up to 15.0. But since it’s a shared pass for ‘more focused effects’ (will probably change it for the classic gdv version) the defaults are lower. I understand @rafan’s goal to get a regular contrast implementation, but gaussian blur will also do it’s own thing.
I have considered most of the remarks and suggestions and made some changes to the shaders.
New Release Version (25.01.2021-r2):
Notable changes:
- ‘bright’ changed to ‘Bright’ in parameter description
- Color profiles and color spaces added to the fast version
- corner/curvature/integer scaling conjuncture fixed with fast version
- corner parameters got an improvement
- regular version has separate passes for glow and bloom/halation
- gaussian blur parameter range increased
- contrast decrease parameter added
- some minor changes
Download link:
https://mega.nz/file/h14WkRLZ#yK5iJkG2peidbe5N_HufU3USF0VtE8ZupVxJPYjJEVU
Hi @guest.r thanks for all the hard work, it’s really coming together!
Any thoughts about possibly adding this mask @hunterk pointed out?
I’d rather not increase gamma, as it also increases how much (individual) bright pixel “grow” over dark pixel and I like it a bit reduced.
I find this curious given that, at times, I’ve cranked both gamma settings to max to restore colors lost due to brightness settings.
The first image uses the default gamma settings. In the second image input and output gamma are maxed.
Both images use have brightness settings at Glow 0.50, Bloom 0.50, Halation 0.50, Bright Boost Dark 0.50, Bright Boost Bright 1.50. These settings were chosen for the sole reason of demonstrating the effect. No other settings were touched.
The brightness settings also tend to distort skin tones in ways raising both gamma settings can correct. To calibrate this I’ve been using an image that’s not exactly appropriate for most forums, although you can also see it in Cotton’s “pause” face.
My own objective is of course different from yours. All I have for reference is my own memory and the raw image, so I’m simply trying to bring the NTSC shader as close to the raw image as possible ideally with a strong mask effect and just enough glow/halation to nicely accentuate the hud elements in certain science-fiction titles.
What do you think?
Raster Bloom Effect Smoothing: 0.90
R. Bloom Overscan Mode: 2.00
Raster Bloom %: 2.00I think that eventually 1440p will become the new 1080p for desktop situations, it’s trending pretty well. Unfortunately i’m sticking with a 1080p display until new models will become available at reasonable prices. That’s why i’m also prioritizing a possible new mask or two for 1440p general usage, since 2-pixel masks are a bit dense and increasing the mask size probably too coarse. I’d like to test it first though. It’s a bit far fetched i guess, but nevertheless. Maybe i’ll do some png mask testing and see if this will speed things up a bit. Png masks and coordinate calculated masks also have better compatibility with older adapters.
I respect your setup, although i would use mode 1.0, add some more r.bloom range and make it a bit more responsive. As always, different games might require different configurations.
Is there a chance some overscan/zoom/placement options will be added?
I know you can use “image_adjustment” for those functions but it would be better if there was just one standalone shader for everything you might need.
Also, does the black level work in the same way as the “image_adjustment” one? Because if you are going to use the later (so the scanlines can be seen on black color), it has to be the first shader in the chain, which takes a lot of adjusting numbers for each pass, manually.
Doesn’t GDV start with a stock shader? You should be able to just replace it with image-adjustment shader.
New Release Version (26.01.2021-r1):
Notable changes:
- adaptive contrast decrease added to standard, hires and ntsc versions
- +/- overscan options added to standard, hires and ntsc versions
- fastest version fixed, runs smoother and a bit faster
Download link:
https://mega.nz/file/MsIDhCZR#mDjAqh03OIlpmw5fIun5PiRXEqLEILKVUO7x_p-IXoE
It’s more convenient and faster to include it within the gdv shader, so it’s implemented now.
Stock shader isn’t needed? It’s there so it can be replaced by something?
Didn’t know that.
Sounds cool, I agree it needs some testing, I’m sure you can get a good idea of its good overall or not. And I agree it seems a bit too big at 1080p. I’m also interested in the performance of png masks.
PNG/LUT masks are often faster than generated masks (esp the bigger they get), but they also have file I/O, which leads to slower compile times. Probably not a big deal in this case, since they’ll only be a few KB each, though. There used to be concerns about running out of LUT slots, as well, but HSM has helped out there. It’s 16 max now, instead of 9, right?
My big mask function was meant mostly for prototyping and comparing masks, and if someone wants to use one or more, they can either hardcode the function into their shader with just the handful they actually want or they can convert them to PNG LUTs and tile them out that way.
Just wanted to say thank you, the glow is working perfectly now, even for the checkerboard test 
Haven’t tested the hires version yet, but could it benefit from the separate passes for glow and bloom/halation also?
Yup this is now max 15 or 16 per pass. This includes textures used by the pass and other pass aliases used in the pass.
You can have many more textures in the preset, so you could have 15 used in one pass then another 15 used in another pass.
That’s nice to hear. The blur viewport scaling can be also reduced somewhat (like 0.25) for better performance with large filtering sizes.
If i’m able to get some nice performance with some modifications for the hires/ntsc versions, then i’ll probably include seperate blur passes.
Note:
Right now I haven’t found at way to get the resolution size of a texture inside slang, it seems like when I try to get textureSize() I seem to always get (1,1) back , and using the auto variable Size doesn’t seem to work as well. So this means that you need to add resolution parameters as user parameters in the shader, or have them be hardcoded 
If anyone has had any success getting the resolution from textures I’d definitely be interested in examples of where this was successful.
New Release Version (27.01.2021-r1):
Notable changes:
- ‘fastest’ version optimized, small glitch fixed, should be complete now
- fast version horizontal glow quality increased a bit
- this should do unless bugs are discovered
Download link:
https://mega.nz/file/hk4hgaiT#PmcRLju_165bZ55a_B_YWgT4hlIDWautgsvf11vBhE4
Woot woot, update hype!