madVR - high quality video renderer (GPU assisted)

[e-t172]

Simple MadVR options..

"Should I enable X?"
"Can you see a difference enabling X?"

Repeat ad nauseam.

Think we've covered this about half a dozen times already.

That's not a good answer though. Checking if an option makes a visible difference can take a lot of time, because ideally you want to check a variety of different scenes, maybe even different formats of various bitrates. This gets very time-consuming, especially if you want to do that for several options or for several possible settings of a given option. It would be way more useful to do something more universally applicable, like conducting surveys to see if a given option makes a difference for most people, and if it does, how big the difference is. This could provide reasonable "guidelines" for people to follow.

Honestly I think the "what don't you try it" answer is a bit rude IMHO. It provides no information, and presumably if the user had the time and motivation to do the comparison themselves they would already have done so. If you don't know the answer, then don't post.

[Manni]

There is actually a bit of a trick when extending the bitdepth of a full range signal, you fill the new bits with the leading bits of the pixel, ie. like this for 8 to 10-bit:
/snip


Thank Nev, glad that I was right to err on the side of caution (when you don't know, don't assume is my motto). I've learnt my lesson :)

[huhn]

there are no general answer so we simply don't say anything anymore or we say there are defaults keep them?


and manni if you really want to get an headache think what this does to the dithering and how do you turn this back to a lower bit deep.

[ryrynz]

That's not a good answer though.

My point is... that it's already been answered many times.


Honestly I think the "why don't you try it" answer is a bit rude IMHO. It provides no information, and presumably if the user had the time and motivation to do the comparison themselves they would already have done so. If you don't know the answer, then don't post.

It's really not, it's the most useful information one could provide, and in this case it's very much the answer. Not having "time or motivation" are nothing but excuses.

Asmodian, perhaps you could add a bit more info on this in your guide?

[Asmodian]

Thank Nev, glad that I was right to err on the side of caution (when you don't know, don't assume is my motto). I've learnt my lesson :)

I don't know, stating your assumption can also be very helpful. I would never have guessed Nev's trick but it is probably what really happens. I would never have known if Nev didn't need to correct me. ;)

[huhn]

or they do 16 bit dither to output.
again we don't know and we can't change it.

[nevcairiel]

I would never have guessed Nev's trick but it is probably what really happens.

Its definitely in use in some things, but I can't exactly dump the HDMI data into a file to look at it, so... (now that would be a handy thing to have!)

[huhn]

there are more than enough lossless HDMI capture cards. they just have there price...

[Asmodian]

Hmm.. I actually have one... Maybe I should do some testing.

[BatKnight]

(...) Fwiw, my 'go to' movie for checking this discussion is Allied 2016. Scene 2:15 through 3:00 shows a dessert slow pan with a cloudy sky. That sky shows banding using 12bit settings in NCP. Using the 8bit settings (that it's going to revert to after a reboot anyway), there is no banding. (...)
I was puzzled by this and had to try it myself. And brazen1 is right, to a certain extent.
I've come to a conclusion, but I don't know how to explain why it happens. I tested wit the movie Allied, too and these are my findings:

Whether I chose "Use default color settings" or "Use NVIDIA color settings with RGB 12 bpc" didn't matter for the results I got. Either settings ended up with the same result, but to be consistent I used these settings (https://imgur.com/bx6QlS8) during the following tests:


1st test: enable "passthrough HDR content to the display" and enable "send HDR metadata to the display". This resulted in an automatic switch to HDR mode when I played the video and the madVR OSD shows (NV HDR): https://imgur.com/OZnoM6A
I can see banding on the blue sky when on D3D11 fullscreen windowed (10 bit) and the banding disappears with I right click the video and it shows D3D11 fullscreen windowed (8 bit)


2nd test: enable "passthrough HDR content to the display" and disable "send HDR metadata to the display". This doesn't automatically change to HDR mode and I have to manually enable "HDR and advanced color" on the Windows 10 Display Settings and the madVR OSD shows (OS HDR): https://imgur.com/i1hLNmC
I can't see any banding on the blue sky when on D3D11 fullscreen windowed (10 bit) or (8 bit).


I believe that when playing a 2160p 10bit HDR 23.976fps video and having madVR set up to output 10 bit, that all is going the best way possible.
What I don't understand is why when sending the HDR metadata, that results on NV HDR, I get banding and when not sending the HDR metadata, and manually enabling the OS HDR, I get perfect image and no banding... Why is OS HDR behaving differently than NV HDR for the same settings?

[seiyafan]

Is 3GB card enough for upscaling to 1440p? I am thinking of getting a 1060 instead of 1050TI but the 6GB version is too expensive right now. Not sure if 1050TI is enough for upscaling to 1440 though.

[ryrynz]

You'll be fine with 3GB, yeah 1060 all the way.. great card.

[bran]

As I've said in previous posts, there is a lot more noticeable banding when sending "12-bit" to current-gen TVs compared to 10bit. Regardless of madVR or standalone UHD-players. So padded zeros or not - the result is more banding.

For example check out threads regarding Panasonics UB700/900 players - people were getting banding until Pana released new firmware enabling 10bit.

I myself got a lot less banding outputting 10bit from AMD compared to nvidias 12bit (Samsung JS9505).

[ryrynz]

So.. maybe if Nvidia had a 10bit mode we'd be peachy?

[nevcairiel]

Or those crappy TVs should stop accepting 12-bit if they can't properly deal with it, then.
The fault clearly lies with the device that advertises support for a mode that it can't process properly.

[ashlar42]

Or those crappy TVs should stop accepting 12-bit if they can't properly deal with it, then.
The fault clearly lies with the device that advertises support for a mode that it can't process properly.This. So much this.

I long for a world where companies open a special section of their website, dedicated to enthusiasts, with all information relative to what's necessary to defeat the so-called "enhancements" that they introduce to satisfy undiscerning eyes. :rolleyes:

[Manni]

Or those crappy TVs should stop accepting 12-bit if they can't properly deal with it, then.
The fault clearly lies with the device that advertises support for a mode that it can't process properly.

Sure, but that doesn’t mean that projectors like my JVC which do support 12bits from input to panel shouldn’t benefit from it.

Zero banding in the Allied clip here, and same results with NV HDR and OS HDR.

What is sure is that people should test whether their display supports 12bits or not before enabling it. 8bits is a safer option unless 12bits support is confirmed.

[el Filou]

The fault clearly lies with the device that advertises support for a mode that it can't process properly.While you're right on TVs, I still don't get why NVIDIA won't give the option of 10-bit HDMI output. :(

[mclingo]

and native 23,976

[Razoola]

The solution here is Nvidia offering 10bit and 12bit support in divers for TV's that support both bit depths.

[Warner306]

I believe that when playing a 2160p 10bit HDR 23.976fps video and having madVR set up to output 10 bit, that all is going the best way possible.
What I don't understand is why when sending the HDR metadata, that results on NV HDR, I get banding and when not sending the HDR metadata, and manually enabling the OS HDR, I get perfect image and no banding... Why is OS HDR behaving differently than NV HDR for the same settings?

I think the problem here is the metadata. When the OS HDR toggle is enabled, it is my understanding Windows sends the color gamut and transfer function to the display, but not the metadata. The gamut and transfer function is enough for the display to enter its HDR mode. Tone and gamut mapping are done at the PC level. In fact, in the next update, Windows is releasing a calibration tool to change how HDR looks on your display. This is why HDR is always on.

When the Nvidia private API is used, the metadata is passed to the display untouched. The display uses its own processing to complete the tone and gamut mapping, not Windows. This would imply your display has issues processing a 10-bit HDR input. It's tone and gamut mapping is not of the highest-quality. This would explain why banding does not show for Manni on his display.

I could be wrong, but maybe a display is not the best at handling HDR processing? If true, I should delete my posts from yesterday.

[Warner306]

As I've said in previous posts, there is a lot more noticeable banding when sending "12-bit" to current-gen TVs compared to 10bit. Regardless of madVR or standalone UHD-players. So padded zeros or not - the result is more banding.

For example check out threads regarding Panasonics UB700/900 players - people were getting banding until Pana released new firmware enabling 10bit.

I myself got a lot less banding outputting 10bit from AMD compared to nvidias 12bit (Samsung JS9505).

But he said most 12-bit input is fine. It is only HDR that is the problem. And 12-bit with the OS HDR toggle is also fine. It has something to do with the HDR tone mapping.

[brazen1]

I have a couple more things to add since some keen interest is popular at the moment: I have no intentions of introducing any sort of Ad nauseam.

Early drivers offered 8,10, and 12bit. The 10bit option was removed in recent drivers for RGB afaik. So now it's just 8bit or 12bit to select.

When using RGB 4:4:4 12bit @23Hz (matching old faithful Allied 2160p HDR test refresh rate) understanding this is a one shot deal since it's going to revert to 8bit after a reboot with newer drivers:

Manni has pointed out his display accepts 12bit and dithers to 10bit correctly with no banding and retains after a reboot. If I'm not mistaken, Manni is also using a custom 3Dlut and not passing HDR through.

It should also be noted, no amount of madVR processing to reduce banding artifacts has any affect at all. Nor does the dithering algorithm used.

When using YCbCr 4:2:2 10/12bit @23Hz there is NO banding.
When using YCbCr 4:4:4 10/12bit @23Hz there IS banding.
When using RGB 4:4:4 12bit @23Hz there IS banding.
When using RGB 4:4:4 8bit @23Hz there is NO banding.

So, is it better to lose 10bit using RGB 4:4:4 8bit @23Hz
or
use YCbCr 4:2:2 10/12bit @23Hz and gain back 10bit once the 12bit dithers down or when using 10bit? I don't mind recalibrating since YCbCr is limited only and no full.

At some point, I may work my way backwards in driver versions to find RGB that still offered 8,10, and 12bit choices so I can select 10 and see if banding is present or if I must still select 8bit to cure it. I'm not looking forward to doing that anytime soon though.

Lastly, Allied is a 2160p HDR title. Testing an SDR 1080p title, no amount of anything eliminates or reduces banding. A good example is 47 Meters Down 2017 at scene 42:00

[Manni]

I have a couple more things to add since some keen interest is popular at the moment: I have no intentions of introducing any sort of Ad nauseam.

Early drivers offered 8,10, and 12bit. The 10bit option was removed in recent drivers afaik. So now it's just 8bit or 12bit to select.

When using RGB 4:4:4 12bit @23Hz (matching old faithful Allied 2160p HDR test refresh rate) understanding this is a one shot deal since it's going to revert to 8bit after a reboot with newer drivers:

Manni has pointed out his display accepts 12bit and dithers to 10bit correctly with no banding and retains after a reboot. If I'm not mistaken, Manni is also using a custom 3Dlut and not passing HDR through.

It should also be noted, no amount of madVR processing to reduce banding artifacts has any affect at all. Nor does the dithering algorithm used.

When using YCbCr 4:2:2 12bit @23Hz there is NO banding.
When using YCbCr 4:4:4 12bit @23Hz there IS banding.
When using RGB 4:4:4 12bit @23Hz there IS banding.
When using RGB 4:4:4 8bit @23Hz there is NO banding.

So, is it better to lose 10bit using RGB 4:4:4 8bit @23Hz
or
use YCbCr 4:2:2 12bit @23Hz and gain back 10bit once the 12bit dithers down? I don't mind recalibrating since YCbCr is limited only and no RGB.

Nope, this is not what is happening here.

I use MadVR in HDR passthrough mode, so MadVR sends 10bits, the GPU sends 12 (padded or "interpolated") and the display does no additional dithering because it's a 12bits native projector (12bits path from inputs to panels). So 12bits is actually the best option for me, as my cables are all able to handle the full HDMI 2.0 bandwidth and my display handles 12bits natively.

I do not use a 3DLUT for HDR, I pass it through to the display and I use custom ST2084 gamma curves to display it properly (the native HDR mode of my model is very poor, so I use the Vertex to disable it and I handle the HDR conversion with my own curves). The Metadata goes to the Vertex (and is displayed on its OSD for monitoring/testing when necessary) but it's not sent on in order to prevent the JVC from switching to its crappy HDR mode automatically. The PJ is calibrated to HDR BT2020 when I display 4K23p HDR content. The native HDR mode on more recent JVCs is better than on my model, but still not as good as a few well-designed custom curves (until MadVR's HDR to SDR conversion works better with projectors).

In my case, the best mode for HDR (or SDR) content at 23p is 4K23p RGB 4:4:4 12bits (MadVR dithering to 10bits). For 60p content, it's 4K60p RGB 4:4:4 8bits (MadVR dithering 8bits). For others, it might be different.

I wouldn't use 4:2:2 unless I had to (poor cables, non-optimal display). I'd rather have MadVR chroma upscaling goodness all the way, but that means cables able to handle 445Mhz in 4K23p@12bits and 600Mhz in 4K60p@8bits. :)

[Warner306]

When using YCbCr 4:2:2 10/12bit @23Hz there is NO banding.
When using YCbCr 4:4:4 10/12bit @23Hz there IS banding.
When using RGB 4:4:4 12bit @23Hz there IS banding.
When using RGB 4:4:4 8bit @23Hz there is NO banding.

So, is it better to lose 10bit using RGB 4:4:4 8bit @23Hz
or
use YCbCr 4:2:2 10/12bit @23Hz and gain back 10bit once the 12bit dithers down or when using 10bit? I don't mind recalibrating since YCbCr is limited only and no full.

Lastly, Allied is a 2160p HDR title. Testing an SDR 1080p title, no amount of anything eliminates or reduces banding. A good example is 47 Meters Down 2017 at scene 42:00

Bit depths were covered yesterday.

Remember, 10-bit RGB > 8-bit RGB > 10-bit YCbCr 4:2:2 > 10-bit YCbCr 4:2:0. That is a quote from madshi.

Given the problem your display has with 12-bit HDR, 8-bit and 10-bit are not equal, as 8-bit is actually better. So your choice is easy. Going from RGB in madVR to YCbCr 4:2:2 would destroy the chroma upscaling done by madVR.

Given that 4:2:2 corrects the HDR issue, maybe your display has trouble with the higher bandwidth of a 12-bit 4:4:4 HDR signal as RGB and YCbCr seem not to matter. It sounds like a poorly-implemented HDR mode by the display. Perhaps, an epic failure by the display if banding is created. For some reason, for one user, Windows OS HDR does a better job. The output from Windows would still be 12-bits HDR, but it doesn't have banding. That sounds like poor tone mapping or gamut mapping.

Does the 1080p title only band at 10-bits? It is not uncommon for 1080p Blu-rays to have some banding in the source.

[brazen1]

Got it. I made the wrong assumption about you and a 3Dlut. I'm not familiar with Vertex? I assume it's some sort of expensive additional device add to your HDMI cables to overcome some sort of problem? Anyway, I don't use a Vertex and I don't think I have any need one, and I don't think most people use one. I'm just sort of the common, regular ol' user that uses madVR, an AVR, and a display. I too would like madVR goodness all the way. I'm pretty sure my display is optimal and my cables are of little importance since all of them are no longer than 6' but maybe I'm mistaken. I'm not smart enough to know if your setup that works for you translates into mine should as well even though my setup is more primitive or perhaps in no need of more external configuration like yours. From the expert knowledge I see here, a general rule of thumb is always use RGB full. That limited adds extra processing. Except now I am met with a decision I have no expertise and rely on others here, including you. Which is preferred? RGB full at 8bit only or YCbCr limited at 10bit? I know what you use. I am asking about myself. It comes down to accept banding or live without 10bit or switch to YCbCr limited. I have no idea which of those 3 choices is the wisest?

Warner, let me digest all that. I need to run a few tests and look up some specs. Thank you.

[Manni]

Got it. I made the wrong assumption about you and a 3Dlut. I'm not familiar with Vertex? I assume it's some sort of expensive additional device add to your HDMI cables to overcome some sort of problem? Anyway, I don't use a Vertex and I don't think I have any need one, and I don't think most people use one. I'm just sort of the common, regular ol' user that uses madVR, an AVR, and a display. I too would like madVR goodness all the way. I'm pretty sure my display is optimal and my cables are of little importance since all of them are no longer than 6' but maybe I'm mistaken. I'm not smart enough to know if your setup that works for you translates into mine should as well even though my setup is more primitive or perhaps in no need of more external configuration like yours. From the expert knowledge I see here, a general rule of thumb is always use RGB full. That limited adds extra processing. Except now I am met with a decision I have no expertise and rely on others here, including you. Which is preferred? RGB full at 8bit only or YCbCr limited at 10bit? I know what you use. I am asking about myself. It comes down to accept banding or live without 10bit or switch to YCbCr limited. I have no idea which of those 3 choices is the wisest?

RGB Full 4:4:4 8bits with MadVR dithering to 8bits in your case. No question.

You don't need a Vertex, and most people don't need one either. It's an advanced diagnostic/testing/HDMI problem solving tool. I was simply explaining my chain as you stated quite a few wrong assumptions.

[el Filou]

and native 23,976But that can still be achieved with custom resolutions, while there is just no way to output 10 bpc over HDMI. I just don't get the reasoning behind allowing 12 bpc and not 10 bpc.

[huhn]

it should still be possible to force nvidia to output 10 bit with a custom edid.

and seriously 12 bit processing is not rocket science at all. even an old cheap Phillips TV was able to do 16 bit driver 12 bit GPU and showed no banding at all...

[bran]

and seriously 12 bit processing is not rocket science at all. even an old cheap Phillips TV was able to do 16 bit driver 12 bit GPU and showed no banding at all...

For myself, and what I've gathered from various threads - the banding happens in UHD HDR titles with 12bit enabled.

[Manni]

For myself, and what I've gathered from various threads - the banding happens in UHD HDR titles with 12bit enabled.

Probably because the displays are not native 12bits or even 10bits displays.

[Warner306]

For myself, and what I've gathered from various threads - the banding happens in UHD HDR titles with 12bit enabled.

How come the one user has no problems with Windows OS HDR at 12-bits? It must be the tone mapping done by the display.

[Warner306]

Probably because the displays are not native 12bits or even 10bits displays.

But they don't struggle with 12-bit input if the source is not HDR.

This what I wrote in my set up manual. Someone correct me if I'm wrong.

HDR metadata conversion involves:
Tone Mapping: Compressing highlights to fit the peak luminance of the display;
Gamut Mapping: Mapping the DCI-P3 or Rec. 2020 primaries to the display's visible colors;
Gamma Transfer: Decoding the SMPTE 2084 HDR (PQ) transfer function to the display EOTF.

One of those processes is failing at 12-bits. The display is supposed to know its own peak luminance and color gamut, so it shouldn't fail at this.

[j82k]

Yeah the whole 10/12 bit marketing thing seems like a big scam to me. Looking at test pattern, my 5 year old monitor can produce better gradients than my 2016 LG Oled.

[Manni]

Yeah the whole 10/12 bit marketing thing seems like a big scam to me. Looking at test pattern, my 5 year old monitor can produce better gradients than my 2016 LG Oled.

That's because people don't make the difference between a display able to accept 10/12bits, and a display able to actually reproduce 10/12bits.

One of the many things marketing people love to exploit.

Many displays on the market accept 12bits and have 8bits panels. So what happens in that case is that you ask the source to send 10bits (or more), the display accepts it, then dithers down to its native resolution (most often 8bits or less).

In that case, having MadVR dither to 8bits will most likely produce much better results.

Is this horse dead enough, or does it still needsome beating? :)

[Manni]

But they don't struggle with 12-bit input if the source is not HDR.


Most manufacturers are still learning how to reproduce HDR10, so this is not surprising.

As I said, on my display the HDR mode is not usable. It has to be disabled to get proper results.

Again, the key is to assess the actual capability of the panels, not just the input, and send what's appropriate after making sure that it is processed well once it reaches the display.

There are lots of ways to achieve this, but they involve test patterns and calibration, which most people can't be bothered with. It's these people that marketing departments targets :).

[brazen1]

madVR has a native display bitdepth adjustment. We can select 1-9 and the next option is 10 or better.

What if madVR had exclusive adjustments for 10,11,12, and so on? This way no matter what the GPU sent (12 in this case), it would adhere to the display bitdepth limit we select, in this case, 10.

'auto' still selects what the GPU is sending (12) and some of us 10bit native display owners are encountering epic failures because of poorly implemented display modes that don't handle 12bit.

I'd like to enjoy the reasons I purchased HDR equipment. To play my native 10bit sources at 10bit giving me 1024 gradient levels of color. To suggest I digress and just accept 8bit 256 gradients and then blame it on this, that and the other thing isn't very encouraging.

I don't count on drivers producing 10bit RGB. Evidently it's missing for a reason. I'm not going to upgrade to a 12bit native display. (this probably seals my fate) I'd have done that in the first place but considering I had zero interest in what I anticipated would be very limited 12bit dolby vision titles, I adhered to common 10bit HDR10 titles. Now this, that, and the other are affecting me.

Maybe madshi will consider separate 10bit and 12bit settings if it's even possible. Knowing madshi, he probably already did and it wouldn't provide any benefits or remedies and I'm wishful thinking about things I know nothing about again.

[Warner306]

If I'm right, and Windows is sending the gamut and transfer function to the display to trigger its HDR mode, then the tone mapping must be at fault. I read it on Redfox forums from a user who created a program that emulates what Windows does in HDR mode. This would turn on and off with HDR content with specific media players. I don't know if you should trust the tone mapping by this programmer, but he claims it does the same thing as Windows HDR. Windows gets it right. The display gets it wrong. That's what the original poster said.

It would be useful to have a user with an AMD card and the same display. Then you could determine if its the extra 2-bits that is causing the problem.

I'm sure many users would like to know the answer to this. They don't want to calibrate their PC and display to introduce banding with HDR content. My old plasma handles 12-bit -> 8-bit SDR just fine. I can't notice the dithering, so a set up error wouldn't harm anything.

[Warner306]

Most manufacturers are still learning how to reproduce HDR10, so this is not surprising.

As I said, on my display the HDR mode is not usable. It has to be disabled to get proper results.

Again, the key is to assess the actual capability of the panels, not just the input, and send what's appropriate after making sure that it is processed well once it reaches the display.

There are lots of ways to achieve this, but they involve test patterns and calibration, which most people can't be bothered with. It's these people that marketing departments targets :).

Your Vertex doesn't need to trigger the projector's HDR mode to get the gamma right?

[e-t172]

Yeah the whole 10/12 bit marketing thing seems like a big scam to me. Looking at test pattern, my 5 year old monitor can produce better gradients than my 2016 LG Oled.

That's completely unsurprising if your "5 year old monitor" has lower contrast than your "2016 LG Oled", which seems extremely likely. The higher the contrast, the more visible banding is.

[Manni]

Your Vertex doesn't need to trigger the projector's HDR mode to get the gamma right?

No, the projector's HDR10 mode is buggy, so you don't want the crappy gamma that the manufacturer forces when it detects HDR metadata.

So the Vertex doesn't send the HDR metadata, hence the display believes it receives SDR, but the full HDR content is sent unchanged. I've designed a better mode that allows the Vertex to select the best possible gamma curve according to the content, using RS-232 control. So instead of the buggy manufacturer's HDR mode, the Vertex selects a user mode and a custom gamma curve according to content. This mode has a BT2020 calibration and a ST2084 gamma curve optimised for the content with the appropriate tonemapping, taking into account the actual peak white of the projector (which the manufacturer has no idea about, as we're talking about a projector here).

This is completely off topic here (and unrelated), so I won't elaborate on this. You'll find more info in the Vertex links at the end of the "useful links" section in the first post of this thread: http://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2246658-jvc-calibration-software-v6-2015-models-x9000-x7000-x5000-rs400-rs500-rs600.html, especially this post for a background explanation of the issue on this specific projector model: http://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2222586-official-jvc-rs600-rs500-x950r-x750r-x9000-x7000-owners-thread-545.html#post55097696

[brazen1]

I'm pretty sure I'm familiar with the programmer you quote but could be different. He was adjusting color corrections via the player and saving the settings per title claiming HDR was a marketing gimmick and he was achieving the same thing using SDR titles and HDR titles without initiating HDR mode. Each title had to be previewed and tailored and then the settings saved via a file saved beside the title. Users had to tailor their own metadata. Furthermore he integrated it with KODI, put up a youtube video, and then asked money for it. Rather than pay for the software that automates some of this, you can test out the theory yourself by playing an SDR or HDR and adjust the color settings in your player. I don't know what any of that had to do with Windows getting it right and displays not.

I know how much mclingo and his AMD cards like me. I'm sure he'll be taking his rig over to his neighbor with a Samsung 10bit any moment now. Maybe an AMD card will land in my lap. Good suggestion, one I hadn't thought of. Hmmmm?

[Warner306]

I'm pretty sure I'm familiar with the programmer you quote but could be different. He was adjusting color corrections via the player and saving the settings per title claiming HDR was a marketing gimmick and he was achieving the same thing using SDR titles and HDR titles without initiating HDR mode. Each title had to be previewed and tailored and then the settings saved via a file saved beside the title. Users had to tailor their own metadata. Furthermore he integrated it with KODI, put up a youtube video, and then asked money for it. Rather than pay for the software that automates some of this, you can test out the theory yourself by playing an SDR or HDR and adjust the color settings in your player. I don't know what any of that had to do with Windows getting it right and displays not.

I know how much mclingo and his AMD cards like me. I'm sure he'll be taking his rig over to his neighbor with a Samsung 10bit any moment now. Maybe an AMD card will land in my lap. Good suggestion, one I hadn't thought of. Hmmmm?

Did he mention if Windows does the tone mapping? That’s what I got. It does trigger HDR mode but alters the metadata. The upcoming Windows HDR calibration feature seems to indicate that.

[nevcairiel]

madVR has a native display bitdepth adjustment. We can select 1-9 and the next option is 10 or better.

What if madVR had exclusive adjustments for 10,11,12, and so on? This way no matter what the GPU sent (12 in this case), it would adhere to the display bitdepth limit we select, in this case, 10.

'auto' still selects what the GPU is sending (12) and some of us 10bit native display owners are encountering epic failures because of poorly implemented display modes that don't handle 12bit

madVR can only send two formats to the GPU, 8-bit RGB or 10-bit RGB. The only other commonly supported formats on GPUs is 16-bit, and madshi has previously said that the 16-bit format is rather "weird", and doesn't necessarily work right.

So that means that you cannot have any special handling for 12-bit output, since you cannot give the GPU 12-bit data, and dithering to 12-bit makes no sense if you transport 10-bit data afterwards.

As a consequence, this also means that dithering to 10-bit is pointless if you send 8-bit data to the GPU, and I would hope that madVR is actually smart enough to automatically dither to 8-bit if its sending 8-bit output, even if the device settings are set to 10-bit.

[brazen1]

I don't know how far it progressed? I was the one persuading him to trigger the Windows advanced HDR and color switch early on and apply HDR through Windows because there was nothing else at the time. No one could replicate a shortcut to the feature. Had there been one I'd of done my own thing. Then madshi beat him to it, avoiding Windows altogether, and going straight to the display once NVidia released its private API. I prefer GPU initiated HDR. Early on testing between Windows HDR and GPU HDR were night and day imo. I know the poster here lately tested this problem we've been tiring of tried it recently too to help debug. To this day, I don't think that switch is automated or triggered by anything. It's on always or off always until you change it. I'm very glad madshi waited and chose the direction he did.

Thank you nevcairiel. That answers that. It seems my fate is in the hands of driver development to introduce RGB 10bit since special 12 bit handling isn't possible for 10bit sources and the only other choice of 8bit is HDR digression. Evidently, AMD is able to output it. nVidia needs to step it up. I'm about to convert.....

[el Filou]

it should still be possible to force nvidia to output 10 bit with a custom edid.Could you elaborate on that? Would the graphics card 'fall back' to 10 bpc by hiding 12 bpc from the accepted formats maybe?

[nevcairiel]

Could you elaborate on that? Would the graphics card 'fall back' to 10 bpc by hiding 12 bpc from the accepted formats maybe?

Of course. Its not like NVIDIA doesn't support 10-bit, they just only offer 8-bit and the highest format supported in the settings. My PC screen here which only supports 10-bit also makes NVIDIA offer that in the control panel.
So you could take the EDID from your screen as-is, and just remove the 12-bit modes, and it should instead offer you 10-bit options.

[huhn]

That's completely unsurprising if your "5 year old monitor" has lower contrast than your "2016 LG Oled", which seems extremely likely. The higher the contrast, the more visible banding is.

no not really it's a known processing error on LG OLED screens.

oled has only much ""bigger" steps in the dark part the rest is very close to even 1000:1 TVs. so no higher contrast doesn't mean generally more banding. and LG claims it is a 10 bit panel with 4 subpixel where one is white giving it in theory 20 bit for luma... so NO.

[j82k]

That's completely unsurprising if your "5 year old monitor" has lower contrast than your "2016 LG Oled", which seems extremely likely. The higher the contrast, the more visible banding is.

While contrast certainly plays a role, it's not about that. The gradation on Oleds is just bad. When looking at grayscale steps test pattern it's just not evenly graded. The difference from one step to the next is sometimes too small and sometimes too big, especially near black steps are extremely bad.

What's funny is that setting madVR to 5-bit makes the grading look almost perfect but that of course causes too much noise and other issues.

[ryrynz]

Makes me wonder if madshi couldn't cook up some special OLED dithering xD. Sony's are superior in this area as reviews have highlighted.
Panasonic and LG both have some improvements in gradients, this years Panasonic OLEDs feature an updated LUT and LG's C series and above feature it's α9 processor to better deal with this.