Yes, RetroArch is updated (nighly), it works in windowed mode, also DX12 and 11 work fine with HDR in Fullscreen.
I use two monitors, I read that it could cause some problems, I disabled the other monitor, but still no good.
3 Likes
Hmm another attempt I’m not sure whether we are better or worse - in person I think it looks better but looking at the photos below I’m not convinced. Cetainly if you now zoom in on both these images they are very close - infact you can do this by just clicking on the image it seems.
I added white correction but sadly that didn’t do what I wanted really which is to skew things in the blue direction without effecting the reds or greens. I added both tint and temperature to adjust both axis of the colour temperature spectrum but I seemed to just get further away rather than nearer. But I will continue fiddling and comparing with my PVM.
Anyway with that failed attempt I decided to add the ability to change my curves on a per channel basis. I then adjusted the blue channel scanlines as can be seen below. This seems to be the fix and actually doesn’t impact that image that much I guess because we’re not that sensitive to blues. However maybe I need to go back to my colour correction to see if I can get them a little more matched up.
I think the greens might be off a bit - you can see this in the center of his shield.
OnePlus 8 Pro Camera: Pro Mode, ISO 100, WB 3510K, Aperture Speed 1/60, about 10cm from the screen, 48MPixel JPEG.
5 Likes
That looks amazing! Looks future proof to me
2 Likes
ah, nice. That was going to be my next suggestion, since the other phosphors looked to be the right size. 
It looks like the low end of the greens and reds (and maybe the very high end of the greens, too?) could be bumped up a bit.
In any event, it’s looking extremely close already, to the point that it’s now within the margin of individual devices/calibrations, I would say.
3 Likes
Yup that’s exactly it isn’t it: the low end greens and reds. I just saw that myself in the forum pictures it’s a great way to compare! I’ll adjust it tomorrow and see what it looks like. Thanks!
2 Likes
I don’t think adding the black and white OLED mask is necessary as it kinda defeats the purpose of the shader, which is to take advantage of HDR to compensate for the extreme brightness loss of using a subpixel mask at 100% strength in order to emulate phosphor shape accurately.
I think it’s better for the shader to retain its focus and it also seems like the HDR brightness would be total overkill in this scenario. Shouldn’t W-OLED with the black and white mask be plenty bright already?
Newest shot looks absolutely fantastic btw.
Another observation: look at how uniform in width the phosphors are over the same color compared to the shader. Like all the greens in his shirt for example are the same width, while there’s a bit more of a taper with the shader.
2 Likes
Yes I’m not going to change the direction of the shader to try and support W-OLED. What I was thinking is if it was just adding a simple phosphor mask as an option I’d do that.
The question I have is what is this W-OLED mask people talk about? I’ve looked through the mask header but can’t see it (or am missing it).
Yes Ive been trying to tackle the green phosphor disparity (I presume you mean width or height of phosphors in the y direction rather than width of phosphors in the X direction?). I’m hoping sorting out the darker greens will help here. However maybe a different curve is required.
If I try to make the green phosphors larger then they merge in highlights and we lose the dark between scanlines we see in Link’s eyes. I think I need to break out the contrast from gamma and then to use a proper linear space value.
I’ll do this tonight hopefully along with another small brightness gain.
2 Likes
It’s just a black and white aperture grille pattern. One pixel dark, one pixel bright, one pixel dark. Etc.
Yep exactly.
Great work, watching this develop has been really exciting.
1 Like
Thank you for your kind words - without the passion of people like your good self I certainly wouldn’t have been spurred on to do this. It’s a great community I’ve only just discovered.
4 Likes
I’ve strangely found this whole process very exciting too - I do this all day as a job so usually it’d be a bit of a bus man’s holiday but its to the credit of the community here it’s not at all like that. Thank you for your great help and support it’s really appreciated!
1 Like
There are so many odd little things with Windows HDR. I’m guessing it’s all dynamic as hitting “f1” to bring up the overlay will change the tone-mapping even with 0 shade opacity. This can making fine tweaks of a shader prickly. Often title screens that are black with small text are dull and flat and then pop when more color hits the screen. Is that Windows, my monitor, the shader?
These are all minor inconveniences but I have noticed them while using HDR.
So what are you tone-mapping and why? Usually in HDR with rec.709 content you would inverse tone-map (to get into HDR values) and then transform down into Rec.2020 space.
I’m guessing you are doing this all in SDR (rec.709) and then relying on the built in HDR conversion (I added to RA) to get you into rec.2020.
Easier said than done with a SDR shader but I’d rewrite the shader to natively support HDR and skip any (usually) unnecessary tone-mapping i.e gamma correct, inverse tone-map, shader code, transform into rec. 2020 space. See my shader in /hdr for more details.
Of course this could be an entirely different problem.
Hmm re-reading this it could be driver/monitor support not quite working - recent Nvidia drivers have been plagued by HDR problems.
EDIT: actually what shader are you using?
2 Likes
Yeah I noticed the same, I’m also used to shader tweaking by having the RA menu fully transparent. But when you hit f1 for the menu the color slightly changes. It’s a thing from the beginning, not related to HDR imho. My best guess is that it’s only the white point that changes when the RA menu is activated.
My best guess is it’s your monitor, I had the same issues at a certain point. When I wanted to point it out here and made a screenshot, then looking at the screenshot in a paint program it was perfectly normal. (Even scanlines etc, whereas in realtime the darker scanlines would be crooked).
Do you have ‘local dimming’ in the monitor ON? my suggestion would be to try both on and off, maybe it helps.
3 Likes
I posted this in the wrong forum as I’ve been using mostly GV but the same happens on the Sony PVM shader. I think rafan is right about my monitor. It’s a Samsung QN90a which has a lot of local dimming and contrast features. I’ll check those out later today and report back.
I’m happy there are people with HDR knowledge here. Who knows what terrible calibration I have with paper white, luminosity…etc.
1 Like
I do that too and I must admit I don’t think I’ve seen any differences when pressing F1. I’ll take a look again tonight.
With regards to paper white, contrast etc it’s all a bit of an art as no display is the same. What usually happens (is supposed to happen) is that the user goes through a series of calibration pictures and the user adjusts those pictures until they match the instruction. We sadly don’t have that so it’s very much finger in the air stuff.
2 Likes
Would it be possible to make a home brew rom with the needed test images, sort of like Fudoh’s 240p Test Suite?
1 Like
that would be pretty tough, but there are some libretro test cores that could probably handle it more easily. Or, for that matter, just load them in the built-in imageviewer core
3 Likes
I’ll just share my experience with this, as something to start from.
Retroarch HDR Peak Luminance
Starting point is that you set the “Peak Luminance” under Retroarch’ HDR setting correctly. There are a few options here:
- Retroarch suggest to go to RTINGS.COM, look up your monitor max luminance value there.
- If you have a colorimeter (something like Xrite i1 DisplayPro or equal that supports measuring HDR range) then set the Windows 10 SDR/HDR brightness slider to the full right (max output) and have your monitor set brightness and contrast to max and measure the max light output using the colorimeter with DisplayCAL . Use this value for RA peak luminance value. This is what I did.
- Use the VESA DisplayHDR test.Get it from the Microsoft app store or Download it here: VESA DisplayHDR test. Run the tool, push Arrow right on your keyboard until the page showing “Max Peak Luminance” and “Max frame average Luminance”. Choose a value for peak luminance in between the two, I would suggest closer to the latter than the first. (see quick manual here , and for the technically inclined (not me) detailed technical quide here ).
So that’s Peak Luminance.
Paper White
The Paper White setting is the top of the old SDR range. So in normal daylighting conditions and when NOT using CRT shader it would be close to 200 or lower to 150 in a dimly lit room (night lighted room condition).
When using CRT shaders one would increase that - as a starting point - by doubling that (depending on how much CRT effects you have going on) and calibrate towards a point where the CRT shader outputs at a comfortable (non-eye straining) light output, especially when looking at fully white screens. Brightness wise it would then come perceptually close to somewhere between 150 and 200 cdm2 depending on your room lighting condition.
Oh and the more CRT mimicking the scanlines and the mask, the higher this value will need to go. The purpose of this thread 
Most important thing to remember IMO is that the Paper White settings ACTS like the old “Contrast” on CRT monitors.
Contrast
Then lastly there is the Retroarch “Contrast” setting under HDR options. Raise this value to bright boost dark colors. This setting IMO can largely be compared to how the old “Brightness” setting on CRT monitors worked (raising or lowering black level). Note that this interacts/overlaps with things like “Bright Boost Dark Pixels” in for example the GDV shader.
All in all the HDR addition to Retroarch is such a great quality of life improvement to the use and tweaking of CRT shaders, all thanks to @MajorPainTheCactus 
.
6 Likes
Okay so upped the dark greens and reds, added a slight brightness tweak due to making the beam size a pixel wide rather than 0. Also used a pure a srgb 2.4 display gamma (I use the proper sRGB gamma decompression algo) and later add contrast.
So I think I’m getting stuck as in its whack a mole: I can widen the green phosphors in his hat/tunic but then I start to lose dark between the scanlines in his eyes shield. I’m not sure what is going on to be honest.
I think the tapering is still off on the green tunic and I think that’s because the curves falloff is steeper although it could be due to the higher dynamic range of the CRT.
The other weird thing is that blue in his shield is blatantly bluer than the CRT but if I dull it down I lose the brightness of the blue in the back ground which is darker than the CRT. With the naked eye his shield now looks near identical to the shield in CRT photo - you can see this in the third image.
Maybe this is due to the rec.2020 having far better blues than rec.601? Maybe this due to incorrectly using the same white temperature in both cases.
What do we think? This looks kind of close but not at the same time.
OnePlus 8 Pro Camera: Pro Mode, ISO 100, WB 3510K, Aperture Speed 1/60, about 10cm from the screen, 48MPixel JPEG.
4 Likes
Street Fighter 2 Alpha 3 shots with slightly different camera settings as you can see on the pictures. (I need a better camera really)
https://imgur.com/gallery/vJUvLbs
(Hmm looking at Imgur it’s crunched the images possibly not the best place to post - what’s a good high detail photo sharing site)
1 Like