By the way @Dennis1 you have to remove the space between the " @" and the user’s name if you want to tag someone.
Having the time of my life with this shader!!
CyberLab Megatron 4K HDR Game Turbo Duo_Dreamcast S-Video Smooth.slangp
Thanks again @MajorPainTheCactus and all others who contributed!
I am too! The Atomiswave HDR looks BEAUTIFUL on Sega Saturn games! I am going black playing games again just to see the shader in action!
Yeah thats not my point here - I know we’re using emulators/cores hence why I went back to using the old power gamma I’m more interested in what the original hardware was doing and how to get my SDR version working in that way (Im going to put this into output gamma curves Ive been using but then we hit problems with modern monitors doing their own gammas). However Im not sure anybody really knows what actual gamma curves those old consoles used - presumably the standards but could be power for all we (I) know at this point.
Sorry for the stupid late reply - Im finding it difficult to keep up with things.
So first of all thanks for doing this! I was wanting to get a spectrometer to do this. So my first question is what are you testing here - are all the settings in the shader set to neutral? Also what are you testing when using autohdr in windows 11 - are you using megatron in sdr mode and retroarch in sdr mode? Have you also tried retroarch hdr (with no shaders)?
This will be really useful to know whats hoing on. One thing I will say is that we’re trying to get to rec. 601 rec. 709 in a rec. 2020 colour space. We’re not wanting to get to full green rec. 2020 as that will make the games look wrong. This means that it is correct in this case that green is rec. 601/709 green which is slightly yellow in rec. 2020 space (and was originally too). Is this where the descrepancy lies?
Also what have you on screen at the time of the when youre capturing - the test 240p suite? If so what test?
Thanks for any info!
Have you got the saturation setting etc set to neutral (0.0)? This might be where your colour difference is coming from but there could well be a bug.
Yes definitely make sure all settings are in neutral (0.0) and vivid should be switched off as @Azurfel points out - its more like ‘dynamic’ mode on your tv and youre trying to use ‘film maker’ mode.
Yeah you need to modify your vertical attacks to lessen that sharp fall off which is causing the wierd slot mask artefacts BUT it is essentially because we’re using discrete pixels here and there are only 5 per half scanline at 240p using 4K resolution.
No problem, I’m also pretty busy and completely understand it.
To measure the colors with Windows 11 Auto HDR enabled, I set your reshade port of the shader to the neutral preset and colors / whitepoint to r709 and of course to SDR, as W11 now does the tonemapping or mapping from rec.2020 back to rec.709 if that’s the more correct term for this scenario.
When I measure your HDR tonemapping algorythm, I disable W11 AutoHDR and measure the colors with HDR enabled in the Megatron reshade menu and otherwise same settings.
I am aware, that we are trying to achieve rec. 601/709 colors in the “rec. 2020 container” which the TV uses when HDR is enabled. I just mentioned, when I measured your HDR tonemapping and W11 tonemapping, that there are differences.
And the green is even undersaturated when compared to the rec.709 triangle, which is what I used as a reference in all my measurements (the dark triangle in the screenshots is rec.709 and the white triangle the actual measurement).
Windows 11 AutoHDR is trying to keep saturated colors beyond rec. 709, which is not correct for the case we want to use it, just like you said.
The Megatron HDR tonemapping is more close to the rec.709 Gamut, but the green primary color has a slight “lime” colored tint to it, the red primary is still slightly oversaturated and the white point is heavily shifted towards magenta which gives the overall image a pinkish tint as you can see here:
To measure the colors, I simply created test patterns within Windows paint. For Red RGB 255,0,0 - for Green RGB 0,255,0 and for Blue RGB 0,0,255
These test patterns are then loaded within Retroarch image viewer with your shader applied (SDR setting when W11 AutoHDR is used and HDR setting when Megatron HDR tonemapping is used and W11 AutoHDR deactivated).
An old i1 Pro 1 spectrometer would also do the job for the beginning, if you want to buy one, as these meters are very stable over time. I have seen those on eBay for around 100 to 200 euros.
And here is the measurement, when I use just the plain HDR from Retroarch without any shader applied:
This measurement is taken with color temperature at my TV set to warm 2, which is close to 6500K. The mapping of the colors from Retroarch in HDR seems very similar to the mapping of Windows 11 AutoHDR.
Thanks for the hint, I will give it a try.
Thank you for the conversion to reshade. I will try it out!
Core/emu output should be identical to original hardware output before it hits any analog circuitry in most/all cases.
Don’t mind me/that comment at all @MajorPainTheCactus. It seems like you misunderstood my statement. I put “when I first started out” and “initially” in italics for emphasis but I’ve now edited them and made them bold and italicized.
Sorry for the confusion but my colors are now perfect (at least for me). Feel free to look at my video and photos although they look a little different in person.
In my opinion, there are so many tools at our disposal to adjust the colours within the shader that that shouldn’t really be so much of an issue at this point.
This is what I was trying to refer to when I spoke about “Raw” and “unprocessed” output @Azurfel but I’m not as versed as you in the technical terms of this field so that’s probably why you misunderstood what I was trying to say.
So this gets weirder. I put full Rec 709 gamuts through lilium’s HDR analysis shader using RetroArch’s image viewer, and there does appear to be a some issue causing scattered color errors that exceed the gamut targeted by video_hdr_expand_gamut/hcrt_expand_gamut:
Primaries specifically do seem to be effected, which is most likely the reason @Dennis1 is getting gamut readings exceeding 709.
I have some theories i want to test. Firstly, i found a version of the k709_to_2020 matrix that goes to 15 decimal places, rather than 7 places like the one provided by Microsoft. I think i’ll compile RetroArch with that in place of Expanded709_to_2020. Swapping between them should give some indication as to whether this issue is the result of rounding errors or something like that.
Edit: the 15 decimal version of 709to2020 makes almost no difference (there are .01% fewer colors outside 709 using that first gamut image i linked when using 15 decimal.)
Adjusting RetroArch’s HDR Paper White or Contrast settings appears to cause the error colors to change position erratically on the analysis gamut chart, so it’s possible that one/both or something they touch is where the source of the issue lies? I will continue poking around.
Last night I found some time to experiment - instead of going to bed 
Ok so I went back doing some side by side experiments with my PAL Sony 2730QM PVM and MiSTer (not original console) and my PC plugged into my Samsung S95B QD-OLED and having put everything to neutral and using PAL I get a pretty accurate colour match eyeballing it whereas before Ive never achieved this. With yours @Azurfel and @Cyber help its great to get to this point at least locally. Now what Im going to do is go back through me presets and reorganize and update them. Im going to update my 2730QM preset and make it the default preset and then make the default setting a saturated/vivid one. I need to continue reading the other comments here first - especially the ones about lilium HDR tests.
Ah Ill have a play around with this lilium reshade tests. Itll be interesting to see. If theres a problem itll most likely be in the inverse tonemapping.
I would be slightly weary here though in that we’re not wanting HDR per se ONLY its brightness levels. We essentially want to undo all the colour expansion and keep the rec.601/709 colour space so a slightly yellow green in terms of rec. 2020 green. Im not sure how any of that effects these lilium hdr tests as I havent used them but Ill be intrigued! Thanks for the link!
We can certainly put RA into SDR mode and plug reshade into it to compare apples to apples.
Yes the Megatron shader is a HDR shader natively and so it does all the inverse tonemapping itself combined with the other settings. I made the RA built in HDR shaders skip when a native HDR shader is detected via the output format i.e the last stage uses rgba16 or rgb10a2 then its presumed its a native hdr shader.
agreed it is a bit of a mouthful - MPTC or MajorPain (my wife would expand that to ‘in the arse’) or just Pain or Cactus.
So you definitely want everything in neutral if you want to play around with colour stuff. As @Azurfel says definitely turn off vivid mode and put everything else to neutral. Ive found the P22-90s phosphor transform to be closest to my PVM though so possibly that and your choice of PAL/NTSC-U or NTSC-J which changes which white point is used: D65 or D93 respectively.
The presets are trying to mimick photos of displays which you should be able to see above if search for the model number in this thread.
This is fantastic!!! Ill definitely try it out - hmm if I had Windows 11 (is it time I upgraded). As I previously said I managed to get a similar thing right out of the box in RA with the megatron on my samsung s95B so possibly I need to see if there is a bug in the autohdr for reshade? Not sure.
The softening issue is definitely the main thing I noticed though now and Ill try your patch to see if we get to tube levels - maybe an 8K tv can remedy this problem without resorting to software blurs?
Ah ok so maybe its the wite point setting that is throwing things off here. If you set the shader into PAL or NTSC-U mode it will use D65 if instead you set it to NTSC-J it will use D93.
There could slso be some bug in the inverse tonemapping so not sure. Maybe I need to invest in a spectrometer!
@MPTC 
I already tried all Presets under “Color System” in your shader. Neither r709, PAL or NTSC-U have an accurate white point near the black body curve. All are shifted strong towards magenta.
I really hope you get this sorted with a spectrometer, as the Megatron shader is really worth it. With some fine tuning it can be very, very close to an actual CRT. And the built in options are absolutely awesome, because you included those important features like different resolutions, different TV lines, different masks and all the other settings perfectly make sense. The shader is even future proof with the ability to set it to 8K, which may result in even more realistic masks.
I did not play around with any shader so much in the past like with yours, as the result can be really good on my OLED. It just needs some fine tuning and hopefully your reshade HDR plugin will work in the future with Open GL and Vulkan, as Windows 11 AutoHDR doesn’t work with all Emulators outside of Retroarch via reshade and has the problem with oversaturation colors beyond rec.709, as it is targeted to improve the visuals of Non-HDR games with more satúrated colors and HDR brightness, which is not our goal.
If you don’t want to spent much for a spectrometer, just look for an old, used i1 Pro 1. I had one too and it was very close to my new i1 Pro 2 in terms of accuracy. They are very stable over time, as spectrometers don’t rely on filters like colorimeters, which tend to degrade over time and can get less accurate over the years.
