Dogway's grading shader (slang)

[Nesguy]

Given the earth-shattering revelations in my previous post, I’m still very confused about the SMPTE-C mode and why there’s such a large discrepancy between it and sRGB.

I take it that the point of the SMPTE-C mode is to show the colors as they would actually appear on a CRT with SMPTE-C phosphors.

Since sRGB is a slightly wider gamut, you’d expect the colors (by default, no shaders) would be slightly more saturated compared to what you’d see on a CRT with SMPTE-C phosphors. I guess the SMPTE-C mode is supposed to correct the oversaturation…?

So, it makes sense that the SMPTE-C mode appears less saturated compared to the sRGB mode, but it’s a really large difference even after adjusting my TV settings accordingly and… am I really doing this right?

@Dogway if you get a chance can you post some reference shots just showing the color differences, sans CRT effects?

[Dogway]

@Nesguy, I updated grade with a bunch of color gamuts, I think they are more accurate than the ones included in venom’s but who knows, at least they show a visible change in colors. The one not used at all is NTSC-FCC with illuminant C, that’s the 1953 one, I included it as gamut #2 just for the curious. gamut #1 (P22) is very similar to #3 (SMPTE). Also included #4 for Japanese phosphors, and #5 for EBU (PAL). If you find me some Conrac phosphor primaries I can convert it to a color matrix.

To go along I also added plane control over YIQ or YUV for a more analogue feel. But That forced me to remove a few settings as I topped the max limit of 32 pragma settings. Tell me if you miss them, or if you prefer the YIQ control for a variety aside the more common grade color functions.

By the way, I think that after I settle on this color gamut thing the shader would be ready to upload to official repo, if everyone agrees on settings and last changes.

@Nesguy, download again now, I made a mess when updating (I fetched it instead)

[hunterk]

@Dogway

I topped the max limit of 32 pragma settings.

If you just move the parameters to the global struct, you can have as many as you want (up to like 128 or something, I think…?)

[Dogway]

To answer your question (I was absent studying and making this shader) I took several shots with their gamut and likely function transform. Since DKC2 is an European game I think EBU makes more sense(?). So I guess you can start with a “correct” template and then tweak from there to whim.

EDIT: I think I forgot to set it to D65 as it’s the spec for those.

sRGB gamut/function transform

SMPTE-C gamut/function transform

EBU gamut/sRGB function transform

[Nesguy]

So for the content to look correct we need to use the right color gamut and the right function transform?

What CRT gamut should we use for sRGB? P22? (my understanding is that sRGB has basically the same gamut as a typical CRT display) I’m guessing the gamut used for POW gamma will be the same as that used for sRGB gamma?

@Dogway

If you find me some Conrac phosphor primaries I can convert it to a color matrix.

It’s my understanding that SMPTE-C = Conrac phosphors.

I’m not sure I’m matching the gamuts with the right function transforms because I’m still winding up with crushed blacks, elevated black levels and clipping with some combinations. Is that to be expected?

[Dogway]

The sRGB gamut was derived from CRT gamuts, it was a consensus between EBU and SMPTE-C (and some Japanese standard I think). If you play mostly Japanese games I think you can use the Japanese gamut standard (until I find those NES TV phosphor primaries!), if you play american games SMPTE gamut. I don’t know if someone can confirm but game localization didn’t involve gamut mapping in the 90’s right?

As for the function transforms, I think keeping with sRGB is a safe bet. The power function has some issues and it just doesn’t look good. The SMPTE-C transform… yeah… food for thought. I think and I might test (I mentioned it some time before in this thread), it’s compensating for the IRE 7.5. So probably I shouldn’t convert back from… uhm I removed the PC_to_TV() call leaving the inverse transform to PC levels and it crushes values in a manner that makes sense.

EDIT:For the time being give me a day or two to clear this issue and check what is happening, it has to do with this latter transform I added today. If you just want to test the gamuts I PM you without that function call.

Check these pics and compare with the ones above (macroblock is gone):

SMPTE function transform (with clipped TV levels)

sRGB function transform (with clipped TV levels)

Power function transform -for comparison- (old default, no clipping values)

[Nesguy]

Yes, both SMPTE and sRGB function transforms are looking much better in the most recent examples! Still a few things here and there that maybe shouldn’t be visible in the SMPTE shot but it’s a big improvement.

@Dogway

The SMPTE-C transform… yeah… food for thought. I think and I might test (I mentioned it some time before in this thread), it’s compensating for the IRE 7.5.

I agree that the 7.5 IRE thing probably has something to do with this.

[tpjunior]

Loving this so much. Having a great time. Syh sent me a folder that helped me out quite a bit. It helped me to figure out what locations mean what. No complaints, great thing you made here. Just a question:

When I use “crt-royale_braun-ntsc-256px-320px-svideo-grade_1080p_slotmsk.slangp” I get this massive mask. Is it intended to look like that? My monitor is 4K, so I know if there is a problem, it’s probably that. But is there some number I can tweak to make it look like originally intended. Maybe reduce triad size or something? I did try that, but is there some sort of general rule when using 1080 shaders on a 4K monitor, like “double or half every parameter” or something? But hey if this is how it’s supposed to look, I don’t hate it. I just figured the mask looks a bit intrusive.

[Dogway]

Hey thanks for liking it, it’s become a bit of a monster but I think it pays off. EDIT: to anyone reading; want to hear how’s the performance of this on weaker machines to check if I should optimize further.

That preset as the name suggests is for 1080p because it uses a B&W pattern mask. If you are on a 4K you can do much better with the standard royale (RGB pattern and settings) “crt-royale-ntsc-256px-320px-svideo-grade”.

It has settings for pattern tiling to accomodate a 4K, I forgot the exact settings but I think there’s a guide somewhere. On one of the files it reads:

//  MaxTriadSize    BlurSize    MinTriadCountsByResolution
//  3.0             9.0         480/640/960/1920 triads at 1080p/1440p/2160p/4320p, 4:3 aspect
//  6.0             17.0        240/320/480/960 triads at 1080p/1440p/2160p/4320p, 4:3 aspect
//  9.0             25.0        160/213/320/640 triads at 1080p/1440p/2160p/4320p, 4:3 aspect
//  12.0            31.0        120/160/240/480 triads at 1080p/1440p/2160p/4320p, 4:3 aspect
//  18.0            43.0        80/107/160/320 triads at 1080p/1440p/2160p/4320p, 4:3 aspect

[Dogway]

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

[Nesguy]

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

@Dogway

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.

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.

[Syh]

@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?

[Dogway]

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.

[Syh]

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

[Nesguy]

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.

[Syh]

That’s what gamut 0 is.

[Nesguy]

Gamut 0 does this:

[Syh]

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

[Nesguy]

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

[Nesguy]

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

EDIT: just re-tested; same results.

GeForce GTX 1050, Windows 7.