I done a measurement LCD with no any filter applied vs CRT Trinitron with 240p suite and 100 IRE.
LCD first CRT second in lux, light sensor on screen
100: 266-1231
82: 205-994
66: 147-720
53: 108-470
41: 63-231
25: 46-95
13: 18-14
25% in example is far from emit the 25% of light on a CRT
Not that I know of, but that might be something we could find (or calculate) from spec sheets with more consistency than trying to measure it with whatever equipment we have on-hand (usually just SDR phones :P)
My laptop has almost double brightness than my PC monitor, around 450 lux on full white. If I apply interlacing.glsl it halves exactly the light emitted at 225 
So you would need 2500 to use full scanlines and still have same brightness with a CRT lol
This is really great and quite interesting results as I wouldn’t have expected the CRT to be so much more bright! I’ve been lead to believe over the whole screen CRT’s are a little less bright than an SDR monitor. However my personal experience with a 2730 PVM is not that the case and a PVM is a lot brighter which ties in with your results.
So although interesting and confirming previous experience this isn’t quite what we’re after. Luminance is measured in cd/m2 i.e candellas per square meter. This is fine for a screen with constant brightness over it i.e meauring white on a LCD/OLED as RTings does but starts to pose problems for us on PVM’s where the brightness is variable across the screen i.e when you have scanlines the parts in between are dark and the center of the scanline is bright. Add onto that CRT’s are quite low res compared to modern LCD’s. As we all know 600TVL CRT has 800 lines across whereas a 4K CRT has 3840 pixels across meaning the density of emitting elements is far higher on an LCD.
So in order for an LCD to mimic a CRT displaying white we have to turn off/darken the vast majority of light emitting elements compared to a normal LCD displaying white. This is why we need the brightness to be far above a normal LCD to make up for the lack elements fully brightening themselves.
What all this mounts to is that we somehow need to measure the peak brightness within a scanline and measure its fall off.
Long and short is that I’m not sure how we do that?
Actually yes you’re right with this approach to get an overall approximation - we measure brightness on an LCD displaying constant white i.e the stock shader over a small percentage of the screen.
We then work out for a CRT shader displaying white, what percentage of pixels are fully lit in that area by adding up all the pixels SDR brightness (0-1) values (say 1000) and dividing it by the total number of pixels in the area (say 10000). This will give us an average SDR brightness level (1000/10000=0.1) that we can then multiply against the LCD’s average brightness over that area (500 * 0.1=50) and then we can use that to divide the CRT’s average brightness over that area (200/50=4). We can then use that value as our average brightness to be distributed over those 1000 pixels i.e 800cd/m2 (200*4=800).
I think thats right?
I suppose we then just apply a gaussian distibution to find peak brightness and fall off BUT this is in one direction.
I bet those BVMs emit a ton of light to compensate for the number of lines. Should be extremely bright on 31khz signals.
I tried this on my LG CX and running in HDR mode some games like Mario are so bright i thought i would go blind. I am not sure if it had something to do with my settings, but it was very uncomfortable to look at.
Pictures i took with my phone, which doesn’t really show how bright it is. There is also a weird artifact in the middle of the screen, like a line of vertical pixels that just look off. Can be seen in Akumajou Densetsu.
Isn’t it great? 
You can take advantage of that extra brightness by turning on OLED Motion (Black frame insertion)
Or increasing the strength of the mask.
With HDR you definitely need to adjust settings to your monitor - until we have a HDR calibration wizard then sadly this just has to be played about with - set peak luminance to your monitors peak luminance, paper white luminance a little above half way and contrast in the 3-4 range but it could be totally different.
Also set your scaling to integer and see if the weird line goes away - let me know if it does or doesn’t.
Wow this is great - I presume the left hand side is in cd/m2 and the bottom is just percentage of screen or something? Is this basically a histogram of the pixels?
It’s lux and white brightness on bottom
Could also be a rounding issue. It might help to multiple the texcoord assignment in the vertex by 1.00001 or whatever.
I get this too. With DX11 I get some cyan colored vertical lines and even some image crawling. Maybe one of the passes needs some filtering.
I’ll get onto this shader glitch now that I’ve added HDR support to our Vulkan driver!
Hi @Arviel hopefully this is fixed now (dependent on the github pull request being merged). Thanks to @hunterk as the rounding was exactly the problem and saved me a lot of head scratching.
In PAR aspect ratio:
Hey awesome work adding HDR to Vulkan.
Are there HDR options for luminance and all that like on DX11/12?
I couldn’t find them in the ui.
Hi sorry it hasn’t been merged yet so you’ll have to wait but yes when that pull request is merged it should be identical.
