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