MadVR in use with LG OLED Thread

[aron7awol]

Originally Posted by chros

Btw, @aron7awol, would you mind testing the cyan/magenta issue on your CX as well? But beware, once you've seen this (if it exists), you won't be able to unsee it anymore! Thanks

You're making me afraid to test this. The last thing I need is another thing to be looking out for when I'm trying to watch stuff! I'm bad enough already.

[aron7awol]

Originally Posted by chros

What do you need this for?

I wanted to move non-16:9 content to the bottom of the screen. It turns out it does work on the old Kodi DSPlayer as well as MPC. I tested it tonight and I actually love it. It not only moves the video closer to eye level, but it also moves the video closer to the center channel for better anchoring of the dialogue. Big upgrade! It's the little things

Originally Posted by chros

Thanks, something is indeed strange, the question is why.

1. here, both with the 1000 and 4000 file (both in nomarl and PC mode):
- a bit more visible the last box with 800 DPL than as with 700DPL! (Remember, that's what I saw with the SM horses scene in the snow)
- at 650 and 840 (!) boxes starts to disappear at the high end
- between 700 and 820 all the boxes appear, although the last box is pretty faint with 700

So, what does this mean? Is it because of the double tonemapping?!
It seems that the optimal settings for me are between 740-820, but that is way higher (40-120 nits) that I measured as a 1% window peak.

Your display certainly has some strange behavior with different maxCLL values, as you found in your curve testing. You really need the metadata override!

Originally Posted by chros

2. maybe it's not important for us, but I think for determining the peak DPL these files are not good, because they result in double tonemapping (unless you use 100 and 4000 DPL for the corresponding files).

I agree.

Originally Posted by chros

- that's what I meant when I mentioned Vincent's video, that we would need the right maxCLL file with the set DPL in madvr, e.g.:
-- 800 maxCLL file for 800 DPL, 850 maxCLL file for 850 DPL, etc

But doesn't madVR already change maxCLL to match DPL, meaning that is already happening for you?

[chros]

Originally Posted by aron7awol

You're making me afraid to test this. The last thing I need is another thing to be looking out for when I'm trying to watch stuff! I'm bad enough already.

I bet your curiosity will win in the end (It's enough to check The Witcher sample against its DV version on Netfilx.)

Originally Posted by aron7awol

I wanted to move non-16:9 content to the bottom of the screen. It turns out it does work on the old Kodi DSPlayer as well as MPC. I tested it tonight and I actually love it. It not only moves the video closer to eye level, but it also moves the video closer to the center channel for better anchoring of the dialogue. Big upgrade! It's the little things

Interesting.

Originally Posted by aron7awol

Your display certainly has some strange behavior with different maxCLL values, as you found in your curve testing. You really need the metadata override!

I agree, let's ask madshi all of us at the same time!
But I think that's what @QBhd saw as well on his C8, isn't it?

Originally Posted by aron7awol

But doesn't madVR already change maxCLL to match DPL, meaning that is already happening for you?

It does change it indeed, but my point was that it also does tonemapping with these 2 files (e.g. with 900 DPL and with the 1000 maxCLL file), the optimal would be if we would have maxCLL files for all the DPLs we want to try out; that's why we have double tonemapping with these.
Although you could argue that this is exactly what's happening with real content as well...

[aron7awol]

Originally Posted by chros

It does change it indeed, but my point was that it also does tonemapping with these 2 files (e.g. with 900 DPL and with the 1000 maxCLL file), the optimal would be if we would have maxCLL files for all the DPLs we want to try out; that's why we have double tonemapping with these.
Although you could argue that this is exactly what's happening with real content as well...

But with how madVR has worked to this point, do you really have 900 DPL and 1000 maxCLL combo? Because madVR changes maxCLL to 900 in that 900 DPL scenario anyway. So really, you already have 900/900 combo.

[SamuriHL]

That's also why I asked for madshi to allow metadata override for passthrough. We want to be able to see how metadata alone messes with how the TV itself works. Now, yes, I could already do that myself, but I don't feel I'm fully qualified to judge what's happening and more eyes are better.

[chros]

Originally Posted by aron7awol

But with how madVR has worked to this point, do you really have 900 DPL and 1000 maxCLL combo? Because madVR changes maxCLL to 900 in that 900 DPL scenario anyway. So really, you already have 900/900 combo.

Yes, that's true, but my point was that if the file indeed has data up to 1000 nits then it means that madvr has to compress it to 900!
But if we would have a 900 maxCLL file madvr (in theory) wouldn't compress anything with 900 DPL

Anyway, now I think we can move on to DTN algo (since everybody has their own DPL setting)...

What do you think?
- first we have to come up with a DTN value for "normal" sources:
-- these are above of our DPL but not much
-- they only have "reasonable" FALL values

I think The Grinch (2018) (CLL can reach 1300-1600, FALL 200-300) is a good candidate for this first step, if everyone agrees. (If you know other titles like this then let us know.)

So, I created a google-sheet for all of us (let me know if you miss something):
- used formula: APDL = log10(DPL) * DTN/50 * FALL
- 2 tables in it for: 800 DPL and 875 DPL
-- first column is DTN, the first row is FALL

This doesn't take into account the followings (for now):
- CLL of the frame
- limiter

[aron7awol]

Originally Posted by chros

Yes, that's true, but my point was that if the file indeed has data up to 1000 nits then it means that madvr has to compress it to 900!
But if we would have a 900 maxCLL file madvr (in theory) wouldn't compress anything with 900 DPL

Okay, if that's what you're trying to accomplish, can't you set madVR to clip at 900 nits?

Edit to add: I still don't think it's possible to figure out to actual DPL using test patterns without being able to disable TMing on the display. Vincent is only able to do that because he knows/assumes the display is just tracking the EOTF and then clipping at DPL. It's not the double TMing that makes it's difficult/impossible, it's any TMing at all. So even if we could disable the display's TMing, we wouldn't use madVR TMing either for this exercise.

[chros]

Originally Posted by aron7awol

Okay, if that's what you're trying to accomplish, can't you set madVR to clip at 900 nits?

Maybe I can now, good idea, but previously we couldn't

About DTN, let's assume the limiter doesn't have any effect (only couple of really bright highlights are in the frame):
- if we take a look at the 875 table, we see that even using 60 DTN, DTN will kick in with 250 FALL!
- now the question is how high the CLL?
-- because if it's only 850 (below DPL) then we don't want DTN to work at all for sure! (I'm not sure that's the case now)
-- even if it's let's say 1100/1300 CLL, then the question is whether it's necessary to work or not

[aron7awol]

Originally Posted by chros

About DTN, let's assume the limiter doesn't have any effect (only couple of really bright highlights are in the frame):
- if we take a look at the 875 table, we see that even using 60 DTN, DTN will kick in with 250 FALL!
- now the question is how high the CLL?
-- because if it's only 850 (below DPL) then we don't want DTN to work at all for sure! (I'm not sure that's the case now)
-- even if it's let's say 1100/1300 CLL, then the question is whether it's necessary to work or not

We can't really assume this frame only has a couple really bright highlights if it has a 250 FALL. 250 FALL is really quite high. DTN should almost certainly be kicking in on 250 FALL frames. (This is why on my Excel sheet that I posted some previous DTN calculation screenshots from, you'll see I didn't use a linear scale for FALL and instead started really low and did exponential growth. I'll post what I used.)

If frame peak (I think that's what you are talking about when you say CLL, right?) is <DPL DTN will do nothing. In reality, DTN will do nothing in most cases even when frame peak > DPL, because that happens all the time at FALL values that are too low for DTN to kick in.

Edit: I started with FALL of 2 and multiplied by 1.3 each time, which resulted in FALL >4000 within the ~30 rows.

Edit2: I also made the formula ADPL = max(log10(DPL) * DTN/50 * FALL, DPL) so that ADPL = DPL when DPL is greater. Then we see it TMs to DPL until it exceeds it and kicks in.

The example I posted for Neo-XP:

[chros]

Yes, CLL is frame peak, Edit2 is good idea, Fall values also can be exponential, yes.
But we need numbers for us, that's why I crsated the sheet.
And I'm not sure at all that 250 Fall has to trigger DTN with 60 DTN in every cases.

[aron7awol]

I think I'd kind of summarize my interpretation of the whole operation of DTN and the avgHL ceiling as follows:

1. Frame peak is pretty much irrelevant. DTN doesn't even look at it, and it can be way higher than DPL without the highlights driving FALL high enough for DTN to kick in. Most frames including those with really bright highlights fall into this category, and DTN does nothing. madVR TMs to DPL.
2. Now as we get into frames with higher FALL (let's just say >200 FALL for this discussion, but obviously it depends on DPL and DTN settings) DTN kicks in and madVR TMs to a target higher than DPL then scales the result down to peak at DPL. Essentially (with don't add peak nits checked) this target is just a simple multiplier of FALL which we can calculate using the formula I posted previously.
3. Within this subset of frames with higher FALL, there is an additional consideration. Is this whole frame "bright" (I believe currently hardcoded to >100 nits but would love to be able to change this) or does it have dark/normal areas and also quite big and bright areas? This is where the avgHL ceiling comes in. avgHL is always >= FALL, but on frames where pretty much the whole frame is bright, it will be closer to FALL, and on frames where there are normal/dark areas, it will be significantly higher than FALL. I think essentially we are trying to account for frame dynamic range differences, and this helps us, to a limited extent, to differentiate within these high-FALL frames between those that have more or less dynamic range. And those with less dynamic range probably don't need as high of a target, and since avgHL will be close to FALL in these cases, the lower ceiling multiplier will result in a lower target than the normal target arrived at via the higher FALL multiplier. So we can try to choose a FALL multiplier that results in proper targets for the higher dynamic range high-FALL frames, but also an avgHL multiplier that results in proper (lower) targets for the lower dynamic range high-FALL frames.

I hope that is all coherent! I wanted to post something similar to this in the AVS thread for discussion there, but I've been waiting for madshi to get back on this topic. Meanwhile, we can work on it here.

Anyway, I'm not sure avgHL ceiling is the optimal way to account for category 3 and these dynamic range differences (and this is why I was thinking about things like stddev/percentile as potentially much better ways), but having the 100 nits "highlight" definition adjustable might help. I actually think the best way to hone in the optimal formulas would be to do a sort of case study where we pick a number of higher-FALL frames from a movie or different movies that sort of fall into these different scenarios, and each of us goes to each of these frames and finds their preferred target. Then based on this result we should be able to come up with a combination of settings and/or an improved formula that gets us close to these targets automatically in each case.

[aron7awol]

Originally Posted by chros

And I'm not sure at all that 250 Fall has to trigger DTN with 60 DTN in every cases.

This obviously depends on the specified DPL/DTN combo, but I'm confident the target exceeds DPL with FALL of 250 on the vast majority of combos that people run.

Low DPLs will exceed it pretty much automatically, as will

700/50
750/53
800/56
850/59
900/61
950/64
1000/67

I think all of us are running a combo that has a higher DTN that those.

You're running 700/60 and 800/?
I'm running a wide variety of DPLs and ~80 DTN
IIRC the other guys here are all ~75 DTN or higher?

Don't forget our DTNs all increased (or should have) with the "don't add peak nits" option, which is where this formula applies. So I don't think any of us are running low (<60) DTNs anymore with that option. You might be the lowest at 700/60.

[chros]

Originally Posted by chros

Fall values also can be exponential, yes

But I created those only up until 400 because we want to test "normal" content first, right?

Originally Posted by aron7awol

This obviously depends on the specified DPL/DTN combo, but I'm confident the target exceeds DPL with FALL of 250 on the vast majority of combos that people run. ...
...
You're running 700/60 and 800/?
...
Don't forget our DTNs all increased (or should have) with the "don't add peak nits" option, which is where this formula applies. So I don't think any of us are running low (<60) DTNs anymore with that option. You might be the lowest at 700/60.

I use 700/60, 800/59. And yes, obviously "don't add peak nits" option is enabled.
We want to experiment with the same settings, to avoid confusion, like this!

So, what about 800/75 to start with? If you like other pair instead, we can use that. But in this case we only have to take a look at 1 row in that sheet.
Along with these options:
- "don't add peak nits" enabled
- "avgHL ceiling" disabled (for "normal content" we don't need it)

Originally Posted by aron7awol

I think I'd kind of summarize my interpretation of the whole operation of DTN and the avgHL ceiling as follows:

1. Frame peak is pretty much irrelevant. DTN doesn't even look at it, and it can be way higher than DPL without the highlights driving FALL high enough for DTN to kick in. Most frames including those with really bright highlights fall into this category, and DTN does nothing. madVR TMs to DPL.

Yes, that's the case for now, but the question is whether this is allright? We agree that having 300 FALL with 600 frame peak is not the same as having it with 1300 frame peak.
That's why I though about CLL, but maybe your 3. point is better for this.

Originally Posted by aron7awol

3. Within this subset of frames with higher FALL, there is an additional consideration. Is this whole frame "bright" (I believe currently hardcoded to >100 nits but would love to be able to change this)

I also think it's 100 nits, the brightness histogram (top right on the OSD) display these as grey (first half of the histogram, 0-63).
And as I said, probably it needs to be some dynamic detection for this, based on the content.

Originally Posted by aron7awol

or does it have dark/normal areas and also quite big and bright areas? This is where the avgHL ceiling comes in. avgHL is always >= FALL, but on frames where pretty much the whole frame is bright, it will be closer to FALL, and on frames where there are normal/dark areas, it will be significantly higher than FALL. I think essentially we are trying to account for frame dynamic range differences, and this helps us, to a limited extent, to differentiate within these high-FALL frames between those that have more or less dynamic range. And those with less dynamic range probably don't need as high of a target, and since avgHL will be close to FALL in these cases, the lower ceiling multiplier will result in a lower target than the normal target arrived at via the higher FALL multiplier. So we can try to choose a FALL multiplier that results in proper targets for the higher dynamic range high-FALL frames, but also an avgHL multiplier that results in proper (lower) targets for the lower dynamic range high-FALL frames.

Good idea, the histogram can help with determining this (instead checking CLL).

Originally Posted by aron7awol

Anyway, I'm not sure avgHL ceiling is the optimal way to account for category 3 and these dynamic range differences (and this is why I was thinking about things like stddev/percentile as potentially much better ways)

What do you mean about stddev? (There's a FALL Stddev on OSD as well, but no one knows what it shows )

Originally Posted by aron7awol

but having the 100 nits "highlight" definition adjustable might help.

This has to be dynamic, we don't want to use profiles for this.

Originally Posted by aron7awol

I actually think the best way to hone in the optimal formulas would be to do a sort of case study where we pick a number of higher-FALL frames from a movie or different movies that sort of fall into these different scenarios, and each of us goes to each of these frames and finds their preferred target. Then based on this result we should be able to come up with a combination of settings and/or an improved formula that gets us close to these targets automatically in each case.

Hmm, that's one way, but I'm not sure it would be fruitful.
What about this for now?
- select 1 title/scenes with appropriate frames for testing
- we will check it together
- try to draw the same (!) conclusion (if we won't agree what we should achieve then we don't have to work on this together )

So, I propose (for the 3rd time) The Grinch (2018).
Thoughts?

[aron7awol]

Originally Posted by chros

But I created those only up until 400 because we want to test "normal" content first, right?

Sure, anything is fine with me.

Originally Posted by chros

I use 700/60, 800/59. And yes, obviously "don't add peak nits" option is enabled.
We want to experiment with the same settings, to avoid confusion, like this!

Okay, I didn't realize you were trying to get us all to agree on a DTN setting? Seems unlikely, but I'll go along.

Originally Posted by chros

So, what about 800/75 to start with? If you like other pair instead, we can use that. But in this case we only have to take a look at 1 row in that sheet.
Along with these options:
- "don't add peak nits" enabled
- "avgHL ceiling" disabled (for "normal content" we don't need it)

800/75 is fine. avgHL ceiling won't be needed if by "normal content" you mean higher FALL but never also high avgHL (overall very bright scenes). I don't know The Grinch well enough to say whether such scenes exist, but I'll take your word for it.

Originally Posted by chros

Yes, that's the case for now, but the question is whether this is allright? We agree that having 300 FALL with 600 frame peak is not the same as having it with 1300 frame peak.
That's why I though about CLL, but maybe your 3. point is better for this.

Yeah, I think we need significantly more information than just frame peak and FALL. Because there could easily be two frames with equal peak and FALL and yet one is overall very bright and could use a lower target (ceiling) than FALL (or peak) would otherwise suggest.

Originally Posted by chros

I also think it's 100 nits, the brightness histogram (top right on the OSD) display these as grey (first half of the histogram, 0-63).
And as I said, probably it needs to be some dynamic detection for this, based on the content.

Agreed.

Originally Posted by chros

Good idea, the histogram can help with determining this (instead checking CLL).

What do you mean about stddev? (There's a FALL Stddev on OSD as well, but no one knows what it shows )

Yes, I'm thinking some combination of a different from 100 avgHL value, stddev, percentile, histogram will give us the information we need to determine this far more accurately.

Originally Posted by chros

This has to be dynamic, we don't want to use profiles for this.

The main reason I want this adjustable is to try some different values on different scenes and see what the result is, to use this data as part of figuring out a dynamic formula. Because I can't calculate an avgHL > 200 nits, for example, myself, I need to be able to set it to 200 and see what it spits out.

Originally Posted by chros

Hmm, that's one way, but I'm not sure it would be fruitful.

The reason I suggested this approach is that it doesn't require us to agree on a DTN value, which there seems to be nothing even close to a consensus on amongst users now. It would give us a number of preferred targets for each user across a variety of types of frames, and since the goal is to come up with a new target algo that works for everyone and multiple DPL/DTN combos, we'd be building a formula that already handles this variety. Essentially, it's the relative differences in preferred targets across the different types of frames that we really need to create a formula to handle. Then we could do some sort of regression model to get from the information we have to the preferred targets. It would be really helpful to see if those relative differences are reasonably consistent from user to user even with different settings. I would imagine they would be. Essentially I'm wanting to sort of take a step back, forget how everything works right now, and each of us goes into each frame with nothing but a goal of just finding a specific TM target (in nits) they like best, and then with all that data, we figure out the best way to get there. It may be similar to how it works now, or it may be drastically different. It's like just letting the data guide us. But that being said...

Originally Posted by chros

What about this for now?
- select 1 title/scenes with appropriate frames for testing
- we will check it together
- try to draw the same (!) conclusion (if we won't agree what we should achieve then we don't have to work on this together )

So, I propose (for the 3rd time) The Grinch (2018).
Thoughts?

...I'm certainly willing to participate in a group testing of a single DPL/DTN combo if that's what everyone wants to do. The data will be useful in any case. And The Grinch is fine with me. So what are you going to pick a number of frames from that movie for each of us to test?

[chros]

Originally Posted by aron7awol

The main reason I want this adjustable is to try some different values on different scenes and see what the result is, to use this data as part of figuring out a dynamic formula. Because I can't calculate an avgHL > 200 nits, for example, myself, I need to be able to set it to 200 and see what it spits out.

Agreed in this. Especially if we suppose that the nominal white of normal content today is 203 nits.

Originally Posted by aron7awol

The reason I suggested this approach is that it doesn't require us to agree on a DTN value, which there seems to be nothing even close to a consensus on amongst users now.

I understand and we can use this later, but not now: too many variables mixed with personal preference without having common understanding of our goal, we will fail miserably
I think it's important to go through couple of titles (not just 1) at first with the same settings, to establish the goal. This alone will be complicated enough for now

Originally Posted by aron7awol

It would give us a number of preferred targets for each user across a variety of types of frames, and since the goal is to come up with a new target algo that works for everyone and multiple DPL/DTN combos, we'd be building a formula that already handles this variety. Essentially, it's the relative differences in preferred targets across the different types of frames that we really need to create a formula to handle. Then we could do some sort of regression model to get from the information we have to the preferred targets. It would be really helpful to see if those relative differences are reasonably consistent from user to user even with different settings. I would imagine they would be. Essentially I'm wanting to sort of take a step back, forget how everything works right now, and each of us goes into each frame with nothing but a goal of just finding a specific TM target (in nits) they like best, and then with all that data, we figure out the best way to get there. It may be similar to how it works now, or it may be drastically different. It's like just letting the data guide us. But that being said...

That's a really good idea for the future!

Originally Posted by aron7awol

...I'm certainly willing to participate in a group testing of a single DPL/DTN combo if that's what everyone wants to do. The data will be useful in any case. And The Grinch is fine with me. So what are you going to pick a number of frames from that movie for each of us to test?

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)

[aron7awol]

Originally Posted by chros

I understand and we can use this later, but not now: too many variables mixed with personal preference without having common understanding of our goal, we will fail miserably
I think it's important to go through couple of titles (not just 1) at first with the same settings, to establish the goal. This alone will be complicated enough for now

Please don't just assume it would fail miserably. The personal preference is something I absolutely want to capture in the data, because the end goal is to create something that works for all the different personal preferences. After all, DTN is tunable for a reason, it's just not a one-size-fits-all setting. Some people prioritize a brighter image and some people prioritize depth and detail. There's no right or wrong value/approach. I just want to be clear that what I'm suggesting is that for a given frame, each of us doesn't say what DTN to use for that frame or what ceiling to use for that frame or anything complicated at all, but literally just the target they liked best (say, ~1450 nits for this particular frame, ~2560 nits for that frame, etc.). I think that if everyone did that and I compiled that data, I'd be willing and able to come up with an algo fairly quickly. It's fine though, I should still be able to get some data from your experiment for this purpose.

Originally Posted by chros

- 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

I can't imagine how we can possibly have consensus on this based on the wide range of personal preference and DTNs people run right now, but I'm open-minded, we'll see!

Originally Posted by chros

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

I think this is due to scene detection. Switching profiles while paused causes it to reset, so I think that's what we should do, for consistency. These dynamic changes due to scene detection are a necessary evil in practice, but IMO we shouldn't worry about or account for that in this exercise, it would muddy the waters and throw off the real desired targets.

[aron7awol]

Alright, I did a quick round of testing:



Notes:
1. I calculated avgHL by finding a ceiling that kicked in and dividing the resulting ceiling by the multiplier.
2. DPL/avgHL is intended to show what the ceiling would have to be in order to pull the target down to DPL (disable DTN on that frame essentially)
3. Switching profiles works well to reset scene detection.
4. I probably should have noted peak as well in case it can be helpful. Oh well, next time.
5. It would also be helpful to do this by frame number rather than timestamp so we can use the same exact frames and/or go back to the same frames for further research.
6. Sky algo is also an important aspect of this. Despite it interacting with the frame measurements, I feel like if there is consensus that sky detection is useful, we should leave it on since it is helpful in reducing the measurements in certain scenarios which only helps us here.

[chros]

Originally Posted by aron7awol

I think this is due to scene detection. Switching profiles while paused causes it to reset, so I think that's what we should do, for consistency. These dynamic changes due to scene detection are a necessary evil in practice, but IMO we shouldn't worry about or account for that in this exercise, it would muddy the waters and throw off the real desired targets.

I guess so too, but I think it's important to watch each scene as a whole as well at the end because that's what happening during normal viewing
I know it's another variable in the equation but it's important to understand how the whole thing (can) work in "real life".
E.g. at the end of scene 4 (btw I added scene numbers to the post above) there is unnecessary dimmed image due to how this works.

Originally Posted by aron7awol

1. I calculated avgHL by finding a ceiling that kicked in and dividing the resulting ceiling by the multiplier.
2. DPL/avgHL is intended to show what the ceiling would have to be in order to pull the target down to DPL (disable DTN on that frame essentially)
3. Switching profiles works well to reset scene detection.
4. I probably should have noted peak as well in case it can be helpful. Oh well, next time.
5. It would also be helpful to do this by frame number rather than timestamp so we can use the same exact frames and/or go back to the same frames for further research.

Thanks, looks interesting, especially the avgHL and DPL/avgHL!
We can also take a look at the histogram.
Good idea about frame peak and frame numbers.

One more thing popped into my mind: have you ever used madmeasure.exe? (It only requires the mkv as param, I'm not sure whether it works with BDMV directories.) It will create a ~100MB measurement file of the content, and madshi added tools into the first post that can analyse its content (e.g. by frames), "Simple Analyzer for madMeasureHDR".

Originally Posted by aron7awol

6. Sky algo is also an important aspect of this. Despite it interacting with the frame measurements, I feel like if there is consensus that sky detection is useful, we should leave it on since it is helpful in reducing the measurements in certain scenarios which only helps us here.

Let's forget about the sky algo (and the rest) for now until it's fixed, because it's buggy (meaning unusable), (and I think it's not needed with "normal" titles, but not use).

PS: I only have limited amount of time per day for this, but I'll try to do testing each day and think with you.

[aron7awol]

Originally Posted by chros

I guess so too, but I think it's important to watch each scene as a whole as well at the end because that's what happening during normal viewing
I know it's another variable in the equation but it's important to understand how the whole thing (can) work in "real life".
E.g. at the end of scene 4 (btw I added scene numbers to the post above) there is unnecessary dimmed image due to how this works.

Scene detection is part of normal viewing, but it's important to note that the reason we see this change in target is due to the previous content (and it trying to make smooth changes in TMing rather than abrupt changes), not the current content. So if we make a decision in targeting based on this, we're just changing our target based on previous content, but whether some previous content was significantly brighter or dimmer than the current content is essentially "random", and so it has to be ignored in deciding on an optimal target (in a vacuum) for the current frame. We can only choose the target we want for the current scene, and in practice if madVR smooths out the targets due to scene detection, it is what it is, it may do so in either direction. If we try to change our decision-making based on this "random" smoothing, it will just result in us overshooting or undershooting our targets (adding volatility) in other cases where scene detection does nothing or smooths in the other direction. From a statistical perspective, this is cut and dried.

Originally Posted by chros

Thanks, looks interesting, especially the avgHL and DPL/avgHL!
We can also take a look at the histogram.
Good idea about frame peak and frame numbers.

So this is exactly what I want(ed) to do, compile as much useful data as possible about these frames, and then additional columns for each of us and our preferred target for each of these frames, by each of us doing a manual targeting considering nothing but how the frame looks and what we prefer. It's fine or even preferable if each person has a different DPL for this, it just becomes one more useful piece of data to use for the regression, since we want to make sure it works for all DPLs. Then just try to come up with an algo to arrive as close as possible to those targets using the data only. I threw that last column in there as sort of an example. Let's say someone with DPL 800 preferred targets were close to those in that column, where they didn't want those first two frames to go above 800, liked the high targets on the 3rd and 5th, and wanted a low target on the 4th. Then the current algo works for them with a combo of DTN 75 and 2x ceiling. Or maybe their or someone else's targets are different and the formula can spit out a different combo like DTN 68 and 2.25x ceiling, or whatever. Nothing hardcoded, nothing decided, just preferred targets and a bunch of data and how can that data get us to those targets. Are you seeing the power of this type of approach after seeing those avgHL and DPL/avgHL columns?

Originally Posted by chros

One more thing popped into my mind: have you ever used madmeasure.exe? (It only requires the mkv as param, I'm not sure whether it works with BDMV directories.) It will create a ~100MB measurement file of the content, and madshi added tools into the first post that can analyse its content (e.g. by frames), "Simple Analyzer for madMeasureHDR".

I haven't, but great idea, that seems to be possibly exactly what I want! It will probably save me from having to do so much manual work compiling the data and probably has additional data that I couldn't even get. Thanks!

Originally Posted by chros

Let's forget about the sky algo (and the rest) for now until it's fixed, because it's buggy (meaning unusable), (and I think it's not needed with "normal" titles, but not use).

So I just read that post you linked. I see it modified FALL, as it normally does, even on a frame where peak < DPL. But if it just reduces FALL for targeting purposes, and the resulting target is < DPL, and so then madVR just ends up with a target of DPL anyway, wouldn't that be a "no harm, no foul" situation? I couldn't see from that post if that happened or not, so just speaking hypothetically. Did it actually change the target at the end of the day?

FWIW, I did note the sky algo kicking in on some of those frames in The Grinch, which does happen to have some bright skies.

[chros]

Sky algo: yes, it works like that. But when it does work when it shouldn't, then what's point of ruining the content? That's what I meant about not usable at all. Even if it would work fine, we would need to test which value is harmless (e.g. 100 dynamic clipping is crap, and still you can set it).
So let's just disable it for now, also removing 1 variable So if it was on when you created the table above then it's need to be redone.

Measurement files: let's share these if one of us created them (so the others don't have to).