That’s great to hear the SDR version is working for you. So I haven’t had a chance to compare but I’ll do it as soon as I get the chance. Hopefully there is something we can do to bring the two closer together in parity.
I don’t think I was making any conclusions. On the contrary, I would like to see more feedback, buzz and the community using these shaders grow. I know it’s early days still.
I wasn’t trying to be critical in any way. Just sort of summing up in a very simplistic way the type of feedback I’ve read and observed here so far. That’s why I was careful to qualify and quantify my statement using very general terms such as “some” and “others” which infers an unknown quantity or percentage.
I most definitely am not suggesting that HDR be ditched in favour of anything else or that it’s not already a successful endeavor.
I wasn’t referring to the shader when I said I never saw an image or asset designed for SDR look identical or even close to identical in HDR mode. The examples I was referring to actually excluded the shader because I was just wondering if that same phenomenon might have been also at play in the shader.
So it was more like a question, not a statement about the shader which is something that is new, being worked on, tested and therefore variable. So no conclusions there. Just a thought that came to my mind based on my previous observations of other things (besides the shader) and wondering if the shader is also at the mercy of the same phenomenon.
Also, I don’t think there is any issue of going back to anything.
I think one can use any shader and still want to see all of them improve and enjoy supporting novel and different approaches.
So please don’t get me wrong. I am definitely an avid supporter of your work and what you have created. I hope you don’t think that I’m amplifying any minor issues that a few users might be having here and there.
I was trying my best to communicate (not criticize) what I thought might have been obvious, which is that users’ mileage might vary depending on their particular setup (particularly in the brightness and calibration department).
No harm intended. You’re doing a great job and service to the community here.
Keep up the good work!
This gray ramp issue may be the same issue that I reported several months ago. Glad I’m not the only one. Solving this would likely improve overall brightness as well.
With regards to color accuracy I was thinking we need to consider one other thing that may sit in the way of having accurate 709 mapping in 2020 space. It’s not related to the shader, but to the fact that HDR monitors don’t have full coverage of the Rec.2020 space themselves.
If you look at RTINGS.COM and add “Rec.2020 coverage xy” as a column in their table tool, the best monitor has a coverage of 84%, most others are in the range 55%-80%.
This implies native monitor primaries in HDR mode differ from the assumed theoretical Rec.2020 primaries, which the shader gamut mapping is based upon, and will result in a (visible?) color shift. How large this shift is would depend on each individual HDR monitor, and how closely it tracks 2020 color gamut.
Maybe this could be a factor also with the greens you’re seeing?
I think I’ve posted it before also, but if you’re interested to know the native primaries of your HDR monitor, run “dxdiag.exe” in Windows and Click on “Save All Information…”, search the log for HDR and there you’ll find the reported primaries of the monitor, such that you can compare them to the Rec.2020 specs primaries, and see how much smaller the monitors gamut actually is.
Yes but Id expect the monitor to be able to display rec.709 correctly otherwise everything would look odd and just that in that say 16% that isn’t possible it’s just clipped i.e it reaches max green the display can do and just stays there.
Definitely try latest and see what you think as I’ve solved a few bugs: one with precision and one with a bad DCI-P3 gamma calculation.
So on mine I funnily enough see it the other way round HDR gives me the best ramp and SDR I have to really mess around with the gamma’s to get a fully balanced ramp. I guess this is just down to our different monitors? What exactly are you seeing wrong with your HDR ramp - black clipping, white clipping, both or something else?
Some images to compare colour as discussed. I have to say these images seem to give the mask accurate a closer accuracy to the PVM than it actually is but in person I’d absolutely say it’s the colour accurate version is more accurate.
Having said that the darks are way to dark so I may have to adjust my gamma levels a bit to march my PVM.
Sony 2730QM PVM:
Sony Megatron Colour Accurate Mode:
Sony Megatron Mask Accurate Mode:
All Photos: OnePlus 8 Pro Camera: Pro Mode, ISO 100, WB 6500K, Aperture Speed 1/60, Auto Focus, 48MPixel JPEG.
Thanks for posting these pictures, let me first just say they look astonishing! I wouldn’t be able to tell the shader ones from real CRT if they would’ve been posted on their own.
The interesting and great part of course now is that you have the CRT for close inspection and comparison. As you mentioned the gamma part is the more obvious difference when comparing them side by side.
Do you have the ability to run the 240p test on your CRT and actually have the CRT placed side-by-side with the LED? I know you’ll have your own methods, but if I were doing the calibration I would do two things:
- Run 240p test suite on both, go to the white screen, and make sure the luminance of the white screen on the CRT matches that of your shader output on LED. Note that is very valid to use the “Contrast” on the CRT to bring it in line with your shader output luminance on the white screen! You don’t have to do everything on the shader/LED side!
- Run 240p test suite Gray Ramp test on both and make sure the darkest value bar (the “8,8,8” bar) is just visible when looked at in a dim room, while covering the bright bars with your hand or a magazine. Note again adjusting the “Brightness” on the CRT is equally valid. The goal is to have them both matched, so adjusting on both is a valid strategy.
- Reiterate the previous two steps until both the white screen and the gray ramp look exactly the same on both the CRT and the LED with shader output. Of course this is only possible if you’re able to run the CRT and the LED/shader in a physical side-by-side comparison, so hopefully that’s something you’re able to do.
If after this process there’s still a difference then it could be an option to add the various Gamma Type functions on gamma_in and _out as parameters, as we talked about previously, to see if for example a change to power law from 709 or other combination of gamma function/type on gamma_in versus the gamma_out type function could “dot the i”
It would be super interesting to see your three phothograps again after the CRT and shader have been matched on gamma! In any case great stuff already, thanks for posting the comparison!
Thanks for the calibration tips! So sadly I haven’t got them side by side as I haven’t been bothered to move my PC and monitor into the living room and I’m certainly not going to try lumping the 50KG PVMs into my office. BUT I can see the two screens at the same time - just from a bit of a distance. I do have 240p t at suite on both and have done calibration comparisons in the past but I should do this again as it’s a long (development) time since I did it last and the gamma has all changed since fixing the precision bug and other things.
The main issue with luminance is that my 600-700 nit LCD monitor can’t reach the brightness of the CRT when the shader is on.
That’s actually a lot of the difference you see in the above pictures TBH as my camera doesn’t have low enough ISO to stop the CRT blooming and clipping the images and giving slightly false results. But then again phone cameras aren’t perfect anyway.
I’ll definitely calibrate the gamma again and post the pictures up.
I’m certainly not an expert on the subject but maybe you can temporarily lower the brightness of the CRT to match the LCD at least initially and do your calibration of your colours, gamma and contrast at that level, so you get the best case for the LCD, in terms of matching the CRT, then you can revert the CRT to the best case for that.
Normalizing the brightness of both displays to the lowest common denominator should also assist with your camera issues.
Again, I’m no expert, just a thought.
Yes good idea, I have a feeling my PVM doesn’t have a brightness control when taking scart though.
It would be very unusual for a studio monitor not be able to control brightness. Being connected via scart should have nothing to do with it?
According to the manual of your Sony PVM 2730QM on page 5 and on page 3, you can control Brightness (black level I think) with button “4” and “Picture” level (meaning old fashioned “Contrast” I think) with button 14.
See page 3 here: https://archive.org/details/sony_PVM-2730QM_Service_Manual/page/n1/mode/2up
And page 5 here: https://archive.org/details/sony_PVM-2730QM_Service_Manual/page/n3/mode/2up
It does say that some controls only work when “Set the MANUAL CONTROL switch on the rear panel to ON” (see page 4 and 2 at the bottom).
EDIT: and on page 2 there’s additionally under “Troubleshooting”:
Symptoms: No controllable keys although the POWER switch is turned. Corrections: Press the CONTROL key.
Page 4 note: Press CONTROL key after power is turned on to illuminate the control keys or indicators
Yes as I say it was a feeling, you could well be right but I do know for certain some controls dont do anything and I have two of them that work that way. Having said that maybe it’s the ‘hue’ controls. I’ll have a play around.
So just just played around with brightness and whilst I was wrong in that its disabled, I was right one way, in that lowering it doesn’t do anything (not that I could perceive in a lit room at any rate) i.e it’s at its darkest but who knows in combination with contrast and a dark room maybe I can get some leverage our of it.
Just curious, did you try both Brightness (button 4 in manual) and Picture (button 14 in manual)? Especially the Picture button should work on Luminance, did you try this button on the right side of your screen?
To make it clear what we call “Brightness” these days with LED monitor, it is the equivalent of “Contrast” or “Picture” control from the CRT days. So if you want to lower the max luminance/brightness on a CRT you actually need to lower “Picture” or “Contrast” and not “Brightness” (which on a CRT controls the black level and does little to max luminance).
I can only say that if you can’t turn the screen close to entirely black, something is definitely wrong with your PVM.
Edit: so yeah you need to lower “Picture” on your PVM (button 14 on the right) to lower the brightness. That should do the trick.
If you want to read up on the (confusing) terminology used in the CRT era, read this from Charles Pontyon, the CRT expert, here CRT “Brightness” and “Contrast” (Picture) controls
Yes I was just saying brightness doesn’t go lower. I don’t tend to do any calibration stuff during the day and so that’s why I havent taken further steps - the problem is at night is the only time I get to work on other projects and so finding time is difficult.
Hi @MajorPainTheCactus !
I’ve been doing some extended testing and have some good news! I’ve now been able to also get a balanced Gray Ramp in HDR mode!
Just for the sake of completeness I’ve tested all three SDR modes (709, sRGB, DCIP3) since they each use a different gamma curve and tested HDR mode. I’ve used the 2730-sdr preset for SDR and the 2730-hdr preset for HDR. So four tests in total.
After loading the preset I changed the “Brightness” +0.15 to “0.00” and TVL to 1000 in all four test, additionally I tweaked CRT gamma in the three SDR tests and for the HDR test tweaked Max Nits, Paper White Nits and CRT Gamma.
To get right to the issue, to get a balanced Gray Ramp in HDR mode I needed to lower CRT gamma from its default 2.4 to 1.9 and then lower max and paper white nits to around 300 each (even though my monitor is HDR 400) and then I get a balanced Gray ramp, while remaining a bright enough screen as well!
So what I’ve noticed is that your 2730-SDR and 2730-HDR preset differ in their preset CRT gamma, the 2730-sdr version sets a preset value of CRT gamma 2.00 but the 2730-HDR preset doesn’t set a preset CRT gamma, so it defaults to the parameter.h default of 2.40!:
2730-sdr preset
loads "#reference “shaders/crt-sony-megatron-sdr.slangp” which has a gamma_in preset value:
#reference "crt-sony-megatron.slangp"
hcrt_hdr = "0.000000"
hcrt_gamma_in = "2.000000"
2730-hdr preset
loads "#reference “shaders/crt-sony-megatron-hdr.slangp” which does not have a gamma_in preset value:
#reference "crt-sony-megatron.slangp"
hcrt_hdr = "1.000000"
I think if you add the " hcrt_gamma_in = “2.000000"” also to your 2730 HDR preset, it may save a lot of headaches for people.
Because, if I change CRT gamma to anything above 2.1/2.2 let alone its default 2.4 there’s just no way I can get the gray ramp balanced, the whites will always be blown out or the whites will be good when lowering paper white to something about 170, but then the darks and the whole screen will be way to dark.
Now onto SDR mode…
Previously I already mentioned that SDR mode was fine for me using the DCIP3 colour space with its power gamma, and now I’ve matched up the SRGB and 709 almost through changing the CRT Gamma as follows:
SDR mode:
SDR colour space: DCI-P3, Display Gamma: 2.40, CRT Gamma: 2.30 == perfect gray ramp
SDR colour space: sRGB, Display Gamma: 2.40, CRT Gamma: 1.90 == close to perfect gray ramp (dark values fall off slightly to steeply)
SDR colour space: r709, Display Gamma: 2.40, CRT Gamma: 1.70 == close to perfect gray ramp (dark values fall off slightly to steeply, and even a bit more than sRGB above)
Note how for sRGB and r709 I increasingly need to lower the CRT gamma.
Maybe I’m premature in my conclusion, but it seems, at least for my setup, that with the power law gamma function (which the sdr dci-p3 setting is using as gamma function) allows me to create the most balanced gray ramp in that the darks don’t fall off too steeply, but overal a really great even spacing between the bars from dark to bright. Maybe it would be the same for other users? In that case possibly it could be considered to add an option for the 709 and sRGB colour space, to be able to switch between their spec gamma curves and power law gamma curve.
Anyway thanks again for the shader and putting in all the effort, much appreciated!!
As a quick response to the HDR section: so what you have hit upon is the reason why all HDR applications really need a calibration process. Basically because no display can currently display the full rec.2020 spec i.e 10,000 nits and the wide colour gamut (as we’ve discussed before) then what looks good on your monitor may not look good on mine and vice versa.
So as you’ve correctly identified these calibration screens behind the scenes tweak the max nits, paper nits and gamma values of said applications and that is basically what we really need in RetroArch but I didn’t have the time or resources to create those screens when I added HDR support to it.
Basically you need to tweak these values for your screen as these values are for my screen i.e 700 max nits, paper nits and 2.4 gamma (in). These values do give a correct grey ramp on mine so that’s what I’ll keep.
Maybe I need to give these instructions on the shader params screen though.
This is great work @rafan! What display do you use?
Will you consider packaging a preset pack or at least posting all of your modified preset code as you go along or when you go through all the Sony Megatron Color Video Monitor presets that you use. This would be a great help to users like myself who don’t have as much knowledge and understanding of how colour systems and calibration work!
Brilliant work in improving this awesome shader!