Dogway's grading shader (slang)

To add some info at the discussion here’s a summary of the main analogue related parameters.

These are the standards, but every TV set was different as we all know (eg. white point towards D93 despite the specification).

EBU gamut was designed as a finished color, ready to be displayed, NTSC relied on each receiver to do further adjustments, typically by manufacturers. NTSC FCC (1953) was rarely or never used (hard to implement), it had very saturated colors.

You have to tweak (and it’s totally fine) your LCD gamma settings depending on the viewing environment and display characteristics. For example if playing on an HDTV, the display is typically calibrated to a 2.4 gamma, so you can compensate that by raising LCD gamma to 2.4. If you are on your 2.2 monitor and your are playing in daylight, it’s totally fine to lower LCD gamma to 2.00 as sRGB defines a gamma of 2.2 to be viewed under dim conditions (~64 lux).

The next settings applies to games based on their developed country:

PAL 
	Gamut: EBU (#5) (or an EBU based CRT gamut)
	WP: ~D65 (6489K)
	TRC: 2.8 Gamma (POW or sRGB)*
	Saturation: -0.05 (until I finish ntsc-signal-bandwidth shader)

NTSC-U 
	Gamut: SMPTE-C (#3, #7) (or a NTSC based CRT gamut)
	WP: D65 (6504K)
	TRC: 2.22 SMPTE-C Gamma (soft-coded to 2.22 when using crt_gamma = 2.40)

NTSC-J  (Default)
	Gamut: NTSC-J (#4) (or a NTSC-J based CRT gamut)
	WP: D93 (9305K)
	TRC: 2.4 Gamma(?) (POW or sRGB)*

*POW has some clipping issues so a good approximation to pow(c, 2.4) is to use sRGB with a value of 2.55 in crt_gamma

And here two more shots with the PAL characteristics stated above, one with sRGB and another with SMPTE transfer function. Yes, to me sRGB is a bit too dark, I know it may suit you but as you said the image is going to get considerable darker with scanlines, vignetting and whatnot. That’s why I think it’s a wise move to start by defining your scanlines, and tune towards the TRC type and gamma as the final step to optimize dynamic range.

sRGB

SMPTE-C

4 Likes

Great info/summary! Might want to add the region-related info in the shader notes somewhere for easy reference.

Yep, that would be the best way to go if you’re particular about how the scanlines look. If you just want to maximize dynamic range, I think you can save scanlines for last. Min/max the scanline parameters so that the beam variance is maximized and then gradually reduce the beam variance until there’s no clipping of colors or scanlines and good shade separation at the high end.

2 Likes

@Dogway

Hey the newest version of grade.glsl is failing to run on my end.

I’m getting

Undeclared identifier: source
No matching overloaded function found: RGB_YUV

Edit: I sent a pull request fixing it, I think. There’s still an issue on my end where gamut 0 results in a black screen though.

All I did was add the M_PI and fix the source label as you had two imgColor labels.

Could you explain the hue/I/Y controls some, as I’m having issues trying to figure out what does what?

1 Like

Thanks a lot for the help. It goes to show what I’m testing more with.

I think I fixed all the little issues, test when you can please. I noticed a change in the encoding of the file to UTF-8, probably due to the “·” character. Just in case I replaced with a simple ANSI compliant dot (.)

Also fixed the black screen issue, adjusted PAL clamp ranges and updated “glass” with a flicker option.

The HUE/I/Q controls are like an analogue version of grade, it tries to mimic the only color adjustments a TV set could do with plane shifting and color burst. The chroma planes are not single colors but greyscale planes that define an opposing bias between A/B colors, for orange-blue (I) or purple-green range (Q), and in PAL-land is opposing blue-green (U) and opposing red-green (V). It’s there for the more purists who only want to adjust colors in an analogue fashion. About HUE I’m not sure if that’s analogue related, it’s happening in YIQ space, I borrowed it from the yiq-hue-adjustment shader.

2 Likes

I’ll test in a couple of hrs, I only woke up momentarily

1 Like

I just tried the latest update and it seems like something is up with the function transforms now- getting clipping and crushed blacks with sRGB. Anyone else?

Also, I think there should be an option to disable the CRT gamut thing just for flexibility and because it can make some things easier to test.

That’s what gamut 0 is.

Gamut 0 does this:

1 Like

Glsl or slang? Because I’m not getting that via slang.

Also I have still had no luck getting green or red to look right no matter what I do. sRGB is a slightly wider gamut than those used by CRTs, so colors are going to look oversaturated unless corrected (especially greens and reds). Compare these colors. Is this something that we can fix with the tint controls? I’m not very good at using the tint controls TBH; can someone help me out?

sRGB gamma, CRT gamma 2.55, LCD gamma 1.80, color temp 7900K

1 Like

It’s slang, should be the latest version too. I’ll try redownloading

EDIT: just re-tested; same results.

GeForce GTX 1050, Windows 7.

1 Like

Hmmm, I tested at 3_4 this morning and wasn’t getting that, hang on.

@Nesguy, can you try now? I just updated with some rework but that darkening haven’t happened to me. With gamut == 0 you skip a lot of code (gamut, TV levels, etc) so it should be the safest option debug-wise. Also slang is always the more up-to-date.

1 Like

Just tried it; I get a black screen when the shader is applied. Removed all other shaders to make sure there wasn’t a conflict with something else.

edit: also seems like the HUE/I/Q controls aren’t doing anything, now

1 Like

Here are some screenshots, my setup, then my setup with your gamma and temp values, and finally with all my grade settings reset except for yours.

There are some tint settings I use mostly on everything, maybe you can try. Aside of some blue to green , and even more green to blue, I like to lower White-green, and if you feel like it also a bit of White-red. Besides that, little else, I use gamut == 4 (NTSC-J) which softens the reds and blues, if it’s undersaturated for you you can increase saturation or the IQ multipliers (haven’t tested), you can also use Vibrance controls for more refinement.

I will have a look at your issues because it’s very strange.

2 Likes

You posted the same picture 3 times?

It’s working fine on my end just updated, slang.

EDIT: My bad images are different, misread the post lol.

1 Like

lol no. It’s subtle though. I think I might remove the NTSC FCC standard, it’s just wrong, not the matrix per-se but the standard, it doesn’t make sense such saturation. CRTs don’t have wide gamuts to reproduce that.

2 Likes

@Nesguy, let me explain part of the changes.

The analogue controls are only available if you set a CRT gamut emulation option. If you use 0, it skips all analogue related controls (HUE and the 4 YIQ ones).

The issue you have with such high saturation is because using such extreme gamma values. 2.55 is ok, but 1.80 for LCD gamma is a bit too low, I wouldn’t go lower than 2.00 at most. You can compensate the gain in saturation desaturating with grade’s saturation setting or if you enable a gamut with the multipliers.

About the black screen, I have to find out what’s happening.

On a general note, what’s driving me a bit nuts is the correlance between the conversion matrices of RGB<->YUV/YIQ/YCC. I know they should happen in gamma space but in no place it is clear if it should happen also in legal range or full range, there are even discussions and contradictions about it. The thing is it also affects the clipping of out of gamut values as I don’t know the clipping range makes reference to legal range either. All in all, I’m kinda reverse engineering that, that’s why I made so many changes, but I think this area is correct now with the latest commit.

2 Likes

@Dogway I’m still getting a black screen with gamut 0 in glsl, just updated to make sure. Slangs running fine though.

1 Like

Don’t use glsl for now, I haven’t updated it. I’ll do it tomorrow if slang is fine with you.

1 Like