No no sorry Cyber I should been a bit more specific about the photos I was talking about for reference. As I say I think all (most) of the front on ones should be in good focus to be able to see the sub pixels - in the original view i.e if you click on them in Discourse I mean.
1 Like
You’re making me nervous. My experience is totally the opposite from yours. Please keep mask accurate as it is the only color correct one for me! 
Maybe its because we are using very different setups: you’re using HDR (rec.2020) and I’m using the shader in SDR DCI-P3 (91% coverage of spec according to RTINGS)
Other things to consider:
- Is the system gamma (curve) on your CRT identical to the system gamma (curve) of your LCD+shader output?
- Does your CRT have sRGB color primaries or EBU color primaries or Sony color primaries?
- Are the phosphors (color primaries) on your CRT accurate to their spec or slightly worn out over the years?
- How accurate is the color gamut mapping: does your LED have good color gamut (volume) coverage of Rec.2020? Is there clipping of colors?
- Is the white point of your CRT exactly D65 or something different? Is your LCD+shader output having the same whitepoint?
I’m stating the obvious for you probably but note that any of the above single differences can result in subtle but noticable color shift, let alone when adding them up. It could be that when the above align perfectly between the CRT and the LED+shader output that mask accurate is the one that is colour accurate.
It’s possible to get scientific answers to the above I think, but it requires a measurement device. An XRite i1 Display color calibrator or similar can do the measurement job as with it you can get the scientific data on your monitor, like the color primaries, the gamma curve and the white point. The harder part is probably to connect your PC to your CRT such that you can do the same measurements on it.
Retroarch has native support for CRT through CRT Switchres that is based on running a Linux machine (it can do native 15Khz support via modeline editing) or a Windows PC with CRT Emudriver. Another option could be DP->VGA dongle with ToastyX’s Custom Resolution Utility. This allows for custom modelines on Windows like on Linux. Soldering a VGA to SCART cable in the right way may be another challenge. Probably a HUGE rabbithole so probably not something to get yourself into without a lot of time on your hands… 
Anyway before this gets lost: please keep the mask accurate option in there as it is, and not fudge around with as all I know is that I’ve been a very happy camper ever since you put it in there!
Apart from some minor nice to have features (interlace support like guest-advanced has it) it seems Sony Megatron is pretty much perfect as it is 
3 Likes
Yes don’t worry I’m not going to break things! I’m just wondering whether there is a solution that fixes both when I fully understand what is actually going on with my display.
So you said you just use the SDR version? As far as I remember the mask accurate/colour accurate doesn’t work for SDR. Hmm actually as I write this maybe it does for DCI-P3. But I think that colour space is broken in Retroarch as we don’t set a DCI-P3 swapchain. We’d need to add that support for it to really properly work like rec.2020 does. Hmm maybe this is part of problem?
2 Likes
Yes I’m using it in DCI-P3.
I also wondered about the swapchain setting. From what I’m observing it doesn’t matter if you have HDR=OFF in Windows, then the monitor is always in its native color space which is DCI-P3 for my monitor (very very saturated red for example).
2 Likes
Yeah I would agree, I had this same experience on my LG monitor using hdr (its hdr400), the overall color of the color accurate looked off, and mask accurate looked correct.
3 Likes
Yeah I’m not sure we’re in true DCI-P3 space . I think instead in its in some quasi rec.709/DCI-P3 space as the proper gamma space for DCI-P3 are values in a higher range 10bit space like 32bit HDR. Kind of a poor man’s HDR that works in Windows non HDR mode. The only thing is that directx swapchain colour spaces don’t seem to directly support this at least not the 2.6 gamma curve.
See here for supported spaces:
3 Likes
Yeah as I say I’m not going to remove anything if it breaks things BUT I’m trying to figure out what is going on here. Why does my display look very broken with mask accurate and then other displays look very broken with colour accurate. This isn’t making a lot of sense to me. There seems to be a fundamental difference in the way HDR content is being displayed or a bug in the swapchain code not telling the display how to display the swapchain correctly. This latter theory if right and being fixed where we might be able to remove the mask accurate/colour accurate option.
3 Likes
Yeah that would be great if possible
2 Likes
The question also seems whether there could be some confusing terminology with P3. My Samsung is advertised as having DCI-P3 coverage, but after reading up on wikipedia DCI-P3, my monitor much more resembles Display-P3, Apple’s adoption of DCI-P3 color space for computer monitors.
From the wikipedia article:
DCI-P3 specifications are designed for viewing in a fully darkened theater environment. The projection system uses a simple 2.6 gamma curve, the nominal white luminance is 48 cd/m2 with the white point defined as a correlated color temperature of ~6300 K.
Display P3 is a color space created by Apple Inc.[12][13] It uses the DCI-P3 primaries, but instead of the ~6300 K white point, Display P3 uses the CIE standard illuminant D65 as the white point, which is the most common standard for self-illuminated displays and devices (sRGB and Adobe RGB both use D65). Also, unlike the DCI-P3 projection gamma of 2.6, Display P3 uses the sRGB transfer curve, which is approximately equivalent to a display with a 2.2 gamma.
So DCI-P3 being the movie theater projection standard for a fully dark viewing environment it does explain the very high 2.6 gamma. It also uses the “odd” 6300k white point. Display-P3 on the other hand makes a lot more sense for watching content on computer monitors or TVs in dim lit (not fully dark!) rooms with its sRGB transfer function and D65 white point.
Out of the box my Samsung was set to its native SDR mode with wide color (P3) gamut, but with D65 white and a gamma curve that resembles something between an sRGB curve and a pure power gamma, averaging out between 2.3 and 2.4. Clearly closer to Display-P3 than DCI-P3, even though the marketing is saying DCI-P3.
It would not be surprising if most wide gamut monitors actually use Display-P3 spec and not DCI-P3 spec and there’s just a general misconcepted use of the terminology where everything P3 is just called “DCI-P3”?
Regardless, it could make sense to add Display-P3 to your shader instead of or as a complement to DCI-P3. The latter really only seems suited for use in a fully dark theater environment.
2 Likes
Not to derail the current conversation but has anyone had any luck solving the gray ramp thing on an SDR display? I had to lower CRT gamma to 1.7 to get all the gray bars visible, which results in a washed out picture elsewhere, and it’s still a bit dark. Any suggestions?
No shader
Megatron
shaders = "5"
feedback_pass = "0"
shader0 = "shaders_slang/ntsc/shaders/ntsc-adaptive/ntsc-pass1.slang"
filter_linear0 = "false"
wrap_mode0 = "clamp_to_border"
mipmap_input0 = "false"
alias0 = ""
float_framebuffer0 = "true"
srgb_framebuffer0 = "false"
scale_type_x0 = "source"
scale_x0 = "4.000000"
scale_type_y0 = "source"
scale_y0 = "1.000000"
shader1 = "shaders_slang/ntsc/shaders/ntsc-adaptive/ntsc-pass2.slang"
filter_linear1 = "true"
wrap_mode1 = "clamp_to_border"
mipmap_input1 = "false"
alias1 = ""
float_framebuffer1 = "false"
srgb_framebuffer1 = "false"
scale_type_x1 = "source"
scale_x1 = "0.750000"
scale_type_y1 = "source"
scale_y1 = "1.000000"
shader2 = "shaders_slang/hdr/shaders/crt-sony-megatron-source-pass.slang"
filter_linear2 = "false"
wrap_mode2 = "clamp_to_border"
mipmap_input2 = "false"
alias2 = "SourceSDR"
float_framebuffer2 = "false"
srgb_framebuffer2 = "false"
scale_type_x2 = "source"
scale_x2 = "1.000000"
scale_type_y2 = "source"
scale_y2 = "1.000000"
shader3 = "shaders_slang/hdr/shaders/crt-sony-megatron-hdr-pass.slang"
filter_linear3 = "false"
wrap_mode3 = "clamp_to_border"
mipmap_input3 = "false"
alias3 = "SourceHDR"
float_framebuffer3 = "false"
srgb_framebuffer3 = "false"
scale_type_x3 = "source"
scale_x3 = "1.000000"
scale_type_y3 = "source"
scale_y3 = "1.000000"
shader4 = "shaders_slang/hdr/shaders/crt-sony-megatron.slang"
filter_linear4 = "false"
wrap_mode4 = "clamp_to_border"
mipmap_input4 = "false"
alias4 = ""
float_framebuffer4 = "false"
srgb_framebuffer4 = "false"
hcrt_hdr = "0.000000"
hcrt_gamma_out = "2.204996"
hcrt_crt_resolution = "3.000000"
hcrt_brightness = "0.250000"
hcrt_gamma_in = "1.700001"
hcrt_red_scanline_min = "0.450000"
hcrt_red_scanline_max = "0.900000"
hcrt_red_scanline_attack = "0.850000"
hcrt_green_scanline_min = "0.450000"
hcrt_green_scanline_max = "0.900000"
hcrt_green_scanline_attack = "0.850000"
hcrt_blue_scanline_min = "0.450000"
hcrt_blue_scanline_max = "0.900000"
hcrt_blue_scanline_attack = "0.850000"
hcrt_blue_horizontal_convergence = "-1.000000"
hcrt_red_beam_sharpness = "1.000000"
hcrt_red_beam_attack = "0.000000"
hcrt_green_beam_sharpness = "1.000000"
hcrt_green_beam_attack = "0.000000"
hcrt_blue_beam_sharpness = "1.000000"
hcrt_blue_beam_attack = "0.000000"
1 Like
Hey there @Nesguy,
I looked into this recently. It has to do with the way gamma has been setup for the three Colour Spaces under SDR: Display Color Space (r709 | SRGB | DCI-P3).
@MajorPainTheCactus made the choice of having all three color spaces (respectively r709, sRGB and DCI-P3) use power law gamma function on linearizing (gamma_in) but use the respective color space’s gamma function when doing the reverse operation on gamma_out.
This seemingly causes a “mismatch” for the gamma curves used on gamma_in and _out for r709 and sRGB modes, darkening the early ramp quite a bit. DCI-P3 is ok, because it uses power law by specification and that is used both on gamma_in and _out in the shader.
So currently you have for the three SDR colour spaces “gamma_in vs. gamma_out” functions:
r709: pow vs. r709 transfer curve
sRGB: pow vs. sRGB transfer curve
DCI-P3:pow vs. pow transfer curve.
There’s no wrong or right here I think. It’s more a matter of choice. There’s enough literature out there that would describe CRT transfer function as either power law, r709 or sRGB curve. It depends on certain assumptions and from what I understand from the Microsoft and HP article on sRGB also depends on what settings were generally used for the analog “brightness” (black level) and “contrast” settings on CRTs.
My guess is that you’re using either r709 or sRGB for the SDR: Display Color Space setting in the shader?
So as a very quick test you could set the color space in the shader to DCI-P3, it will give washed out colors if your monitor is not wide gamut, but does it solve the gray ramp issue for you?
Or if you’re into some code editing -as a quick test - you could change the gamma transfer functions used for the r709 or sRGB modes on gamma_out to also use power law. The slightly more involved way would be to match the gamma_in to their respective color space transfer curves but since differences may be small, using power law on both is good enough for a test.
To do this if you go to “hdr/shaders/include/gamma_correct.h” you can change the gamma_corrections “LinearTo709” and “LinearTosRGB” to use “LinearToDCIP3”, which actually is the power law conversion:
so change this in gamma_correct.h:
if(HCRT_HDR < 1.0f)
{
if(HCRT_OUTPUT_COLOUR_SPACE == 0.0f)
{
gamma_corrected = LinearTo709(scanline_colour);
}
else if(HCRT_OUTPUT_COLOUR_SPACE == 1.0f)
{
gamma_corrected = LinearTosRGB(scanline_colour);
}
else
{
gamma_corrected = LinearToDCIP3(scanline_colour);
}
to this:
if(HCRT_HDR < 1.0f)
{
if(HCRT_OUTPUT_COLOUR_SPACE == 0.0f)
{
gamma_corrected = LinearToDCIP3(scanline_colour);
}
else if(HCRT_OUTPUT_COLOUR_SPACE == 1.0f)
{
gamma_corrected = LinearToDCIP3(scanline_colour);
}
else
{
gamma_corrected = LinearToDCIP3(scanline_colour);
}
Note this only changes the transfer curve to also use power law on gamma_out for r709 and sRGB modes, nothing else.
4 Likes
Thank you! Yes, this solves the gray ramp issue while resulting in washed out colors on my non-wide gamut display.
I’ll give this a shot later, thanks! Perhaps a power law toggle switch could be added if this proves to be a good solution @MajorPainTheCactus
4 Likes
So this isn’t actually true - it shouldn’t be converting from any of those spaces as this should all be rec. 601 stuff on input i.e what the consoles output of the time adhered to.
Rec. 709, sRGB and rec. 2020 are all on output and are all modern color spaces and gamma curves sRGB for instance being developed for website viewing on the desktop. However what I will say is that rec. 601 transfer function is the same as rec. 709 transfer function.
However there is a bug in that I’m not using my function rec601ToLinear on input and defaulting the CRT gamma to be 2.22. I’ll fix that right away.
You don’t need to mess around with the output transfer functions above but you will need to make sure whatever you choose for those, that your monitor matches them.
3 Likes
Fixed that the right input rec. 601 transfer function is being used and should hopefully fix both @Nesguy and @rafan issues. The pull request is V4.2 Sony Megatron Shader so should get in the build in the next day or two depending on when the pull request is merged. Thanks for pointing this out as it wasn’t obvious in HDR (which is what I always use) as you can compensate for this issue much more easily - its way more obvious in the SDR modes.
6 Likes
Does there seem to be some kind of compression(?) occurring at the low end, now?
#reference "shaders_slang/hdr/crt-sony-megatron-aeg-CTV-4800-VT-hdr.slangp"
hcrt_hdr = "0.000000"
hcrt_gamma_out = "2.200000"
hcrt_lcd_resolution = "0.000000"
hcrt_crt_screen_type = "0.000000"
hcrt_crt_resolution = "1.000000"
hcrt_gamma_in = "2.400000"
hcrt_red_scanline_min = "0.800000"
hcrt_red_scanline_max = "0.900000"
hcrt_green_scanline_min = "0.800000"
hcrt_green_scanline_max = "0.900000"
hcrt_blue_scanline_min = "0.800000"
hcrt_blue_scanline_max = "0.900000"
1 Like
Definitely make sure all your setting are neutral i.e usually set to 0 or 1 except for maybe the attacks. I’m not sure I can see what you’re talking about though - are you saying the darkest two bars are the same? They should be very slightly different as in black and super super dark grey - I think the dark grey will be near to 1,1,1 (white being 255,255,255) or something once gamma corrected with a ^2.4.
EDIT: Btw I would expect your gamma in and out values to be swapped around. Generally rec. 601 was 2.22 (in) and sRGB is 2.4 (out).
1 Like
Yep, the 3rd and 4th bars from right are the same, swapping the gamma values back to the default fixed it. Gamma can be a confusing thing due to differing nomenclatures.
Btw, I’m embarrassed to ask, but what exactly does scanline attack do?
3 Likes
You shouldn’t be it’s a pretty specific thing to this shader. So as a rough high level description it’s attack of the various curves I use for various things or to put it another way, how steep or shallow the curves are.
So for example vertical scanline attack says how fast the intensity of the scanline falls off in the vertical direction. The horizontal attack is how fast it falls off in the horizontal axis ie how fast it transitions from a black pixel to a white pixel.
The slightly more technical description is that I use 1D berzier curves for everything which have two anchor points at 0 and 1 and two control points at 0.333 and 0.666 and effectively the attack moves the two control points up and down.
5 Likes
IDK, I think there’s still something odd going on with gamma in SDR mode, but I can’t quite put my finger on it. It’s either bright and washed out or well saturated but dark. Gray ramp looks good, but the colors don’t. I know gamma is affected by just about everything but I’m having a hard time getting a handle on it. Maybe I just need to play with brightness/saturation/contrast. I’m curious to see what others can come up with. @rafan
EDIT: I think I just need to adjust contrast and saturation, actually.
2 Likes
I’d add also check your TV settings. Certainly let me know any tests I can look at that you think are off.
1 Like