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.
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!)
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…
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.
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.
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.
@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.
@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.
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).
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…
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.
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.
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!
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!
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!
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.
