Things are prone to change since our interpretation of linear has changed now. The above is a test version, I’m interested on differences with everything else turned off mostly. CRT gamut, color space, saturation, temperature, etc are fine because they don’t mess with the tonal range.
I suggest to keep signal gamma and CRT gamma the same as if we calibrated our emulated CRT gamma to the developer’s CRT display.
I tried the new version and only see a very tiny difference when running test suite grey scale patterns. But I don’t think I would notice the difference in a double blinded test. I do like the new version better conceptually.
I’m now trying to get the best possible calibration with DisplayCal, but am a bit confused with all the settings. Would be great of you could advise on the below. If I want the best possible result with guest-dr-venom with grade included what calibration settings would I use and what 3D LUT settings:
For grade should I use “-1: rec 709” or “0: sRGB”?
Wit regards to DisplayCal settings:
On tab Calibration:
On tab 3D LUT:
You have to match grade color space with DisplayCAL TRC setting. It depends in your viewing environment. If you play daytime use sRGB, otherwise on a dim to dark environment use Rec.709 in grade and Custom in DisplayCAL (2.4 Relative when not OLED).
For the LUT settings, use Rec.709 and the same TRC settings. You need to enable “Advanced options” from the top menu and uncheck “Apply calibration (vcgt)”. You can test different Rendering intents, some people prefer Preserve Saturation despite it can change HUE’s a bit.
Sadly the link is expired 
Sorry, it was only a test version to get some feedback, didn’t expect it would take more than a week. Here it is again: https://pastebin.com/8n8nkkpw
I shuffled things a bit. I moved the gamut and temperature block up to the analogue region, so this is processed over rec.601 primaries as it should, and later converted to rec.709 or your SPC space. This is now happening in SMPT-C linear gamma, not sRGB transfer function.
I also calculated the temperature of each phosphor gamut matrix, before I was using standard temperatures but now each has a matching temperature to normalize them to D65, so we can later add a temperature of our like. I might change them to a Bradford matrix later on if it helps with HUE deviations.
Witchcraft I say, witchcraft.
Nice update
I noticed g_crtgamut (Phosphor) at “0” or “-1” produces a black screen.
Strange it’s not happening to me but might possible be a bug on my side, are you in vulkan or gl_core?
Happens to me when I replace the first “stock” pass in the latest guest-dr-venom with grade.slang. Only setting the crt phosphor to “0” or “-1” produces the black screen. The other phosphor settings work.
Latest guest-dr-venom here: https://forums.libretro.com/t/new-crt-shader-from-guest/25444/278
guest.r has explictly added a first “stock” pass to the shader to provide room to replace it with any external pass (which I assume is the category grade.slang also fits to).
EDIT: ah, it happens only with GLcore set, not with Vulkan.
I’m running into a small issue that maybe you have an explanation for.
If I run 240p test suite “white screen” without a shader than the screen looks white. If I run only grade.slang with default settings and “phosphor” to “0” then there’s a noticable green tint to the white. See the two pictures below.
Is this supposed to happen with phospor set to “0” and everything else at default?
I tried some things and moving White-Green Tint to “0.88” makes the white neutral without the green tint (and comparable to “no shader white”). But then other colors are affected too.
no shader
grade.slang with default settings and “phosphor” set to “0”
It boils down to the temperature function, it never converges to pure white as far I could check.
I did more changes to the temperature neutralization of the phosphor gamuts, this time by eye, they all should resemble white now but since they are correlated it might not be pure white.
For phosphor 0.0 I could bypass the temperature function altogether I think that would make most sense (since a CRT should always have a phosphor), what do you think?
This version looks a bit better but still has a noticable green tint to it. I agree that for phospor 0.0 it makes sense to bypass the temperature function altogether. Would be nice if you could make an update for us to compare/test. I assume the only thing not working anymore at phosphor setting 0.0 is the White Point setting, or does that still work and is only the “baked whitepoint” for phosphor 0 removed? Or are other things affected too?
Here’s with the bypass, it will skip the white point setting only. You can try the previous version and try to find a white point that resembles white with phosphor 0 but as I said I think there’s no value that converges to pure white so probably this version is a better option.
If the issues with the glcore are fixed I can promote this to the repo.
By the way, on another note I wanted to add that it is the scanlines non-linear dynamics which messes with output gamma, if the beam dynamics follows a linear response it just messes with brightness but not the gamma curve. I do need to revise if the measured CRT gammas take into account scanlines or not, so far the best paper for CRT gamma is this one. An Accurate Characterization of CRT Monitor
Works as intended now. Issues with glcore are fixed also 
Thanks for the link to the paper, I guess we would need more of those kind of analyses of the behaviour and chraracteristics of CRTs to better understand where we could make an advancement in emulation.
EDIT: I was intrigued by the different values for y for R, G and B for the P22 phosphors (in paragraph 2.1). Do you have a take on that? It seems it may be worth experimenting in a shader with separating the gamma for the three primaries in that way, or am I reading that all wrong?
I understood the R,G,B separate gamma for the phosphor as simply the color characteristics of the phosphor, which are already emulated (3D LUTs would be an improvement though).
I think the next step for improvement would be on determining if the “standard” 2.50 gamma of CRTs are measured with scanlines, in which case absolute gamma output will heavily depend on scanline and TVL count and their non-linear response. It would be nice for the gamma_out to be aware of this non-linearity.
I gave the above paper a deeper read and finally got to some conclusions.
The mentioned CRT gamma of 2.5 is actually that of the electron gun, which after passing through phosphor’s intrinsic gamma (beam dynamics) yields a gamma of 2.2 or 2.25.
What this means is that I changed the default Game Embedded Gamma to 2.2, and the CRT Electron Gun Gamma to 2.50. (A_review_of_RGB_color_spaces)
I calculated what beam dynamic settings can yield a gamma of 0.88 (for 2.2) and 0.9 (for 2.25) for crt-royale and crt-guest-dr-venom shaders in this post.
Summary:
crt-royale: beam-min-sigma of 0.05 for 0.88 (2.2 absolute gamma output) and 0.10 for 0.9 (2.25 absolute gamma output).
crt-guest-dr-venom2: Scanline shape dark pixels of 1.50 for 0.88 (2.2 absolute gamma output) and 1.70 for 0.9 (2.25 absolute gamma output) (assumes scanline beam shape low of 14.0)
As a side note, brightness also gets affected by scanlines for about 10 or 15% so you have to compensate for that on your monitor settings if you want to reach a desired luminance level.
I updated the shader on my repo so this is prior to updating to master if everything goes well. https://github.com/Dogway/emulation-random/blob/master/RetroArch/Shaders/grade.slang
Small fix (download from repo above), “Sega Luma Fix” was bypassed when phosphor = 0.0. And cosmetics.
By the way I found the reference paper for the NTSC-J phosphor gamut (page 18), so it doesn’t look like I pulled it out of my… imagination lol
I’m trying to make sure I have the most up to date Grade,
The version I have is I think from December I think and looks like this:
#pragma parameter g_gamma_in "Signal Gamma" 2.50 1.80 3.0 0.05
#pragma parameter g_gamma_out "CRT Gamma" 2.50 1.80 3.0 0.05
#pragma parameter g_signal_type "Signal Type (0:RGB 1:Composite)" 1.0 0.0 1.0 1.0
#pragma parameter g_crtgamut "Phosphor (1:NTSC-U 2:NTSC-J 3:PAL)" 2.0 -4.0 3.0 1.0
and the current version in the retroarch repo looks like this:
#pragma parameter g_gamma_in "Game Embedded Gamma" 2.222 1.80 3.0 0.05
#pragma parameter g_gamma_out "CRT Electron Gun Gamma" 2.50 1.80 3.0 0.05
#pragma parameter g_signal_type "Signal Type (0:RGB 1:Composite)" 1.0 0.0 1.0 1.0
#pragma parameter g_crtgamut "Phosphor (1:NTSC-U 2:NTSC-J 3:PAL)" 2.0 -4.0 3.0 1.0Just saying but those are identical, just the “flavor” text is different.
Is there any actually changes in code?
If you send the December copy to me, I can go over them I guess lol.