MadVR in use with LG OLED Thread

[quietvoid]

Another day, another test build. I compared max2 up to max4.
For MMFR, max3 completely removes the hue in flames/lightning, max2 just brightens it slightly.

In my Spider-Man Far from Home sample however, it seems to increase the highlight brightness but the TV doesn't like it and clips slightly around the lightning bolt, not much detail loss though.
I wouldn't use anything above max2 to avoid clipping, but this might just be an issue since we're double tonemapping..

In the saturation test pattern, all above regular max become more saturated somehow.
No idea what that translates to, I can't see differences in normal content.

Anyways, sticking to good ol' max.

[QBhd]

I would rank "harm" (I know terrible choice of words) in order as:
1) Lost detail
2) Dimming of image
3) Changing intent of creator
4) Artifacts
5) Clipping

Passthrough will be heavy in 1&5, too much DTN will be heavy in 2, etc... I am just looking for a balance that has as little of the above as possible

QB

[aron7awol]

I would rank "harm" (I know terrible choice of words) in order as:
1) Lost detail
2) Dimming of image
3) Changing intent of creator
4) Artifacts
5) Clipping

Passthrough will be heavy in 1&5, too much DTN will be heavy in 2, etc... I am just looking for a balance that has as little of the above as possible

Yeah, 1 and 5 go hand in hand. 1000 DPL certainly has some of 1, as does any DPL over the LGs "clipping point" for the given metadata curve.

[quietvoid]

@quietvoid: since you created a HDR10+ parser, do you know a way to remove HDR10+ data from video streams (not DoVi)? (maybe yusesope has it in his tool over makemkv forum, but I never used it). I'm asking because of this (https://forum.doom9.org/showthread.php?p=1919624#post1919624).
Thanks
https://forum.doom9.org/showthread.php?p=1932777#post1932777

[aron7awol]

Re: EOTF tracking and rolloff/clipping points, is there a reason you guys don't upload DeviceControl templates with rolloff point of 100% to stop the TV from TMing and instead tell it to hard clip at peak luminance?

I can't say I've done it myself yet, but it's something I've been considering doing after I measure the actual peak luminance of my display.

[quietvoid]

I think that feature is only available to 2019+ models :D

[aron7awol]

Oh, sorry, I was thrown off because it showed 2017 and 2018 support for DeviceControl, but now I see that was not for the PQ Curve templates. :(

[quietvoid]

Not for the PQ curve upload.

[SamuriHL]

Yea, screw you C9 + owners! :P We'd LOVE that option but it's not available to us. :(

[aron7awol]

So madVR has the feature to detect hard coded black bars, and one of the options when it does is to shift the image to the bottom of the screen. I'm trying to accomplish the same thing but on videos that don't have hard coded black bars. Essentially I want to put both black bars on the top of the screen and slide the image to the bottom. Are you guys aware of any way to get madVR to do this or any player that can do this?

[Asmodian]

In processing -> zoom control there is a setting "always shift the image" that can be set to the top or bottom of the screen. This works even when there are no black bars.

If you actually want to avoid using a portion of your screen entirely, you can set the display type to a projector to access the "screen config" menu and define a visible screen area.

[QBhd]

Okay, so I was motivated to see what the Mehanik Clipping Patterns offered for us. And the results were odd...

So these are the two files that I mainly focused on:

http://qbstorrents.erebus.feralhosting.com/Doom9/madVR.Tonemapping/02.%20White_Color%20clipping.rar

I disabled all the settings that I could in the Pixel Shaders and this was just a straight up DPL experiment.

Now for the oddness...

If I lowered DPL, more of the boxes were visible I even went down to 400 for shits and giggles, but even at 800 more of the 4000 nit file was visible. It was noticeably dimmer, especially when toggling to Passthrough. This seems to make sense... Then I went above 1000 DPL, again even as high as 2000... Instead of less boxes being visible and clipping kicking in, more boxes were again visible. More to the point, the clipping mark was roughly the same at 800 DPL as at 1200 DPL. So I dove deeper, 950 & 1050 both clipped roughly the same with more boxes being visible than 1000. So it seems that if you were to chart the last visible box vs the DPL it would be a "U" shaped chart with 1000 DPL the low point (roughly speaking).

So what does this all mean? Is it even more proof that 1000 DPL on the C8 is optimal? What is causing the clipping to shift UP when DPL goes above 1000? I know the TV's TM'ing will play a roll, but not this much...

Thoughts?

QB

Edit: oops links not doing what I wanted... I will fix now
Edit2: Fixed (I hope, LOL)

[aron7awol]

^^^ Those are the same exact two patterns that I use for this stuff, so I can speak to my observations on them as well.

I believe the reason you are seeing what you are seeing is that once you go >1000 DPL, and in turn >1000 maxCLL, you are seeing the result of the LG TMing changing from its 1000 nit curve to something in between that and its 4000 nit curve. We know on the 2019/2020 models it interpolates between the curves when maxCLL falls in between, and I would assume it does the same on earlier models even though we can't use the templates to modify the curves on those models.

So I don't think it means 1000 DPL is optimal, necessarily. I think you're saying it clips the most at 1000, right? If not losing highlight detail is truly your #1 priority, I'd say something <1000 is "optimal".

But the real issue is we need to be able to modify the metadata in order to not to be a slave to the display's TMing changing with DPL. Without that, 1000 DPL is just what results in the most clipping (and loss of highlight detail).

[aron7awol]

In processing -> zoom control there is a setting "always shift the image" that can be set to the top or bottom of the screen. This works even when there are no black bars.

If you actually want to avoid using a portion of your screen entirely, you can set the display type to a projector to access the "screen config" menu and define a visible screen area.
Thanks. I know I tried that in the past (with the old Kodi DSPlayer only) and it didn't work, and maybe the player was why, so I'll certainly test it again!

Edit: Sure enough, it works in MPC. Thanks!

[QBhd]

As someone with an engineering background, when I see a clear inflection point it means something. And yes, until we are not slaves to DPL linked to metadata I will stick with what the data is trying to show us

Also, there is still less clipping than with Passthrough... And detail can also be retained with DTN (this test was just to find the DPL)

QB

[aron7awol]

As someone with an engineering background, when I see a clear inflection point it means something. And yes, until we are not slaves to DPL linked to metadata I will stick with what the data is trying to show us
It certainly does mean something, it's the point beyond which it starts changing to a totally different curve. You see more and more clipping as you set DPL beyond the display's capabilities, up to 1000 DPL, and then beyond that point the TV starts switching toward the 4000 nit tone curve and clipping is reduced.

If you want the most clipping possible from the TV without being able to override metadata, 1000 DPL gives you that. I was just pointing out that "the most clipping possible" flies in the face of your priority list, with #1 being not losing detail. But if you prefer the way 1000 looks with real content, perhaps your priority list is just not what you thought it was. ;)

Also, there is still less clipping than with Passthrough...
Yes, this is true, but there is still more clipping with 1000 DPL than a lower DPL in your testing, right?

And detail can also be retained with DTN (this test was just to find the DPL)
More detail can be retained with DTN, yes. And yet, still, if you compare 1000 DPL and a lower DPL with the same target, you will still find there is even more detail (due to less/no clipping) with the lower DPL. This will always be the case, because if DPL is set to something exceeding the actual peak nits of the display, madVR will send pixels that exceed and will be clipped by the display.

Again, I'm not trying to tell you what you prefer and what you don't prefer, just pointing out differences. If you prefer the overall compromise of 1000 DPL best, with its balance of some clipping and overall picture brightness, I can totally relate. I really like the way it looks as well.

[QBhd]

You're preaching to the choir. More detail (i.e. less clipping with this particular test) can be attained in two ways. Lowering peak brightness or increasing peak brightness... All I am saying is the balance lies in the middle and this test is very easy to find that DPL +/- 50 nits. 1000 is a nice round number which makes some sense all by itself... And the flashing box at 860 (on the pattern) is so incredibly faint for both 1050 & 950 (DPL) that narrowing it down further would be difficult.

QB

[aron7awol]

You're preaching to the choir. More detail (i.e. less clipping with this particular test) can be attained in two ways. Lowering peak brightness or increasing peak brightness... All I am saying is the balance lies in the middle and this test is very easy to find that DPL +/- 50 nits. 1000 is a nice round number which makes some sense all by itself... And the flashing box at 860 (on the pattern) is so incredibly faint for both 1050 & 950 (DPL) that narrowing it down further would be difficult.
I'm just not sure what you are actually trying to balance or narrow down between 1050 and 950?

If you're trying to find the point with the most clipping, that's 1000. But I thought you didn't want to clip and lose detail, which is why I find it strange that you're honing in on the point that clips the most. And really, there's nothing to hone in on anyway, we know that's 1000.

[chros]

OFF:
https://forum.doom9.org/showthread.php?p=1932777#post1932777
Thank You! It works like a charm! :) (You see there are people who don't understand what the problem is / you want to achieve and just complaining non-stop :))
What popped into my mind is - if you will have time / in the mood -:
- you could incorporate this into the hdr10+ parser project
-- by setting a flag that allows stripping the metadata while making a backup of it in one go
-- allowing to rewrite the original hdr10+ file with the saved metadata

ON:
And all this because bloody LG's magenta/cyan issue with HDR10 content!!! :D It just drives me nuts, right @jk82?! :D

Btw, @aron7awol, would you mind testing the cyan/magenta issue (https://forum.doom9.org/showthread.php?p=1925528#post1925528) on your CX as well? But beware, once you've seen this (if it exists), you won't be able to unsee it anymore! :D Thanks

[chros]

Are you guys aware of any way to get madVR to do this or any player that can do this?
What do you need this for?

see what the Mehanik Clipping Patterns offered for us. And the results were odd...

Now for the oddness...

Thoughts?

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.

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

[aron7awol]

Btw, @aron7awol, would you mind testing the cyan/magenta issue (https://forum.doom9.org/showthread.php?p=1925528#post1925528) on your CX as well? But beware, once you've seen this (if it exists), you won't be able to unsee it anymore! :D 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]

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

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!

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.

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

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.
:D I bet your curiosity will win in the end :) (It's enough to check The Witcher sample against its DV version on Netfilx.)

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.

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?

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]

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]

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 (https://docs.google.com/spreadsheets/d/1IupvatPOHJxpzEiH_8JqHO5QJkKBRNhEUUpt3m0_hNI/edit?usp=sharing) 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]

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]

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]

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:

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

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

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]

Fall values also can be exponential, yes
But I created those only up until 400 because we want to test "normal" content first, right?

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)

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.

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.

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

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

but having the 100 nits "highlight" definition adjustable might help.
This has to be dynamic, we don't want to use profiles for this.

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]

But I created those only up until 400 because we want to test "normal" content first, right?
Sure, anything is fine with me.


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

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

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.

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.

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.

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.

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

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]

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.

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

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!

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

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.


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


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:

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

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]

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.


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 (https://forum.doom9.org/showthread.php?t=146228) into the first post that can analyse its content (e.g. by frames), "Simple Analyzer for madMeasureHDR".

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

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.

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?

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 (https://forum.doom9.org/showthread.php?t=146228) 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! :)


Let's forget about the sky algo (and the rest) for now until it's fixed, because it's buggy (https://www.avsforum.com/threads/improving-madvr-hdr-to-sdr-mapping-for-projector.2954506/post-60341772) (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).

[aron7awol]

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.
So what does it do in that scenario, result in a target < DPL?

[chros]

That's correct, resulting in target of DPL. So from the target view it is not an issue, but in reality it modifies the content, e. g. removes fine datails from it even if it's not needed.

[aron7awol]

That's correct, resulting in target of DPL. So from the target view it is not an issue, but in reality it modifies the content, e. g. removes fine datails from it even if it's not needed.
Are you sure it actually modifies the content? I thought it just modified the FALL used for the DTN algo calculation for targeting purposes, but didn't actually modify anything. Is the end result on-screen any different in that scenario?

Now in the dynamic clipping scenario, if it's actually modifying the content before it determines whether that's even necessary, I agree, that's a bug to me.

[chros]

Both are the same :)
Sky algo works based on histogram and yes it modifies the content (same as dynamic clipping) , that's why you have less FALL with it. How much it is visible, good question, depending on its values and content. There was a pj user who stated anything above 5 (strength) is harmful :)

[aron7awol]

Both are the same :)
Sky algo works based on histogram and yes it modifies the content (same as dynamic clipping) , that's why you have less FALL with it. How much it is visible, good question, depending on its values and content. There was a pj user who stated anything above 5 (strength) is harmful :)
Just because the FALL reported on the OSD by madVR is lower (which is the FALL it is using for target calculation) doesn't mean that it actually modified the content. In fact, can you imagine how much of an impact it would have to have on the image in order to actually reduce FALL that much! It would have to dim the sky like crazy. So I'm almost 100% sure that it just ignores the "sky" as part of calculating FALL, which is only used for target calculation. So there's no bug, it has no negative impact if it does that even on a frame with peak < DPL, because the target just ends up as DPL anyway.

So really, if I understand the way it works correctly, it can't modify the image itself, the only effect it can ever have is to potentially change the target (but never below DPL, of course), which is the point of it, anyway. It's an additional intelligence, doing something similar to what the avgHL ceiling is trying to accomplish. I think some thought it would make the ceiling redundant, but I think that both have their place based on my testing.

Which user said a strength of 5 was harmful? I'm interested in reading about their experiences. Are you sure they weren't talking about dynamic clipping?

Edit: Just tested this. It definitely only affects the reported FALL and resulting target. I was able to compare the same frame on two different profiles with the same target and one with a drastically lower reported FALL than the other, but the two images were identical.

[chros]

I'm sure, here (https://www.avsforum.com/threads/improving-madvr-hdr-to-sdr-mapping-for-projector.2954506/post-59183342) it is. Doesn't the histogram changes by it?
Can you ask madshi about this just in case?

[aron7awol]

I see no change in the histogram. Reported FALL dropped from 223 down to 151 but image is identical. I'd like to think I could notice that much of a FALL difference. :)

I don't know if that guy was confusing effects of HSTM with sky or just seeing a target difference or what, but what he reported doesn't make any sense to me based on what I've seen and what I read previously about the sky algo.

[quietvoid]

I'm pretty sure the sky detection is just to avoid dimming scenes that contain a "sky", where it wouldn't improve the resolved highlights in the picture by tonemapping at a higher target.
It's not supposed to change the image.

[aron7awol]

Yeah, and I've been running it on 100 strength for a while now and I've never seen it cause a single issue, possibly because we're pretty much immune to it causing any potential issues because our targets just can't go all that low due to high DPL.

I think it's similar to what the guys in the AVS thread are seeing with grain right now. That's only an issue at low DPLs because the curve can end up rolling through the area where that grain falls, but for us, we're pretty much always 1:1 mapping down in that area.

[aron7awol]

As for dynamic clipping, I agree, we don't want it working when peak < DPL, but I wonder if the logic of having it on always is that if we're toeing the line of DPL, we don't want it turning on and off within the same scene. But of course that situation could be dealt with with some additional intelligence of seeing if we're near DPL, leveraging the scene detection algo to smooth the transition, etc. My guess is madshi just didn't see all that as worth the effort and left it on always, but it would be nice for the user to be able to decide if they want it disabled when peak < DPL instead in the meantime and accept the risk of it potentially pumping on and off in that edge case.