Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 14th January 2021, 18:03   #1461  |  Link
chros
Registered User
 
chros's Avatar
 
Join Date: Mar 2002
Posts: 2,038
I also use these modes on my B8, but the gamut option is (!) available in ISF Dark/Bright SDR modes, so I set it to Wide.

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

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

So it seems it actually works exactly as we want it to, where it only clips as much as needed to bring the frame peak down to DPL, but no more, and so if peak < DPL, not at all.
Indeed!!! Thanks for this test!
I just tested the MMFR sample (keyframe at 00:19 sec, frame peak 6344 without clipping), lum max to see the blue patches.
I tried various DPLs 800/2000/4000 and set the clipping according to them: e.g. at 4000 DPL, 40 DC results in 3954 nits. If I use higher DC e.g. 100 no difference in the patches, if I go lower e.g. 39 there is difference (slight) straight away.
So this one isn't a bug either

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

Quote:
Originally Posted by chros View Post
(Btw, I used 700/60 because I switched off sky algo (=0).)
This one kept me thinking: are you sure that the sky algo is useful for us? (try it with The Meg (TM) sample)
Let's take these two profiles (DPL/DTN/SS):
- p1: 800/60/0
- p2: 800/85/100

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

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

What do you think?

Quote:
Originally Posted by aron7awol View Post
Maybe the 100 10 20 20 that Neo-XP uses? I know he's done extensive testing with it, and if that's not harmful for his lower nits I'm certain it won't be for us!
I agree (if we decide it's useful for us) but that means he changed it in the last 2 months
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v398.18),Win10 LTSC 1809,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED65B8(2160p@23/24/25/29/30/50/59/60Hz) | madvr config

Last edited by chros; 15th January 2021 at 11:46.
chros is offline   Reply With Quote
Old 14th January 2021, 18:39   #1462  |  Link
VBB
Registered User
 
VBB's Avatar
 
Join Date: May 2016
Location: Long Beach, CA, USA
Posts: 560
@oldpainlesskodi - My C7 is locked to "Wide" in PC mode.
__________________
Henry

LG OLED65C7P | Denon AVR-X3500H | ELAC Uni-Fi x7 | ELAC Debut 2.0 SUB3030 x2
NVIDIA GeForce GTX 960 | LAV Filters | madVR | MPC-HC | Plex | X-Rite i1Display Pro | DisplayCAL | HCFR
VBB is offline   Reply With Quote
Old 14th January 2021, 19:03   #1463  |  Link
oldpainlesskodi
Registered User
 
Join Date: Apr 2017
Posts: 339
Thanks VBB - not just mine then. So, begs the question if auto in non-pc mode is the correct option then...
__________________
Sapphire RX 5700 XT (21.2.2) Ryzen 7 3700x, PRIME X570-Pro, Win 10 x64 (2004), Silverstone LC13B-E, Onkyo TX-RZ800, LG OLED55BX6LB, Mission M35i speakers, Kodi Dsplayer 17.6 X64
oldpainlesskodi is offline   Reply With Quote
Old 14th January 2021, 19:09   #1464  |  Link
chros
Registered User
 
chros's Avatar
 
Join Date: Mar 2002
Posts: 2,038
Quote:
Originally Posted by aron7awol View Post
Sure, but I should probably do The Grinch rather than the random short episode I did just as a test
Here it is (I just used the biggest m2ts file), madmeasure.exe stats:
Code:
Metadata:
  Mastering display luminance: 0.0001/1000, gamut: 0.68 0.32, 0.15 0.06, 0.265 0.69, 0.3127 0.329
  MaxCLL: 1000, MaxFALL: 407 nits
Measurements:
  Frames: 123455, MaxCLL 100%: 3916, 99.9%: 1195, MaxFALL: 884, AvgFALL: 100, AvgFMLL: 791 nits
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v398.18),Win10 LTSC 1809,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED65B8(2160p@23/24/25/29/30/50/59/60Hz) | madvr config
chros is offline   Reply With Quote
Old 14th January 2021, 19:18   #1465  |  Link
VBB
Registered User
 
VBB's Avatar
 
Join Date: May 2016
Location: Long Beach, CA, USA
Posts: 560
Quote:
Originally Posted by oldpainlesskodi View Post
Thanks VBB - not just mine then. So, begs the question if auto in non-pc mode is the correct option then...
Depends on what you mean by correct. Auto in non-PC mode maps to BT.709, while Wide in PC mode maps to the panel's native gamut, which is close to DCI-P3. Whatever you set the TV to, just make sure to match that in madVR. The same goes for gamma.
__________________
Henry

LG OLED65C7P | Denon AVR-X3500H | ELAC Uni-Fi x7 | ELAC Debut 2.0 SUB3030 x2
NVIDIA GeForce GTX 960 | LAV Filters | madVR | MPC-HC | Plex | X-Rite i1Display Pro | DisplayCAL | HCFR
VBB is offline   Reply With Quote
Old 14th January 2021, 19:41   #1466  |  Link
oldpainlesskodi
Registered User
 
Join Date: Apr 2017
Posts: 339
Yeah, that was kinda my point - surely in PC mode the panel should be in monitor mode and display what it thinks is being sent? After all, what is PC mode supposed to do......just curious why it maps to wide color gamut I guess.
__________________
Sapphire RX 5700 XT (21.2.2) Ryzen 7 3700x, PRIME X570-Pro, Win 10 x64 (2004), Silverstone LC13B-E, Onkyo TX-RZ800, LG OLED55BX6LB, Mission M35i speakers, Kodi Dsplayer 17.6 X64
oldpainlesskodi is offline   Reply With Quote
Old 14th January 2021, 19:50   #1467  |  Link
VBB
Registered User
 
VBB's Avatar
 
Join Date: May 2016
Location: Long Beach, CA, USA
Posts: 560
I don't know why LG think it's a good idea to lock anything.
__________________
Henry

LG OLED65C7P | Denon AVR-X3500H | ELAC Uni-Fi x7 | ELAC Debut 2.0 SUB3030 x2
NVIDIA GeForce GTX 960 | LAV Filters | madVR | MPC-HC | Plex | X-Rite i1Display Pro | DisplayCAL | HCFR
VBB is offline   Reply With Quote
Old 14th January 2021, 20:03   #1468  |  Link
aron7awol
Registered User
 
Join Date: Dec 2020
Posts: 94
Quote:
Originally Posted by chros View Post
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.

Quote:
Originally Posted by chros View Post
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!

Quote:
Originally Posted by chros View Post
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?

Quote:
Originally Posted by chros View Post
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.

Quote:
Originally Posted by chros View Post
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.

Last edited by aron7awol; 14th January 2021 at 20:51.
aron7awol is offline   Reply With Quote
Old 14th January 2021, 20:29   #1469  |  Link
oldpainlesskodi
Registered User
 
Join Date: Apr 2017
Posts: 339
@VBB - agreed. Oh well, more testing lol.
__________________
Sapphire RX 5700 XT (21.2.2) Ryzen 7 3700x, PRIME X570-Pro, Win 10 x64 (2004), Silverstone LC13B-E, Onkyo TX-RZ800, LG OLED55BX6LB, Mission M35i speakers, Kodi Dsplayer 17.6 X64
oldpainlesskodi is offline   Reply With Quote
Old 15th January 2021, 11:49   #1470  |  Link
chros
Registered User
 
chros's Avatar
 
Join Date: Mar 2002
Posts: 2,038
Quote:
Originally Posted by aron7awol View Post
So, my quick answer off-the-cuff is that I think this ends up as just a display thing in the OSD, similar to how FALL changes from sky detection in the OSD even when nothing actually changes. But I want to think about this a little more to be sure.
Ok, thanks. But you can't come up any reasonable explanation for it either then let's report it madshi, because for me it doesn't make any sense.

Quote:
Originally Posted by aron7awol View Post
I know you mean DTN, not DPL, in that last sentence.
Yes, sorry, corrected, thanks.

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

Quote:
Originally Posted by aron7awol View Post
I think he mentioned he changed it after switching to "don't add peak nits", for what that's worth.
OK, can be, I don't remember.
So when we use it, let's use: 100/10/20/20

Quote:
Originally Posted by aron7awol View Post
And just for the record, I'm not sure I even want to use dynamic clipping yet at the end of the day, I just wanted to test it to see if I liked what it did, and at least it seems to work as intended and so we can evaluate potentially using it.
...
(sky detection) I am certainly not sure!
Quote:
Originally Posted by aron7awol View Post
So kind of as I refer to above, maybe we should compare the same DTN with/without sky detection first
Agreed: so what shall we do with these 2 during our initial testing?
I vote for:
- let's disable them (I don't think they are needed for "normal" content at all)
- we can play with them after that with the well known scenes

How does it sound?
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v398.18),Win10 LTSC 1809,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED65B8(2160p@23/24/25/29/30/50/59/60Hz) | madvr config

Last edited by chros; 15th January 2021 at 11:56.
chros is offline   Reply With Quote
Old 15th January 2021, 17:10   #1471  |  Link
aron7awol
Registered User
 
Join Date: Dec 2020
Posts: 94
Quote:
Originally Posted by chros View Post
Ok, thanks. But you can't come up any reasonable explanation for it either then let's report it madshi, because for me it doesn't make any sense.
I'm just trying to think about if it actually matters. What is that frame peak value used for? Smoothing algo and as a ceiling for TMing, anything else? Which value is better to use for smoothing, the original peak or the after-DC peak?

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

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

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

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

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

Last edited by aron7awol; 15th January 2021 at 18:03.
aron7awol is offline   Reply With Quote
Old 15th January 2021, 18:21   #1472  |  Link
QBhd
QB the Slayer
 
QBhd's Avatar
 
Join Date: Feb 2011
Location: Toronto
Posts: 651
I have no idea what you two are trying to accomplish! Were have a boat load of settings and they all do different things. It's all well and good to have an understanding of what the settings do and why they are there. But there will be no perfect combination.

QB
__________________
QBhd is online now   Reply With Quote
Old 15th January 2021, 20:16   #1473  |  Link
aron7awol
Registered User
 
Join Date: Dec 2020
Posts: 94
Quote:
Originally Posted by QBhd View Post
I have no idea what you two are trying to accomplish! Were have a boat load of settings and they all do different things. It's all well and good to have an understanding of what the settings do and why they are there. But there will be no perfect combination.
I feel like it should be possible to make an algo that gets very close to hitting our ideal target on a particular frame, if we just figure out what exactly drives our preference on each "type" of frame. I would expect whatever it is that makes us choose one target over another will be there in the data if we just look for it. But first we need to know what target we actually want.

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

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

Last edited by aron7awol; 15th January 2021 at 20:26.
aron7awol is offline   Reply With Quote
Old 15th January 2021, 20:29   #1474  |  Link
chros
Registered User
 
chros's Avatar
 
Join Date: Mar 2002
Posts: 2,038
Quote:
Originally Posted by QBhd View Post
But there will be no perfect combination.
And that's the issue, see above.
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v398.18),Win10 LTSC 1809,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED65B8(2160p@23/24/25/29/30/50/59/60Hz) | madvr config
chros is offline   Reply With Quote
Old 15th January 2021, 20:48   #1475  |  Link
QBhd
QB the Slayer
 
QBhd's Avatar
 
Join Date: Feb 2011
Location: Toronto
Posts: 651
So you are going to do this for ONE frame? What about the trillions of trillions of other frames?

QB
__________________
QBhd is online now   Reply With Quote
Old 15th January 2021, 21:03   #1476  |  Link
aron7awol
Registered User
 
Join Date: Dec 2020
Posts: 94
Quote:
Originally Posted by QBhd View Post
So you are going to do this for ONE frame? What about the trillions of trillions of other frames?
No, of course not! But we don't need trillions of frames either. We just need a small subset that hopefully covers the different types of frames (only those that are bright enough to need target > DPL) that require different targeting. This is no different from when we normally test and hone in on a particular DTN that we use other than we aren't a slave to the algo, we just need to make a note of the preferred target (nits, not DTN value) for each frame we evaluate. Really, it's just the exceptions that the current algo doesn't target so well that we really need to know about.

Last edited by aron7awol; 15th January 2021 at 22:50.
aron7awol is offline   Reply With Quote
Old 16th January 2021, 01:54   #1477  |  Link
aron7awol
Registered User
 
Join Date: Dec 2020
Posts: 94
Haha @chros, I think I found a bug when both sky detection and dynamic clipping are enabled at the same time! Pretty funny. So you were kind of right about the suspected bugs, you just needed to use both together to manifest it!

Last edited by aron7awol; 16th January 2021 at 01:58.
aron7awol is offline   Reply With Quote
Old 16th January 2021, 09:35   #1478  |  Link
chros
Registered User
 
chros's Avatar
 
Join Date: Mar 2002
Posts: 2,038
I noticed something similar with sky strength at 199 (!) without DC, and I thought this value was 0-100
__________________
Ryzen 5 2600,Asus Prime b450-Plus,16GB,MSI GTX 1060 Gaming X 6GB(v398.18),Win10 LTSC 1809,MPC-BEx64+LAV+MadVR,Yamaha RX-A870,LG OLED65B8(2160p@23/24/25/29/30/50/59/60Hz) | madvr config
chros is offline   Reply With Quote
Old 19th January 2021, 16:09   #1479  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Posts: 206
@aron7awol I've gone looking through the avs thread again.
Here's the latest Excel version of the measurement files parser: https://www.avsforum.com/threads/imp...#post-57108412

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

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

Last edited by quietvoid; 19th January 2021 at 16:12.
quietvoid is offline   Reply With Quote
Old 19th January 2021, 17:36   #1480  |  Link
aron7awol
Registered User
 
Join Date: Dec 2020
Posts: 94
Thank you!
aron7awol is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:32.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.