Nevertheless, i’m posting the updated version. A new threshold parameter is added. Hires version is also ‘supported’. Hopefully mipmapping with D3D11 is fixed someday, also vulkan hdr with amd’s more recent adapters. 
Download link:
4 Likes
That works much better, thanks!
I’m now using a preset with brightboost dark and brightboost bright at 1.0, using the HDR settings in RA to adjust for the loss of brightness and it looks great! Colors seems more natural and contrast looks much enhanced, while the image brightness remains vivid.
I think we’re almost there now, but while testing I noticed a thing.
If you go into the 240p test suite and then to “White & RGB Screen”. Here you can cycle through five screens: White, Black, Red, Green, Blue (cycle though them with LB/RB on controller or Q and W on keyboard).
First don’t use the the Lower Dynamic Brightness (OFF, default setting) and cycle through the screens. You’ll notice how every screen has equal perceived brightness. E.g. the red screen looks equally bright as the white screen. Same goes for the other colors.
Now enable Lower Dynamic Brightness, and for testing purpose use a low value like 200 or 150. Do the same, sycle through all screens. You’ll notice the Lower Dynamic Brightness is only active on the white screen, darkening it by quite a bit, but the Red, Green and Blue screens remain unaffected, causing a disbalance in perceived brightness cycling through the screens.
Would be great if there would be a solution to this.
Preferred outcome would be that the Lower Dynamic Brightness would lower the brightness equally on each of the screens from the 240p “White and RGB SCreen” test, such that cycling through the screens the perceived brightness is the same for each of the screens.
With that adaption I think it would be perfect!
Edit: is this about luma versus relative luminance?
1 Like
This one is a bit tricky, because the way average brightness is calculated. Mipmapping produces the average color of the screen and current approach considered how many sub-pixels are emitting light and how strong the light is.
Using luma weights would in fact boost the white brightness even more. This one brings us to using the ‘max(r,g,b)’ color calculation, which works good only on the RGB screens you mentioned, but not on ‘normal’ screens which use different colors.
Example: 1/3 of the screen is max. red, 1/3 max. green and 1/3 max. blue. Mipmaps produce the average color of (1/3, 1/3, 1/3), resulting luminosity is 1/3. On pure red, green or blue maxed screens it would be 1.0. Here is the problem.
I think the ‘subpixel count and intensity’ method currently in place is a good compromise, mostly because it shrinks grayscale values a bit at the end. But they can be shrunk even more, if we use cubic etc. norm instead of current quadratic ( = sqrt(rr+gg+bb)).
3 Likes
Is the latest update you posted now fully compatible with D3D11? If not for working purposes would a version that is not based on mip-mapping be possible (however much slower that is, for testing purpuses it’s ok?)
Just want to make sure that what I’m testing with your latest update is actually based on how it’s supposed to be working, not that I’m getting some (unknown) crooked result because I’m in D3D11 HDR…
EDIT: have been doing more tweaking and getting really balanced results with LDB at values around 200+. Given how good most things look now, I am not so sure anymore that the mentioned “issue” with cycling through the mentioned test in 240p test suite is actually a real thing. The whole purpose of the LDR is to top off the very bright range (allowing us to boost HDR peak luminance by quite a margin and in exchange lower the “artificial” bright boost dark to unity for better overall color performance).
With that in mind and my current testing it seems a bit unrealistic to use values < 200 for LDR. It may defeat the whole purpose of the functionality using low values for this. So with that in mind, when using values of around 200 or more the mentioned 240p white & RGB screens cycling test is actually looking quite OK/GOOD.
I think as soon as you want to lower the LDR value below something around 200, the HDR peak luminance is actually set too high already. It’s overkill for what you want to achieve at that point. It seems that lowering the HDR peak luminance is more appropriate in that case, or reasoning differently, when you’re at a point where you want to lower LDR below around 200, you have headroom with your peak luminance to increase mask settings etc.
Not sure if all that makes sense, but it’s my current thinking.
1 Like
There is an option i guess, but the effect smoothing could not be available, depending on some stuff like frame history, which also seems to be broken with d3d#.
I we look at it in another way there should be some extra motivation to continue the nice work on vulkan hdr support, as the new hdr crt shaders will definitely be a part of the mega bezel project, which works best with vulkan.
I’d go with vulkan on the long run.
Edit: i’m glad things are working out for you in some manner. I’ll definitely keep my thoughts with some more ‘mysterious’ features like average luminance, which could also improve, i think mipmaps could be dropped also etc…
3 Likes
Greetings and thanks again @guest.r.
Does this mean I have to do over any deconvergence tweaks if I was already satisfied with what the image looked like using custom deconvergence settings?
Just wondering if it would be difficult to bring it back or if all presets that used custom deconvergence settings before would automatically get an upgrade even if they looked satisfactory before?
What does this do and mean? I’ve seen the screenshots I’m seeing the improvements there and reading about the increase brightness but what’s going on at the pixel/subpixel or “phosphor” level here?
Is it that the entire mask can be shifted to align with different subpixel arrangements? Or is it that the individual “phosphor” colours can be shifted now using a similar effect as how deconvergence would shift where the individual colours would be lit?
I spend most of my time compensating for brightness loss due to using strong mask and scanline settings. This seems as though it might help in that regard but I’m just curious as to how it works and what effect it would have on the appearance of the mask patterns.
1 Like
Possibly, I would consider it the price of progress. Probably the result in presets which have deconvergence with the new shader and no additional adjustment is that the mask will look a bit sharper than before.
I can attest to it being a BIG improvement, it’s more accurate, and you can now use deconvergence without unintentionally blurring your results, and tune with halation if you want to add blur in the mask.
Thanks @guest.r you rock!!!
4 Likes
I completely understand this and that’s one of the reasons why I’ve been taking so long to update my 1080p Optimized presets which reference my 4K Optimized ones. In most areas the inherited changes have caused improvement while I still felt the need to improve things in other areas. The irony is that the final change that added the icing on the cake and improved the colour, outlines (by softening them very slightly) and contrast while reducing the screen door effect in my Composite - Pure 1080p preset was turning Deconvergence On with my custom tweaks from my last round of updates.
This is not a complaint in any way just sharing my experience and trying to understand what to expect.
At least I know what the image looks like now so I might better be able to reproduce it after the update or possibly make things look even better than before!
I knew this change was coming so I’m wondering now If I should disable the deconvergence before releasing it or just hold off on this release until I rework it after testing things with the new version. Has HSM Mega Bezel Reflection Shader been updated yet to include this version of CRT-Guest-Advanved?
Most likely I’ll just leave off the deconvergence for now so that users can still get the benefits of the updated preset (minus that minor icing). Then after HSM Mega Bezel Reflection Shader is updated I’ll have an updated preset with a reworking available. So this preset in its current form may never see the light of day.
I’ll see if I can share some before and after screenshots so that you’all can visualize what I’m talking about.
For the best viewing experience of these screenshots I suggest you right click on the image then click, “Open link in new tab”, “Open link in new window” or “Open image in new tab”.
Then click on the new window or tab and press the F11 key for a fullscreen view.
CyberLab__Composite-Pure__1080p__ADV - (Deconvergence On)
CyberLab__Composite-Pure__1080p__ADV - (Deconvergence Off)
CyberLab__Composite-Pure__1080p__ADV - (Deconvergence On)
CyberLab__Composite-Pure__1080p__ADV - (Deconvergence Off)
Besides this 1 new 1080p preset I’ve been working on, none of my recent 4K Optimized presets use Deconvergence at the moment. I disabled it in my current release in order to experiment with having all triads perfectly aligned and I kinda like that look (at least for now).
Most definitely, and @HyperspaceMadness and the rest of the Mega Bezel team too of course! Legends in the making!
3 Likes
It shouldn’t be too hard since you can also use the deconvergence strength parameter, which also works ‘better’. In general there is a correct way to do deconvergence with crt shaders with masks and this is before masks are applied.
This one was a bit elusive with the older code base since you can squeeze only very little in the alpha channel, some values must be calculated twice, artifacts are possible…also lot of work and testing is involved with some solutions.
2 Likes
Not sure if Vulkan is the future, as shaders run at 1/3 the speed of glcore here. The performance loss is staggering.
It didn’t use to be this way, but then something broke it along the way, and nobody knows how to fix it (or what the problem is to begin with.)
1 Like
nVidia gpu’s are well known to have superb gl performance and compatibility, but this situation with slow vulkan might be a mix of OS, drivers and also less testing with older hw.
Vulkan is actively developed, supported and multi-platform though.
As one can read MS is doing it’s share to make d3d12 more favorable with windows in general… 
I’m sure vulkan itself is fine. I meant vulkan in RA is not great lately. It seems there’s no people anymore who know how to work on it.
Vulkan in general is great here. Usually faster than GL. Except in RA.
1 Like
In my experience the case could be that it’s simply hard to do proper testing with different hardware and operating systems. And there are also driver updates, OS updates… It’s more or less a realistic assumption that it’s currently maintained to run on more new and mainstream HW.
Vulkan and glcore are identical in perf here (intel haswell, linux). You’ll have to bisect it, I guess.
2 Likes
New Release Version (2022-02-12-r2):
Notable changes:
- hires version read a random avg. luminance value in deconvergence pass - fixed now
- average screen luminance calculation improved
- better clipping prevention of scanlines (deconvergence passes), old version could produce odd stuff
- rolling scanlines didn’t trigger correctly with very low parameter values - fixed (main pass)
- halation code trigger small fix
- halation has now stepper fall-off, but is a bit more intense. looks more compelling .
- edit: deconvergence added to bloom value
Download link:
https://mega.nz/file/E5w0hLKb#_w_iSK7Vb9kMCVFqlhxWioQeDkiJLfYMwI8KLcwol6g
11 Likes
Thanks for the update! How would this affect the bloom or deconvergence behaviour?
1 Like
It’s more in line with the older implementation, regarding the coloring.
It didn’t got implemented by itself, so i had to do it.
Works better now in general.
1 Like
Wow! and I was only now extolling the virtues of the previous version while updating my presets to cater for the changes:
Old version based on crt-guest-advanced-2022-02-01-release1
New version based on crt-guest-advanced-2022-02-10-release1
Post CRT Brightness Set to 1.80 plus Bloom Set to 0.15. Colour seems to be looking much better now.
Old Version based on crt-guest-advanced-2022-02-01-release1
New Version based on crt-guest-advanced-2022-02-10-release1
5 Likes
Hey, that’s good looking indeed. 
In general i try to improve only certain features at time not to break something else. Recent bloom changes are almost nitpicking, but it should do better coloring now.
I feel a bit bad if i’m giving @HyperspaceMadness extra work, otoh i try to implement only meaningful changes following the recipe ‘don’t fix it if it’s working’.
I’ll wait a bit if any issues are reported, but yesterday’s version should be quite complete.
6 Likes
Thanks! I think overall crt-guest-advanced-2022-02-10-release1 seemed clearer than crt-guest-advanced-2022-02-01-release1 with the potential for even more brightness without washing out things. For a very long time I disabled bloom due to the excessive blur and bleed with crt-guest-advanced-2022-02-10-release1 I think I have everything at my disposal to make the perfect preset with full mask and scanline strength without compromising on brightness, sharpness or requiring HDR.
Hopefully I can still accomplish that with New Release Version (2022-02-12-r2) as well.
What you see in the second and fourth screenshots above is only a couple minutes spent using the crt-guest-advanced-2022-02-10-release1. Imagine if I had more time. So let’s see what Version (2022-02-12-r2) brings to the table. I hope I don’t lose any clarity and brightness potential.
2 Likes