MadVR in use with LG OLED Thread

[aron7awol]

So I generated a measurement file as a test to see what it contained. What do you guys use to analyze the resulting measurement files, this?

https://www.avsforum.com/threads/madvr-tool-madmeasurehdr-optimizer-measurements-dynamic-clipping-target-nits.3040072/page-17#post-57433788

That tool only seems to give limited info on frames (peak nits, LUMs, and HUEs) and scenes (scene peak), and it shows some percentiles which would be really useful if they were related to frames or scenes but instead they are percentiles of the entire file.

Do you guys know of a way to get more granular data out of the measurement file, or is this all it contains?

[quietvoid]

Before a tool there was an Excel spreadsheet, you can try finding that one.
Probably doesn't have new calculations or something, but you'd have access to the data.
Sadly I don't think Soulnight ever shared the code.

An alternative would be parsing the measurement files, but I don't know the format.
If you find a description of the fields, I might look into it.

I also found the other one: https://www.avsforum.com/threads/madvr-tool-madmeasurehdr-optimizer-measurements-dynamic-clipping-target-nits.3040072/page-17#post-57433788
May have more what you're looking for.

[aron7awol]

Thanks. Unfortunately, that's the same tool I tried :(

An Excel spreadsheet sounds good, I'll look for that.

[chros]

I don't know any other tool we can use for measurement files, only this one (let alone the docs for it :) ).
Basically, these were the "offline" variant of the histogram on the OSD, that's why only the brightness and hue histogram data is in it.
- on the main tab you can double click on:
-- an "avg xxx% frame peak" row (in the middle column) -> yellow graph will appear on graph
-- a scene row )on the left column to get a scene histogram + graph
--- here you can double click on a frame to get both histogram
- right click on a row -> export to txt

Can you upload the measurement file somewhere? (e.g. 7zip-ed to wetransfer.com (https://wetransfer.com/)) Thanks

Edit: I saw quietvoid already replied :)
@quietvoid: you can export it into txt (see above) if you like

Sky detection: thanks guys, then I remembered wrong, so it's not a bug :) I don't see any changes in the image here either.
(Btw, I used 700/60 because I switched off sky algo (=0).)
So, what values should we use for this during testing? 100, 20, 20, 20?

About dynamic clipping: I'm certain that is indeed a bug :) there's no hidden meaning behind it.

[aron7awol]

I don't know any other tool we can use for measurement files, only this one (let alone the docs for it :) ).
Basically, these were the "offline" variant of the histogram on the OSD, that's why only the brightness and hue histogram data is in it.
Hmm, so if the measurement file doesn't actually contain the frame by frame data that we would need to get the pieces of data I listed in my sheet, then I guess we're stuck compiling most of it manually (and unable to get the rest of the data that I really wanted). :( Maybe once madshi gets back on the target topic we can get him to dump some additional data on the OSD or in a measurement file.

Can you upload the measurement file somewhere? (e.g. 7zip-ed to wetransfer.com (https://wetransfer.com/)) Thanks
Sure, but I should probably do The Grinch rather than the random short episode I did just as a test :)


Sky detection: thanks guys, then I remembered wrong, so it's not a bug :) I don't see any changes in the image here either.
(Btw, I used 700/60 because I switched off sky algo (=0).)
So, what values should we use for this during testing? 100, 20, 20, 20?
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!

About dynamic clipping: I'm certain that is indeed a bug :) there's no hidden meaning behind it.
Bug or not, the edge case I considered would be a real problem, but that's not to say we shouldn't be able to disable it when peak < DPL! After all, it's just an edge case. I'm just giving madshi the benefit of the doubt. :)

[quietvoid]

Hmm I would think there is frame by frame data, it was just grouped by scene to verify scene cuts.
Otherwise there's no way you can do such a graph scene by scene..
For example: https://www.avsforum.com/attachments/2019-1-18-3-jpg.2512358/

Anyways, here's the post detailing the format: https://www.avsforum.com/threads/improving-madvr-hdr-to-sdr-mapping-for-projector.2954506/page-185#post-57030812
I don't have a measurement file laying around anymore..

[chros]

Hmm I would think there is frame by frame data, it was just grouped by scene to verify scene cuts.
Otherwise there's no way you can do such a graph scene by scene..
For example: https://www.avsforum.com/attachments/2019-1-18-3-jpg.2512358/

Yes, and when you double click on a row on the table you will get the histogram data graphs.

[aron7awol]

So I decided to test Dynamic Clipping a bit, because I've never actually turned it on, and I wondered if it could be useful to us. After all, a lot of us like the sometimes pretty heavy clipping that using higher DPLs than our actual panel peak nits gives us, so I wanted to see if Dynamic Clipping 100 would be similar, stronger, or weaker than that.

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.

[oldpainlesskodi]

Sorry for being a little off topic - does anyone else's LG OLED map the color gamut to wide in PC mode? Even though the option is disabled, after going back and forwards with testing, it certainly seems that mine is mapping to wide in PC mode.

If it makes any difference, full chain in RGB, and both 60 and 23.976 fps (10bit) tested.

[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.

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?

(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?

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 (https://www.avsforum.com/threads/improving-madvr-hdr-to-sdr-mapping-for-projector.2954506/post-60250637) :)

[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]

Sure, but I should probably do The Grinch rather than the random short episode I did just as a test :)
Here it is (https://we.tl/t-5syLTZORR1) (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]

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]

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.

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! :)

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?

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.

I agree (if we decide it's useful for us) but that means he changed it in the last 2 months (https://www.avsforum.com/threads/improving-madvr-hdr-to-sdr-mapping-for-projector.2954506/post-60250637) :)
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]

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.

I know you mean DTN, not DPL, in that last sentence.
Yes, sorry, corrected, thanks.

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.

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

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! :)

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]

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?

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]

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]

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]

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/improving-madvr-hdr-to-sdr-mapping-for-projector.2954506/page-215#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!

[quietvoid]

I've updated my 2018 to 05.30.10, reset all settings.
No improvement for Dolby Vision black levels, contrast 99 looks weird.

I'm questioning one thing, what do you guys have set for Color Gamut in HDR?
Auto looks less saturated than Wide, with all my inputs (FireTV stick, madVR).
But I don't know if Wide is accurate.

[QBhd]

I have been on Auto since day 1... but like you I am not sure if it is correct or not. I may do a few measurements this week... maybe :)

QB

[quietvoid]

I've read that it just increases saturation artificially, but it's weird to name an option that way.

[chros]

I've updated my 2018 to 05.30.10, reset all settings.
No improvement for Dolby Vision black levels, contrast 99 looks weird.
Cheers. According to Vincent, they just recently fixed the CX DV black issue with the 2nd firmware release, not before.

I'm questioning one thing, what do you guys have set for Color Gamut in HDR?
Auto looks less saturated than Wide, with all my inputs (FireTV stick, madVR).
But I don't know if Wide is accurate.
I also use Auto (Cinema preset default) with HDR10. The interesting part is that I tried it with Cinema Home preset, and "Extended" is the very same as Auto (Cinema) and not "Wide"!

I have been on Auto since day 1... but like you I am not sure if it is correct or not. I may do a few measurements this week... maybe :)
That would be nice, I only measured SDR.

I've read that it just increases saturation artificially, but it's weird to name an option that way.
Which option? :) Wide?

[quietvoid]

Which option? :) Wide?

Yes, Wide.

[SamuriHL]

I've updated my 2018 to 05.30.10, reset all settings.


Not available for me yet. Didn't even know they put a new build out. Typical.

[SamuriHL]

[05.30.10]
1. Improved disconnection in certain apps after software update

Really? Yawn.

[quietvoid]

The 05.30.02 update had a lot of issues with WiFi slowing down significantly and even dropping.
They didn't mess around to publish a hotfix.
Basically these last updates just add AirPlay support.

[Asmodian]

I am very happy to report that firmware 03.21.16 seems to have solved my near black banding problem when sending full range RGB to my 48" LG CX. :)

After recalibrating with the new firmware (which was needed) I am happy running 10 bit RGB full 120 Hz to the display, though I still have madVR dithering to 8 bit to reduce banding.

[SamuriHL]

Where's that one finger salute emoji..... Lmao! I'm glad they fixed it for you. I just wish they'd maybe back port a few fixes. Sigh

Sent from my SM-G975U using Tapatalk

[chros]

I'm glad they fixed it for you.
Better later than never :D But seriously, 9 months after releasing a product ... finally DV is maybe good now :)

You can pick up scenes as well, share the timestamps and that's it.
- let's use 800/75 then for now
-- "disabled avgHL ceiling" enabled
-- "don't add peak nits" enabled
-- all the other unnecessary options disabled (contrast/shadow recovery, dynamic clipping, sky strength)
- that means DTN will kick in at ~184 FALL (if frame peak > DPL)
- the question is what FALL/scene combo DTN is really needed and is there any scene in the title when DTN is unnecessary with these settings
-- if we can come up with a DTN value at the end for this title then that'd be the best :)

One more important thing:
- madvr can/does result in different ADPLs during playback vs still images!

The Grinch is very bright, so it's easy to find scenes like this:
- 1: 00:02:05 - 00:03:20 (2985 - 4784)
- 2: 00:06:45 - 00:07:25 (9699 - 10658)
- 3: 00:13:10 - 00:14:00 (18930 - 20130)
-- this scene is interesting, there are frames when frame peak is only ~430 but FALL is >200.
- 4: 00:16:00 - 00:16:45 (23006 - 24086)
So, I had a little time to play with these (I added frame numbers to scenes as well), in short:
- I disabled (!) DTN for "normal" content (in my default HDR10 profile)

Here is why, DTN cause more harm than good with "normal" content:
- I haven't seen any frames that needs DTN (dimming)
- madvr works with scenes:
-- it resets on scene changes
-- within a scene it slowly corrects itself
--- often happens that there are high FALL frames for only couple of seconds that still unnecessarly dim the following frames in the same scenes

The real question is what contents are "normal" for us high DPL users, based on avgHL or frame peak or something else (as we already talked about it). I bet 95% of the content we come across today are like this.

What clear now is that the current implementation of DTN is completely wrong for high DPLs, meaning we definitely can't use 1 profile settings for all the content we have.

[SamuriHL]

LG hasn't given me a whole lot of reasons to upgrade my C8. Lower max nit level. Still screwed up DV (may be fixed finally?! WOO?). PC mode still not 100% awesome. I mean they're getting better but I'd need a flawless panel to get me to want to upgrade. I want to see what the hell they've done this year because the Cx (not to be confused with the CX LOL) line didn't get the upgraded panel tech this year. WTF? They really know how to confuse people.

[chros]

I agree, and not to mention new panel issues: horizontal banding, grid pattern, etc.
For me the biggest issue with separating Gx from Cx is that these will have different firmwares! What a mess this will be :D

[Asmodian]

I am hoping all models get the new panels in 2022 and re-unify the Cx and Gx.

PC mode still not 100% awesome.

I agree that it isn't 100% awesome but the newest firmware on the 2020 models solved my last significant issue with PC mode. Banding seems similar in PC mode v.s. HDMI mode now, in both HDR and SDR.

I can always get more picky, and there are plenty of imperfections when I do, but PC mode has improved so much since my C7 that I have to be happy about it. At least for a bit. ;)

[aron7awol]

So, I had a little time to play with these (I added frame numbers to scenes as well), in short:
- I disabled (!) DTN for "normal" content (in my default HDR10 profile)

Here is why, DTN cause more harm than good with "normal" content:
- I haven't seen any frames that needs DTN (dimming)
- madvr works with scenes:
-- it resets on scene changes
-- within a scene it slowly corrects itself
--- often happens that there are high FALL frames for only couple of seconds that still unnecessarly dim the following frames in the same scenes

The real question is what contents are "normal" for us high DPL users, based on avgHL or frame peak or something else (as we already talked about it). I bet 95% of the content we come across today are like this.

What clear now is that the current implementation of DTN is completely wrong for high DPLs, meaning we definitely can't use 1 profile settings for all the content we have.
Did you have sky detection turned on? I found DTN to not do very much with The Grinch with it on, which sounds like what you want it to do.

[chros]

It was off as per instructions along with the others. My point is that based on those 4 scenes TG doesn't need DTN!

[aron7awol]

It was off as per instructions along with the others. My point is that based on those 4 scenes TG doesn't need DTN!
Okay, but sky detection seems to work perfectly on that movie to lower FALL so that DTN does little/nothing, which seems to be exactly what you want on those scenes. Otherwise, you have to lower DTN in order to stop it from kicking in and see how that lower DTN works with other content.

Sky detection is designed to work hand-in-hand with DTN (it modifies FALL only for the DTN calc and does nothing else), so I think it's premature to conclude that the current implementation of DTN is completely wrong for high DPLs when we've only tested a single DTN and only without sky detection doing its job to lower targets in flat skies which are abundant in The Grinch.

I think if you enable sky detection on those scenes you will come to quite the opposite conclusion, that the targeting actually ends up very close to where you want it on those scenes with the 75 DTN.

[chros]

Okay, but sky detection seems to work perfectly on that movie to lower FALL so that DTN does little/nothing, which seems to be exactly what you want on those scenes. Otherwise, you have to lower DTN in order to stop it from kicking in and see how that lower DTN works with other content.
Yes, it helps, bit still not perfect, DTN is triggered once in scene 2 (although just for a short time), but in scene 4 similar thing happens than without it:
- "disable avgHL ceiling" disabled
- avgHL ceiling: 2x
- sky strength: 100

that the targeting actually ends up very close to where you want it
And that is my point: it doesn't. I think TG (that is an extreme example of "normal" contents) doesn't need DTN at all.

So, if someone comes across these type of contents (e.g. maxCLL < 1300-1600 nits) that benefit from DTN then please share it (with timestamps).

[aron7awol]

So let's focus on those scenes where it is doing what you don't want it to do, even with sky detection enabled.

For each of those scenes make a note of:
With sky detection enabled, what is FALL, and what is the resulting target?
If you lower avgHL multiplier further, is there a point where it kicks in?
Does changing the sky max width 10 vs 20 or the hill settings help ?

[aron7awol]

https://i.imgur.com/KA8mV6X.png

Did some testing of those same scenes to see what impact the avgHL ceiling and sky detection would have on those frames which result in targets >800 with just DTN 75:

1. Sky detection lowered the target down to 800 in 4 out of the 6 frames.
2. In the two remaining frames, a 2.5x avgHL ceiling lowered the target down to 800.
3. Thus, running sky detection and a 2.5x avgHL ceiling resulted in a target of 800 in all of the frames tested.

I went back at the end to one of those two frames (6:59 shown at the bottom of the list) where sky detection didn't lower the target, and tested Dynamic Clipping to see if it would have any impact. A value as low as 20 lowered the target down to 800 alone.

So I think this is a good exercise showing the power of the ancillary functions of the algo, where we see each of them able to chip in and lower targets in certain cases, and although one of them alone didn't do that completely, when enabled together they can combine to give us the targets we want. And let's keep in mind we haven't even established that 75 DTN is what we want, but it still shows that DTN can work for this particular movie with sky and avgHL ceiling enabled.

I added a column to the far right showing the maximum DTN for each frame that would result in a target of 800. I think that columns shows nicely that relying on just a single DTN FALL multiplier to end up at the right targets is an exercise in futility, and that some ancillary functions are essentially required in order to get good targets. I don't see this as a knock on DTN, it's just that FALL alone only tells us so much, and so the FALL multiplier is just one piece of the puzzle.

So @chros, I think if you run through The Grinch with sky detection on and a 2.5x avgHL ceiling (I'm leaving DC off for now because of the order-of-operations error when used concurrently with sky detection) you'll be very happy with the resulting targets. The question then becomes, are there any frames where that combo results in a target we aren't happy with? We now need to find those so we can take the next steps.

Edit: I went back through with those settings and found a frame at 2:20 which resulted in a target >800. The target was 830, which was avgHLx2.5 and so avgHL was 332 for this frame. Lowering DTN to 65 lowered the target to 800. Additionally, I switched back and forth between the 800 and 830 target for this frame and really couldn't tell any difference anyway.

Edit2: Also forgot to mention that 2.75x works almost as well as 2.50x to keep those targets down. It resulted in some that were something like 806 nits instead of 800 but that's inconsequential. Just wanted to mention it because 2.50x might be a little lower than we want for some other stuff like The Meg. FWIW, my previous testing had found an avgHL multiplier that was approximately 70% of FALL multiplier seemed to work well, which in this case would be 3.05x for the 800/75 combo. That is the exact combo I liked a lot with The Meg: 800/75 3.00x. This is good, I think, that combo of settings actually works quite well on both The Grinch and The Meg. I might choose something in between 2.75x and 3.00x if that were possible.

[chros]

Thanks for the detailed post, but I got different results than you, how is this possible? :)
Here are the 2 frames (that cause the issues in scene 2 and 4, you can you ctrl+g in mpcbe to jump there (note that directshow isn't not frame accurate seeking), and btw there's a new repeat A-B feature in the latest mpc-be beta (under Play -> Repeat) that is really useful for testing scenes :) )

Here's my settings (https://imgbox.com/1bCmZUqW) (note that I still use b119, not the newest):
- note I used my SDR monitor for reading data from it (not image comparison, for that I used the TV)
-- calibration is set to bt2020 (although just the measured peak changes with e.g. bt709)
- lum method and desat options doesn't seem to change anything
- max width of sky strength doesn't seem to change anything either (using these 2 frames)

1. @7:12 frame 10361: frame peak 990 (vs 977), FALL 321.4 nits (vs 324)
- 2.5x avgHL: 990 (vs 977)
- sky100: 823 (vs 800) (FALL 188.62)
- 2.5x avgHL + sky100: 823 (vs 800) (so sky detection does the job here alone)

Now I wonder where the different values come from in your vs my case...

2. @16:17 frame 23434: frame peak 809, FALL 465 nits
- 2.5x avgHL: 809
- sky100: 809 (FALL 443.49)
- 2.5x avgHL + sky100: 809

This is the first frame of the scene, it's seemingly harmless, but that's (and the following high FALL frames) the cause for dimming other frames unnecessarely here.