I use https://imgbb.com/
BTW I think you can solve the perceived color issues with a Look up table (LUT)
2 Likes
On my LG C9, I have a max Luminance of 720. I chose 300 for paper white because it looks great given the loss of brightness due to scanlines. I have an Xrite i1 DisplayPro with CALMAN for LG (BTW portrait displays is an awful company – do not buy!)
2 Likes
I think you may not be giving yourself enough credit here. That is, I think there are 2 main differences at play that aren’t really feasible (or possibly even desirable) to fix:
1.) the CRT’s green phosphors really bulge out horizontally compared with the other phosphors, which I would assume is an effect of the camera, since they’re obviously physically the same size
2.) the blues at full strength flare out to cyan, which makes a sort of optical illusion that I spent >9k hrs in GIMP correcting here:
Without those flare-outs in the blues, they look a lot more similar IMO.
You could potentially simulate the flare-outs in your shader by having some of the green subpixels activate alongside the blue ones when the blue channel gets above 0.8 or whatever (essentially overriding the mask, which would have the side effect of boosting your brightness somewhat) but that’s kinda getting in the weeds and moving away from one of the major goals of the shader–i.e., the simplicity of letting the HDR do the heavy lifting instead of trying to fake a bunch of stuff. I guess it would naturally give your bright blues a greener tint, too…
5 Likes
On my Samsung QN90a I had some dynamic local dimming I needed to turn off as well as change HDMI Black Level from “normal” to “low.” That setting absolutely mangled the gamma curve on my monitor. Shaders are looking good now.
5 Likes
Although I think Fudoh’s test suite might be a place to add this I think just adding it directly into RA as a calibration wizard on the HDR page would be the best place.
‘All’ we need is to build it in the UI and find some calibration images!
EDIT: actually Fudoh’s test suite probably isn’t the place to put these as its limited by the console output rec.601 ideally you want these images as full HDR ones.
3 Likes
Firstly thanks for the detailed response. With regards to the paper white luminance although you are absolutely right it’s the top of the old SDR range, a hack I do with this shader and only this shader (as it’s so dark) is to put the paper white luminance to the peak luminance. This means a lot more of the original SDR range is shifted up into the brighter range of HDR.
Normally you just want highlights to pop and so you would have a paper white that is much lower than the peak.
3 Likes
Yup just to also confirm pressing F1 has no visual impact (with overlay opacity 0) on my monitor (Eve Spectrum)
1 Like
@hunterk thank you ever so much for spending your time doing this it’s greatly appreciated and is something I really need to do also as it’s a great way to debug.
I have access to Photoshop and I should run this through some blue correction filters to see if that helps.
Having said that I think the cyan blue artefact is actually caused by my camera clipping the blue brightness even though I’m using ISO 100. I’m going to confirm this by eye (if that is indeed possible).
As for the width differences I noticed that too. My hope is that as you get a brighter display this starts to naturally happen 
Do you still think the dark width between scanlines in the eyes is an optical illusion due to the phosphor width? I’m not sure but then this is also my best guess also of what is going on.
So I’m going to move away from Link now and start looking at the way the primary gradients behave in 240p Test Suite. Hopefully this will give me more low hanging fruit.
2 Likes
@hunterk a small unimportant request but do you have ability to remove ‘V1.0’ from the title of this thread? Do I even have the ability - I just tried but couldn’t seem to do it.
Done!
Re: cyan flare-outs, yes, it’s definitely a trick of the camera, and I think the bulging greens are, as well. The question becomes: are you trying to reproduce what you see with your eyes or what you see with the camera? I think the former is a better target, and based on your on-its-own shot, I think you’re already there. Photography of CRTs has a well known blue push, and I think these things may be related to that, so if you wanted to make it look like a camera shot, this would probably be the way to go.
And yeah, I think the greens have a hair more separation in the eyes, but the blues look right to me. And I don’t know that the green difference is worth adjusting for (whack-a-mole).
5 Likes
Thanks for changing the title - that’s been niggling me for a while! 
Yes I think you’re right in that we’re chasing camera artefacts in a lot of cases - I’m definitely at or near that point.
What I would say is that at the scale we’re dealing with translating sizes, shape and brightness levels from one screen to another is near impossible with just the naked eye. Even if the two screens are next to each other I think it would be quite difficult. The camera kind of normalises and magnifies both screens for side by side comparisons. I do think that what you see with the naked eye is the target though.
I probably need a more professional camera as a starting point in this…
4 Likes
Hey, great work on the comparison. I see you’re contemplating the color differences and their source.
I think a quick look into CRT color spaces could be worthwhile, as imo your Sony CRT phosphor color primaries will be very different from your LED, accounting for a possibly siginificant colour and brightness difference.
In 1931 the International Commission on Illumination (CIE) mapped out human vision and created what is known as the CIE 1931 chromaticity diagram. It maps out all the color values that human vision can see and maps color spaces to x and y coordinates.
Rec. 2020 primaries:
Red Green Blue Whitepoint
x 0.708 0.170 0.131 0.31271
y 0.292 0.797 0.046 0.32902
CRT phosphor primaries (SMPTE-C)
Red Green Blue Whitepoint
x 0.630 0.310 0.155 0.31271
y 0.340 0.595 0.070 0.32902
As you can see the CRT color primaries are very different from Rec. 2020. Blue on Rec.2020 is much more saturated and thus one of the reasons it will appear darker. Since the CRT color primaries are so different, it can easily be imagined that any mixture of the CRT primaries will look differently from the same relative value mixture but with Rec.2020 values.
I think the above is a large component of the color differences between your Sony PVM and the shader output on your LED.
Enter the rabbithole…
The proper way would be to try to account for this difference in colourspaces.
This is where Dogway (grade shader) and guest.r have poured many hours into already, researching into ways to map CRT phosphor color spaces (like P-22 phosphors, EBU, NTSC, SMPTE-C etc…) to modern displays.
If Ithe color mismatch between your CRT and your LED is of enough concern you could possibly consider creating a single shader pre-pass that maps the CRT colorspace into HDR Rec.2020 to your liking.
The math is above my head, but most of it seems explained on the brucelindbloom.com site.
Grade.slang here: https://github.com/Dogway/emulation-random/blob/master/RetroArch/Shaders/grade.slang
Btw I googled for the PVM you mentioned you own (Sony PVM 2730QM ) and noticed in the manual it has three choosable whitepoint settings amongst which are D65 and D93. You could consider making a photograph with both of these settings on the PVM as they’ll materially alter the perceived output.
While googling I also came across a document that mentioned the color primaries of Sony P22 phoshors, in Table 1 of the third page: http://test.imaging.org/site/PDFS/Papers/1998/RP-0-69/2202.pdf. Maybe they would be close to the ones in your PVM.
3 Likes
Hi @rafan great response, thanks. So yes I was kind of guessing this might be the cause of some of my issues as I mentioned last night:
Maybe this is due to the rec.2020 having far better blues than rec.601?
Rec.601 is the general standard for NTSC’s SMPTE-C and PAL’s SECAM.
I think I should experiment with this a bit more and see if converting from rec.709 -> rec.601 -> rec.2020 resolves some issues instead of rec.709 -> rec.2020.
As you point out I’m sure it will as converting to rec.601 should clamp the colours and should at least pull out what are problems inherent in the display (brightness) and what is not.
I’ll give those links a read too - this invaluable stuff and really helpful! Thanks!
3 Likes
Which of rec.601 will you be converting too? Is your PVM PAL or NTSC?
Never really looked into 601, just noticed that 625 (PAL) line and 525 (NTSC) differ greatly.
The material difference is with the rec.601 NTSC primaries. That’s where a visible difference could be.
The difference between Rec. 709 and rec. 601 PAL (625 line) is negligible? Only a small twist on the green phosphor, I doubt if that’s very noticable…
4 Likes
It’s a very good question! I live in the UK and both my 2730QM’s are European models that take in a SCART socket but I run NTSC versions of a lot of consoles (I use MiSTer) as NTSC is better for them (Amiga and ST though are another story).
The manual says: it automatically selects the correct colour system so I’m guessing its using NTSC.
Colour System PAL, SECAM, NTSC, NTSC 4.43 (automatically selected)
I am wondering how much of a difference this is going to make even with the different NTSC values. Anyway lets play around with this and the grade shader you mentioned and see what I find out. I’ll report back my findings/new understanding!
3 Likes
That’s interesting, I think the colour system refers to the signals the monitor is able to decode, not the phosphors. So it’s able to decode NTSC signal, but the display itself (the phosphors coated on the inside) are most probably using PAL spec phosphors (same as EBU or something very close) since it’s a UK PAL model.
Mapping to the NTSC phoshors in the shader thus most likely will increase the color difference instead of lowering it. Anyway thanks for sharing!
1 Like
Although I think you might be right I think there maybe the argument I shouldn’t transform into rec.2020 colour space and leave it as rec.709/rec.601 PAL. I’ll try this and see what it gets us.
1 Like
From my failed attempt yesterday of sharing some high-res photos of this shader in Street Fighter 2 Alpha 3 (sadly I need a higher MPixel camera):
OnePlus 8 Pro Camera: Pro Mode, ISO 250, WB Auto, Aperture Speed 1/60, 48MPixel JPEG.
2 Likes
Well, I’m using DCI-P3 with HSM because Rec709 or SRGB are obviously oversaturated (looks nice, though :D). If I tell it to use Rec2020 it looks very wrong; yellow-green and desaturated. Might just have something to do with how Windows 11 uses HDR.
1 Like
Question: I’m thinking of stripping out all the phosphor masks except the RGBX one does anybody think thats a bad idea? Possibly keep RCYB on a #define?
I think the ethos of this shader is that it does one specific thing and thats simulate Sony BVMs/PVMs as best it can. There are plenty of other extremely good shaders that people can use to bend into shape for other CRTs/looks.
I’m also thinking of hiding as many settings as possible and just having a developer #define in it to turn on the technical settings. I kind of think just settings that the CRT actually had would be good.
One problem is I’d still like to data drive this - does anybody know how to have data driven values in .slangp that don’t appear in the shader parameters menu?
3 Likes