MadVR in use with LG OLED Thread

[chros]

I also use these modes on my B8, but the gamut option is (!) available in ISF Dark/Bright SDR modes, so I set it to Wide.

Originally Posted by aron7awol

I used the scene at the beginning of Valerian that I've seen others in the AVS thread use to show what Dynamic Clipping does. And I actually think, based on the testing I just did, that similar to the Sky Detection, even though the OSD always shows a change, it doesn't actually kick in when peak < DPL.

At first I was just testing at my normal high DPL, and I was thrown off because even though the frame peak was changing in the OSD, suggesting clipping was occurring, I couldn't find any change in the image whatsoever. And so after messing around with other frames and still not seeing any change, I tried a lower DPL, and sure enough, the clipping (in this case, on her necklace) was immediately in my face obvious. So then I started creeping up on DPL, and the clipping became less and less, and once I got up to the original frame peak, there was no clipping at all.

So it seems it actually works exactly as we want it to, where it only clips as much as needed to bring the frame peak down to DPL, but no more, and so if peak < DPL, not at all.

Indeed!!! Thanks for this test!
I just tested the MMFR sample (keyframe at 00:19 sec, frame peak 6344 without clipping), lum max to see the blue patches.
I tried various DPLs 800/2000/4000 and set the clipping according to them: e.g. at 4000 DPL, 40 DC results in 3954 nits. If I use higher DC e.g. 100 no difference in the patches, if I go lower e.g. 39 there is difference (slight) straight away.
So this one isn't a bug either

Does this mean that there's a lower limit at DPL for this?
If so, then why on earth madvr allows the measured nits value to go lower than DPL?! What's the point?
I mean, with DC we clearly have the lower limit which is DPL!!! (Unlike with the sky algo where we don't have a specific lower limit, at least not that straightforward.)
What am I missing here?

Originally Posted by chros

(Btw, I used 700/60 because I switched off sky algo (=0).)

This one kept me thinking: are you sure that the sky algo is useful for us? (try it with The Meg (TM) sample)
Let's take these two profiles (DPL/DTN/SS):
- p1: 800/60/0
- p2: 800/85/100

The purpose of sky detection is the lower the FALL of high FALL scenes so DTN doesn't result in such high ADPLs, allowing to use higher ADPL value (85 vs 60), right?

But this one actually has a side effect:
- high FALL scenes:
-- with p1: they still have high FALL, so we don't need to use high DPL for these
-- with p2: they have way lower FALL, so to compensate we need high DPL
- lower FALL scenes (not really low ones)
-- with p1: we don't have such high ADPLs due to low DTN
-- with p2: we will have higher ADPLs (than peobably is necessary) due to the higher DPL!!!

What do you think?

Originally Posted by aron7awol

Maybe the 100 10 20 20 that Neo-XP uses? I know he's done extensive testing with it, and if that's not harmful for his lower nits I'm certain it won't be for us!

I agree (if we decide it's useful for us) but that means he changed it in the last 2 months

[VBB]

@oldpainlesskodi - My C7 is locked to "Wide" in PC mode.

[oldpainlesskodi]

Thanks VBB - not just mine then. So, begs the question if auto in non-pc mode is the correct option then...

[chros]

Originally Posted by aron7awol

Sure, but I should probably do The Grinch rather than the random short episode I did just as a test

Here it is (I just used the biggest m2ts file), madmeasure.exe stats:

Metadata:
  Mastering display luminance: 0.0001/1000, gamut: 0.68 0.32, 0.15 0.06, 0.265 0.69, 0.3127 0.329
  MaxCLL: 1000, MaxFALL: 407 nits
Measurements:
  Frames: 123455, MaxCLL 100%: 3916, 99.9%: 1195, MaxFALL: 884, AvgFALL: 100, AvgFMLL: 791 nits

[VBB]

Originally Posted by oldpainlesskodi

Thanks VBB - not just mine then. So, begs the question if auto in non-pc mode is the correct option then...

Depends on what you mean by correct. Auto in non-PC mode maps to BT.709, while Wide in PC mode maps to the panel's native gamut, which is close to DCI-P3. Whatever you set the TV to, just make sure to match that in madVR. The same goes for gamma.

[oldpainlesskodi]

Yeah, that was kinda my point - surely in PC mode the panel should be in monitor mode and display what it thinks is being sent? After all, what is PC mode supposed to do......just curious why it maps to wide color gamut I guess.

[VBB]

I don't know why LG think it's a good idea to lock anything.

[aron7awol]

Originally Posted by chros

Indeed!!! Thanks for this test!
I just tested the MMFR sample (keyframe at 00:19 sec, frame peak 6344 without clipping), lum max to see the blue patches.
I tried various DPLs 800/2000/4000 and set the clipping according to them: e.g. at 4000 DPL, 40 DC results in 3954 nits. If I use higher DC e.g. 100 no difference in the patches, if I go lower e.g. 39 there is difference (slight) straight away.
So this one isn't a bug either

Does this mean that there's a lower limit at DPL for this?
If so, then why on earth madvr allows the measured nits value to go lower than DPL?! What's the point?
I mean, with DC we clearly have the lower limit which is DPL!!! (Unlike with the sky algo where we don't have a specific lower limit, at least not that straightforward.)
What am I missing here?

So, my quick answer off-the-cuff is that I think this ends up as just a display thing in the OSD, similar to how FALL changes from sky detection in the OSD even when nothing actually changes. But I want to think about this a little more to be sure.

And just for the record, I'm not sure I even want to use dynamic clipping yet at the end of the day, I just wanted to test it to see if I liked what it did, and at least it seems to work as intended and so we can evaluate potentially using it.

Originally Posted by chros

This one kept me thinking: are you sure that the sky algo is useful for us? (try it with The Meg (TM) sample)

I am certainly not sure!

Originally Posted by chros

Let's take these two profiles (DPL/DTN/SS):
- p1: 800/60/0
- p2: 800/85/100

The purpose of sky detection is the lower the FALL of high FALL scenes so DTN doesn't result in such high ADPLs, allowing to use higher DPL value (85 vs 60), right?

I know you mean DTN, not DPL, in that last sentence. I'm not sure I would say the purpose of sky detection is to lower FALL to allow the use of a higher DTN, as much as I'd say the purpose is really to lower FALL so that the target doesn't end up unnecessarily high in that particular scene. But that being said, that reduction of the target in those scenes may allow the use of a higher DTN in a case where a user wanted to use a higher DTN based on other scenes but only didn't because of these scenes. So I do get what you're saying, I just think that's really more of a potential side benefit than a primary intent?

Originally Posted by chros

But this one actually has a side effect:
- high FALL scenes:
-- with p1: they still have high FALL, so we don't need to use high DPL for these
-- with p2: they have way lower FALL, so to compensate we need high DPL
- lower FALL scenes (not really low ones)
-- with p1: we don't have such high ADPLs due to low DTN
-- with p2: we will have higher ADPLs (than peobably is necessary) due to the higher DPL!!!

What do you think?

So kind of as I refer to above, maybe we should compare the same DTN with/without sky detection first, and then evaluate whether we actually want to increase DTN on the sky-enabled profile. Because we might be happy with the lower targets it results in on certain scenes, but still like our normal targets on the other scenes. And then there's also the avgHL ceiling which can also bring down a "too high" target in other scenarios. And if there are other scenarios where we feel that a target is too high, we should try to figure out how to identify this scene from the data and maybe add some sort of additional "ceiling". So I think it comes down to whether we ever feel like we want a higher DTN based on some frames but other frames make us not want to increase it, and that's exactly where we need to focus on improving the algo.

Originally Posted by chros

I agree (if we decide it's useful for us) but that means he changed it in the last 2 months

I think he mentioned he changed it after switching to "don't add peak nits", for what that's worth.

[oldpainlesskodi]

@VBB - agreed. Oh well, more testing lol.

[chros]

Originally Posted by aron7awol

So, my quick answer off-the-cuff is that I think this ends up as just a display thing in the OSD, similar to how FALL changes from sky detection in the OSD even when nothing actually changes. But I want to think about this a little more to be sure.

Ok, thanks. But you can't come up any reasonable explanation for it either then let's report it madshi, because for me it doesn't make any sense.

Originally Posted by aron7awol

I know you mean DTN, not DPL, in that last sentence.

Yes, sorry, corrected, thanks.

Originally Posted by aron7awol

I'm not sure I would say the purpose of sky detection is to lower FALL to allow the use of a higher DTN, as much as I'd say the purpose is really to lower FALL so that the target doesn't end up unnecessarily high in that particular scene. But that being said, that reduction of the target in those scenes may allow the use of a higher DTN in a case where a user wanted to use a higher DTN based on other scenes but only didn't because of these scenes. So I do get what you're saying, I just think that's really more of a potential side benefit than a primary intent?

Yes, that's correct/what I meant.

Originally Posted by aron7awol

I think he mentioned he changed it after switching to "don't add peak nits", for what that's worth.

OK, can be, I don't remember.
So when we use it, let's use: 100/10/20/20

Originally Posted by aron7awol

And just for the record, I'm not sure I even want to use dynamic clipping yet at the end of the day, I just wanted to test it to see if I liked what it did, and at least it seems to work as intended and so we can evaluate potentially using it.
...
(sky detection) I am certainly not sure!

Originally Posted by aron7awol

So kind of as I refer to above, maybe we should compare the same DTN with/without sky detection first

Agreed: so what shall we do with these 2 during our initial testing?
I vote for:
- let's disable them (I don't think they are needed for "normal" content at all)
- we can play with them after that with the well known scenes

How does it sound?

[aron7awol]

Originally Posted by chros

Ok, thanks. But you can't come up any reasonable explanation for it either then let's report it madshi, because for me it doesn't make any sense.

I'm just trying to think about if it actually matters. What is that frame peak value used for? Smoothing algo and as a ceiling for TMing, anything else? Which value is better to use for smoothing, the original peak or the after-DC peak?

Originally Posted by chros

Agreed: so what shall we do with these 2 during our initial testing?
I vote for:
- let's disable them (I don't think they are needed for "normal" content at all)
- we can play with them after that with the well known scenes

How does it sound?

And this is exactly the dilemma I feel with trying to test some specific combination of settings, or with certain things disabled. They all work together to hit the targets, and so we can't really test them separately and arrive at any great conclusions, and trying to test them all together introduces so many variables.

And this is why even though it may initially sound more complicated, I actually think the simplest approach is to completely forget all the algos and all the complicated combinations of settings, and instead just look at a frame and find the target we want for that frame manually. Nothing more complicated than that. Pretend you are an AI that can analyze this frame and come up with an ideal target for that frame, what would it be? After all, if we could create the perfect algo, isn't that exactly what we would want it to arrive at?

It doesn't matter how exactly we are going to arrive at that target at the end of the day, maybe it's the existing algos, maybe it's a totally new algo, maybe it's a combination of the two. Let's cross that bridge when we get to it. We really need the targets first, to know if the existing algo can work or if it needs to be changed. Otherwise, we're just pigeon-holed into the existing algo and maybe it's impossible to make it consistently hit our targets, and so we're just stuck chasing our tail.

After all, even if you just go start testing with some combination of settings, what's going to happen when you test the first frame? You're going to look at it and decide if you're happy with it or not, right? Is this going to be a simple happy/unhappy question, or are you going to adjust up and down a bit to see if you can find something even better? In any case, inevitably you are going to come across a frame that you are unhappy with the result. What then? Are you going to then adjust DTN up/down to find something that works well for that frame? Once you do, are you then going to go back and test the previous frames that you were happy with with the new DTN and see if you're still happy with them? I hope you know I'm not being facetious, I'm genuinely asking what you are thinking as far as how to handle those scenarios during the testing.

[QBhd]

I have no idea what you two are trying to accomplish! Were have a boat load of settings and they all do different things. It's all well and good to have an understanding of what the settings do and why they are there. But there will be no perfect combination.

QB

[aron7awol]

Originally Posted by QBhd

I have no idea what you two are trying to accomplish! Were have a boat load of settings and they all do different things. It's all well and good to have an understanding of what the settings do and why they are there. But there will be no perfect combination.

I feel like it should be possible to make an algo that gets very close to hitting our ideal target on a particular frame, if we just figure out what exactly drives our preference on each "type" of frame. I would expect whatever it is that makes us choose one target over another will be there in the data if we just look for it. But first we need to know what target we actually want.

Right now the targeting is really only based on 3 things:
1. FALL multiplier (but is the relationship between FALL and a preferred target even linear?)
2. avgHL multiplier ceiling (but is using >100 nits as avgHL the best value to use, and again, is the relationship linear?)
3. Sky detection to ignore flat areas so they don't disproportionately bias the FALL targeting

It works pretty well as of now, but I think it could potentially be so much better.

[chros]

Originally Posted by QBhd

But there will be no perfect combination.

And that's the issue, see above.

[QBhd]

So you are going to do this for ONE frame? What about the trillions of trillions of other frames?

QB

[aron7awol]

Originally Posted by QBhd

So you are going to do this for ONE frame? What about the trillions of trillions of other frames?

No, of course not! But we don't need trillions of frames either. We just need a small subset that hopefully covers the different types of frames (only those that are bright enough to need target > DPL) that require different targeting. This is no different from when we normally test and hone in on a particular DTN that we use other than we aren't a slave to the algo, we just need to make a note of the preferred target (nits, not DTN value) for each frame we evaluate. Really, it's just the exceptions that the current algo doesn't target so well that we really need to know about.

[aron7awol]

Haha @chros, I think I found a bug when both sky detection and dynamic clipping are enabled at the same time! Pretty funny. So you were kind of right about the suspected bugs, you just needed to use both together to manifest it!

[chros]

I noticed something similar with sky strength at 199 (!) without DC, and I thought this value was 0-100

[quietvoid]

@aron7awol I've gone looking through the avs thread again.
Here's the latest Excel version of the measurement files parser: https://www.avsforum.com/threads/imp...#post-57108412

Format revisions:
v4: https://www.avsforum.com/posts/57030812
v5: https://www.avsforum.com/posts/57075684
v6 (current): https://www.avsforum.com/posts/57331156/

I've started to reimplement a parser to csv just in case madshi decides it's worth it to add the black level measurements for analysis.

[aron7awol]

Thank you!