AVS Forum banner

821 - 840 of 1220 Posts

·
Registered
Joined
·
1,479 Posts
Discussion Starter #821 (Edited)
Arrival from 1:01:50 to 1:02:30 has several visible brightness adjustments - at least for me. This is exhibited by both the recent live algo and also from my tweaked measurement file playback for this title. Curious if this could be from the way the Fall algo treats this material and not just scene change detection at play? Hoping @Soulnight might review?

EDIT: Might just be a scene change issue. I will retest later so maybe wait if not that interesting.
I am 99% sure that the Fall algo has nothing to do with it.

Probably a scene change issue.

2 evils possible:

Option 1:
the target nits gets resetted at scene change at a bad time.
Typically:
You can get a visible brightness jump between 2 people discussing with camera change but the viewer sees it as "one single scene".
- LIVE algo current implementation always reset at each scene cut and will definitely display a lot of the associated issues
- Our tool behaviour depends on the settings used. Default settings try to avoid this kind of unwanted reset.

Option 2:
Huge change in brightness and scene cut not detected.
- Our tool may try to smooth this out with the rolling avg which can result in pumping.
- Live algo will be either too dark or overblown if big scene is missed.

So the default settings in our tool try to avoid both bad options.

Can you share the settings you are using?
And also maybe share a video sample to look at the issue?
 

·
Registered
Joined
·
466 Posts
@Soulnight - So I tested the Arrival scenes again and the scenes match your option 1 evil - two people discussing. This movie seems to have more issues than any of my others I have watched - especially the last 30 to 40 minutes. As example at 1:02:21 ish there is a cut to one actor and it noticeably rolls darker. Then at 1:02:26 ish there is a cut back to the other actor and it noticeably rolls lighter. This is part of a conversation around the time of "I'm curious" dialog. The brightness adjustments are at a scene cut between the actors both times that I assume is missed. Here are the settings used in case you can point out a possible tweak to improve - thanks.

Selected target nits calculation method: FALL-Algo
Selected static target nits: 269
Real display peak nits: 90

Dynamic target nits: Yes
Minimal target nits: 90
Maximum Target Nits: 2500
Time for rolling avg in frames: 200
Dynamic Target Nits Tuning [50-100]: 125
Merge scenes [FALL change in %]: 100
Minimal chapter duration in frames: 100
Merge chapters [avgFALL change in %]: 50
No compression limit [nits]: 150
Fix for very small and bright spots [%]: 5
Number of identified chapters: 425
----------------------------------------------
Dynamic clipping
Dynamic range recovery strength in %: 100
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #825
What madVR build is recommended to use with latest flo and Anna tool?
One of the latest betas? Or a public release?
MadVR Beta V40.

Any newer beta "should" work without any issue either as long as the "measurement file" is not checked as "ignored" in madVR settings.
;)
 

·
Registered
Joined
·
694 Posts
MadVR Beta V40.

Any newer beta "should" work without any issue either a slong as the "measurement file" is not checked as "ignored" in madVR settings.
;)
I asked this in another thread but figured this is probably the better one to ask it in (though you may be biased!)---

I know madshi is working on real time dynamic mapping by looking ahead a few frames, which markmon and others have said will obviate the need for measurements. But won't pre-measuring the entire file always give the best results, at the very least by offloading some of the real-time processing work that would have to be done otherwise? Am I missing something?
 

·
Registered
Joined
·
473 Posts
What madVR build is recommended to use with latest flo and Anna tool?
One of the latest betas? Or a public release?
MadVR Beta V40.

Any newer beta "should" work without any issue either a slong as the "measurement file" is not checked as "ignored" in madVR settings.
/forum/images/smilies/wink.gif
Should dynamic clipping be ticked in madVR, or is that only used when NOT using the Measuring files, i.e. the live algo?
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #829 (Edited)
I asked this in another thread but figured this is probably the better one to ask it in (though you may be biased!)---

I know madshi is working on real time dynamic mapping by looking ahead a few frames, which markmon and others have said will obviate the need for measurements. But won't pre-measuring the entire file always give the best results, at the very least by offloading some of the real-time processing work that would have to be done otherwise? Am I missing something?
Well honestly, without being biased :D , it's pretty obvious that *in theory" you should be able to have much better results than ANY version of the LIVE algo IF you know all the frames in advance.

Now, having said that, it of course depends on how good in the LIVE algo and how good is the "Measurement file based" algo.
But, if both are given the same developement effort, "measurement file based" will always beat by quite a margin the LIVE algo.

So for the *maybe* biased part:
the current philosophy of the "Dynamic target" live algo is to use the "FALL algo" and then reset the target nits for each new detected scene.
This means that if 2 people are talking to each other in the same room, and the camera keeps switching every 2s between the two, the target nits will get reseted at each camera change. IF the FALL is very different between the 2 camera perspective, then you will observe large target nits change at each camera change.
--> This might be disturbing since while in the same "conversation" the brightness will change up and down

Ideally, you would like for such "conversation between 2 people" to be handled as one single scene, so that you don't have strange brightness jump between the same "chapter".
--> This is where the "measurement file" has a huge advantage: you can basically detect such situation by looking ahead.

-->In our tool working with the measuement file, we "try" to only reset the target nits only large "chapter" change (large FALL change). "Chapter merge" is here for that.

We also made an improvement in the V3.7.2 (not released to you guys yet :D ), where we basically handle "sandwich scene" to help with this kind of situation where the camera switch back and forth, but you actually want to keep the same target so that the brightness does not change too much.

Also while in a "SCENE", the live algo is able to change the target nits based on a predefined speed scaled to the current delta to the desired frame peak. But Live algo does not known the future.
With the measurement file, we currently use a centered rolling avg so that we can better prepare for the future with a smoth transition to the future required target nits. :)

So while I am very happy that the LIVE algo now included the dynamic target nits, and while the LIVE algo may please most people and avoid the 'hassle" of generating measurement file, the "measurement file" will still be beneficial to be "smarter" about the "when" do you reset the target nits so that the relative change between "friend scenes" is still respected.

Also, we should not forget that Madshi first purpose of the measurement file was to know in advance the frame peak so that you would never tone map to a peak smaller than the current frame peak which would result in indesired clipping. The live algo may lead to uncontrolled clipping because of the "fixed" moving speed. With the measurement file, it's always "perfect", because it can react in advance (it knows the future) and raise the tone mapping peak target progressively so that when it does reach the frame with the highest peak, it still does not clip. :cool:

And finally, you can probably do much more than what we are doing at the moment with the measurement file to make it even better. ;)

Edit: and yes you are right at the very least you can unload your gpu and save some precious ms if you use the already pre-analysed and post-processed measurement file.
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #830
Should dynamic clipping be ticked in madVR, or is that only used when NOT using the Measuring files, i.e. the live algo?
No, you can untick it. WE do it directly with the tool in the measurement file.
(I think it's not active anyway if measurement file are active, but would need confirmation).
 

·
Registered
Joined
·
694 Posts
I asked this in another thread but figured this is probably the better one to ask it in (though you may be biased!)---

I know madshi is working on real time dynamic mapping by looking ahead a few frames, which markmon and others have said will obviate the need for measurements. But won't pre-measuring the entire file always give the best results, at the very least by offloading some of the real-time processing work that would have to be done otherwise? Am I missing something?
Well honestly, without being biased /forum/images/smilies/biggrin.gif , it's pretty obvious that *in theory" you should be able to have much better results than ANY version of the LIVE algo IF you know all the frames in advance.

Now, having said that, it of course depends on how good in the LIVE algo and how good is the "Measurement file based" algo.
But, if both are given the same developement effort, "measurement file based" will always beat by quite a margin the LIVE algo.

So for the *maybe* biased part:
the current philosophy of the "Dynamic target" live algo is to use the "FALL algo" and then reset the target nits for each new detected scene.
This means that if 2 people are talking to each other in the same room, and the camera keeps switching every 2s between the two, the target nits will get reseted at each camera change. IF the FALL is very different between the 2 camera perspective, then you will observe large target nits change at each camera change.
--> This might be disturbing since while in the same "conversation" the brightness will change up and down

Ideally, you would like for such "conversation between 2 people" to be handled as one single scene, so that you don't have strange brightness jump between the same "chapter".
--> This is where the "measurement file" has a huge advantage: you can basically detect such situation by looking ahead.

-->In our tool working with the measuement file, we "try" to only reset the target nits only large "chapter" change (large FALL change). "Chapter merge" is here for that.

We also made an improvement in the V3.7.2 (not released to you guys yet /forum/images/smilies/biggrin.gif ), where we basically handle "sandwich scene" to help with this kind of situation where the camera switch back and forth, but you actually want to keep the same target so that the brightness does not change too much.

Also while in a "SCENE", the live algo is able to change the target nits based on a predefined speed scaled to the current delta to the desired frame peak. But Live algo does not known the future.
With the measurement file, we currently use a centered rolling avg so that we can better prepare for the future with a smoth transition to the future required target nits. /forum/images/smilies/smile.gif

So while I am very happy that the LIVE algo now included the dynamic target nits, and while the LIVE algo may please most people and avoid the 'hassle" of generating measurement file, the "measurement file" will still be beneficial to be "smarter" about the "when" do you reset the target nits so that the relative change between "friend scenes" is still respected.

Also, we should not forget that Madshi first purpose of the measurement file was to know in advance the frame peak so that you would never tone map to a peak smaller than the current frame peak which would result in indesired clipping. The live algo may lead to uncontrolled clipping because of the "fixed" moving speed. With the measurement file, it's always "perfect", because it can react in advance (it knows the future) and raise the tone mapping peak target progressively so that when it does reach the frame with the highest peak, it still does not clip. /forum/images/smilies/cool.gif

And finally, you can probably do much more than what we are doing at the moment with the measurement file to make it even better. /forum/images/smilies/wink.gif

Edit: and yes you are right at the very least you can unload your gpu and save some precious ms if you use the already pre-analysed and post-processed measurement file.
Fantastic explanation. Thank you. I cannot see why I wouldn't pre-measure all of my UHD content. Looking forward to the next release!
 

·
Registered
Joined
·
975 Posts
Related question to the mapping, I was trying to get some quick measurements as I break in a new bulb to set up my tone mapping. I did a 100 IRE pattern to get peak nits, I used the built in hcfr pattern with a small square in the middle of a black screen, would this be a valid way of getting peak nits for inputting into the actual nits field? Or should I do a full white screen or something different?
 

·
Registered
Joined
·
473 Posts
Should dynamic clipping be ticked in madVR, or is that only used when NOT using the Measuring files, i.e. the live algo?
No, you can untick it. WE do it directly with the tool in the measurement file.
(I think it's not active anyway if measurement file are active, but would need confirmation).
Thanks!
 

·
Registered
Joined
·
122 Posts
Hi Soulnight,

Is the default settings good enough for high peak displays? Let's say that my real display peak nits is 740 what do you suggest for no compression limit and dynamic tuning settings.

Thanks
 

·
Registered
Joined
·
975 Posts
Question for someone just starting out tuning this stuff. I am currently using a dynamic tuning value of 100 as a mid point and trying to get a starting point to tweak.

My question for you guys with lots of experience with tone mapping would be how much diminishing returns are there on the nits when using the mapping. I have 3 choices for my settings ,

High lamp with color filter 156 nits,98% p3 coverage
Low lamp no filter 136 nits, high 80s p3 coverage
Low lamp with filter 113 nits , 98% p3 coverage

I am doing low lamp with filter right now but trying to decide if the extra coverage is worth the loss in brightness or if the extra noise in high lamp would be worth the extra nits. I tried doing a/b testing but it's hard with how long the sync takes and this my first viewing of hdr so I have no reference point.

I am currently using no dynamic clipping and a no compression of 150 with a minimum real nits of 105 (bulb is new I expect it to drop quick from the 113).

Any advice would be appreciated , I am trying to watch a movie this weekend and would like some starter settings :)
 

·
Registered
Joined
·
466 Posts
... trying to decide if the extra coverage is worth the loss in brightness or if the extra noise in high lamp would be worth the extra nits. I tried doing a/b testing but it's hard with how long the sync takes and this my first viewing of hdr so I have no reference point.

I am currently using no dynamic clipping and a no compression of 150 with a minimum real nits of 105 (bulb is new I expect it to drop quick from the 113).

Any advice would be appreciated , I am trying to watch a movie this weekend and would like some starter settings :)
For me the thing that makes HDR tough for projectors is low nits. So I favor more nits over color coverage when keeping HDR and using a custom Arve curve. With tone mapping I still prefer it to look as "HDR like" as possible and that means I also favor more nits over color coverage to give me the highest dynamic range I can squeeze out of it. Personal tastes might differ however and I know some like to watch tone mapped on low lamp closer to their regular SDR experience and want the WCG. I guess I got used to the High Lamp for actual HDR and so I have kept that even now that I am tone mapping for my HDR content and watching in SDR BT2020 (but without the filter). I am sure someone will disagree but that's just what I am doing.
 

·
Registered
Joined
·
975 Posts
For me the thing that makes HDR tough for projectors is low nits. So I favor more nits over color coverage when keeping HDR and using a custom Arve curve. With tone mapping I still prefer it to look as "HDR like" as possible and that means I also favor more nits over color coverage to give me the highest dynamic range I can squeeze out of it. Personal tastes might differ however and I know some like to watch tone mapped on low lamp closer to their regular SDR experience and want the WCG. I guess I got used to the High Lamp for actual HDR and so I have kept that even now that I am tone mapping for my HDR content and watching in SDR BT2020 (but without the filter). I am sure someone will disagree but that's just what I am doing.
Thanks, I ran the 113 nits this weekend and it looked great, but still trying to decide what to do. Trying to do comparisons is tough though, I also wonder how many movies take advantage of full P3 colorspace.
 

·
Registered
Joined
·
466 Posts
I have one movie in my collection that the measurement does not complete. I have tried the measure with D3D11 as normal and also DXVA2 native to see if that might allow it to complete but same result. It takes the full time and appears to be processing up until it finishes with the incomplete file. The movie file itself seems fine - I can play it and navigate around no problem. Anyone else have a measurement issues like this with a specifc title? Any place to review for possible error messages or a reason? The title is "Keeping up with the Jonses".

Thanks
 

·
Premium Member
Joined
·
9,882 Posts
I have one movie in my collection that the measurement does not complete. I have tried the measure with D3D11 as normal and also DXVA2 native to see if that might allow it to complete but same result. It takes the full time and appears to be processing up until it finishes with the incomplete file. The movie file itself seems fine - I can play it and navigate around no problem. Anyone else have a measurement issues like this with a specifc title? Any place to review for possible error messages or a reason? The title is "Keeping up with the Jonses".

Thanks
If you're muxing with makemkv, try remuxing that title with mkvtoolix. There is a bug in makemkv when the audio and video track are not the same length (audio longer than video, so black screen at the end of the file). Mkvtoolnix deals better with the situation than makemkv. Mike knows about the issue but it won't be solved any time soon apparently.

To see if this is the same issue, go to the end of the file. If it's audio on a black screen, and if you can't navigate that part of the file at the end, that's what it is.

I had this issue with a few titles, remuxed them with mkvtoolnix and measurements completed fine.

Otherwise redo your rip, it might be wrong for another reason.

Don't ever use DXVA native, it's the worst option for measurements, at least here, and it's not recommended for playback anyway.

D3D11 native is usually the fastest for measurements, then copyback. Use DXVA2 copyback if you have to, but not native.
 
821 - 840 of 1220 Posts
Top