AVS Forum banner

741 - 760 of 1220 Posts

·
Registered
Joined
·
22 Posts
Please post a screenshot of all the settings you are using.

Chapter stability is controlled by:
- Rolling avg time in frames
- Merge scenes
- Merge Chapters
- Minimum chapter duration
Sorry for the late answer Flo, I was trying to better understand how your tool works to avoid bothering (and stupid) questions... However, the program was in default with all blank fields but the minimal target nits / real target nits (it was 100 but I'm using 50 now, 'cause I think is closer to the real brightness of my JVC RS49) and the dynamic target recovery strengh (100).


Maybe I have to set the recovery strengh to 75 or 50 with real target to 50 nits and see what happens and (in case I still have probems of quick brightness fluctuations) set an higher value of avg time frames (maybe 240 or 480): what do you think?
 

·
Registered
Joined
·
173 Posts
Sorry for the late answer Flo, I was trying to better understand how your tool works to avoid bothering (and stupid) questions... However, the program was in default with all blank fields but the minimal target nits / real target nits (it was 100 but I'm using 50 now, 'cause I think is closer to the real brightness of my JVC RS49) and the dynamic target recovery strengh (100).


Maybe I have to set the recovery strengh to 75 or 50 with real target to 50 nits and see what happens and (in case I still have probems of quick brightness fluctuations) set an higher value of avg time frames (maybe 240 or 480): what do you think?
They're not supposed to be blank, if they are blank that may explain your problems. I believe that the defaults are something like:

Maximal target: 1500
Dynamic Tuning: 75
No Compression limit: 200
Rolling average: 240
scene merge: 100
minimal chapter duration: 120
chapter merge: 50

Generally if you're seeing the brightness change you need to increase the rolling average, 480 works well to mask the changes but can be pretty slow. If it's changing suddenly then you need to change the chapter and scene merge settings. I personally use:

Rolling average: 120
scene merge: 350
minimal chapter duration: 24
chapter merge: 200
 

·
Registered
Joined
·
54 Posts
Further explanation about madMeasureMakeHardLink:

@pandm1967 might have worked it out in his measurement utility, but I have never understood how it works. Maybe he could explain it further?
Sorry for the delay. It is the traditional Chinese New Year now, so I am a little busy.

Because English is not my native language, and I am not good at it. I don't know if I can express my thoughts clearly? I will do my best, if you can't understand or have other questions, please point out and let us discuss it.

How to create a UHD clone folder measurement file for madVR using madMeasureMakeHardLink:
1. Click "Run Measure" of madMeasureMakeHardLink on the drive containing the UHD clone folder. (Each directory contains a UHD clone).
For the UHD's main title contain only one large stream file (?????.m2ts), madMeasureMakeHardLink measures the biggest stream file.​
For UHD's main title contains multiple stream files (e.g : include Theatrical & Extended version) or multiple titls UHDs (e.g : TV episoles), madMeasureMakeHardLink asks you to select the desired playlist to be measured.​
The simple way to choose playlist is to drag your UHD directory to MPC-BE and when it starts playing, check the properties (Shift + F10), which will display the playlist file that is played. Most of it is correct, but not always. Because MPC-BE always choose the longest playlist as main playlist. Sometime it is not correct. For those TV episodes or special UHDs, check the internet to find the correct playlist, or use the BDinfo tool to list the UHD titles and guess which ones are the correct playlists.​
2. Click "Make Hard Link" of madMeasureMakeHardLink on local drive to create additional hard links for the measurement files.
Because when madVR starts rendering media file, the measurement file of the media file are required for active dynamic tone mapping.
When playing the UHD folder, different media players report different media file to madVR, Kodi-DSplayer reports the media file to madVR: index.bdmv, MPC-BE reports the media file to madVR: ?????.mpls. My tools create aditional index.bdmv.measurements and ?????.mpls.measurements for both situation.
Q & A:
Q : Why doesn't the "Make Hard Link" feature support NAS drives?
A : Because make hard links funtion is a NTFS volumn feature. It can only support in local NTFS volumns. I found there many users uses NAS to store UHD clones, I will update "make hard link" to "duplicate measurement file" soon, it will use copy method to duplicate the measurement for NAS or non-NTFS drivers, but copy method will consume additional disk space.​
Q : Why choose to measure stream file for single large stream file titles and playlist files for multiple stream files titles?
A : Because measurement is a time consuming process and requires the user to select the desired playlist, the process will be interrupted. I automatically measure the single media stream titles and put all the multi-stream file titles into the final stage of the measurement.​
Q : How do I play the UHD clones folders?
A : Normaly I use Kodi-DSPlayer to play single stream file UHDs and long version of Multi-Version UHDs. (normaly the extended version). I use MPC-BE to play the TV episodes or manually selected playlist UHDs by dragging the desired playlist file to MPC.​
Q : How do I get Kodi-DSPlayer to work with the latest LAV filters?
A : Although Kodi-DSPlayer (17.6) has a built-in LAV filter, that version is an earlier version, not the latest version. Manually replace the files in the C:\Program Files\Kodi\system\players\dsplayer\LAVFilters directory with the latest lav files is a solution but since Kodi-DSPlayer manages the lav configuration parameters, it does not work well with the latest lavfilters.
My solution is :
a) Kodi setting : Settings -> General -> Player -> DS Player ->Filters , Filters management : System filters (DirectShow merits).
b) Use the Win7DSFilterTweaker_6.3 tool to set all preferred decoders and splitters to LAV (32 or 64 bit decoder, depending on Kodi-DSPlayer version).
c) If not works, try this program CodecTweakTool_630.exe to set "Preferred splitter" to LAV (recommanded set all source to LAV).​
 

·
Premium Member
Joined
·
9,820 Posts
Thanks a lot for the detailed post, very clear now :)

I'll wait for the version that supports NAS storage to give it a try, as all my films are ripped to different NAS boxes.
 

·
Registered
Joined
·
7,946 Posts
Instead, I will probably propose what @Dexter Kane proposed :) :
Like before, only 2 zones:
- below "No Compression Limit":
-->target Nits = Peak Nits

- above "No Compression Limit":
instead of:
target Nits = Min( frame peak, 2*avgHL, 200 + 2*Dynamictuning/50*FALL)
we would get:
target Nits = Min( frame peak, 2*avgHL, NocompLimit + 2*Dynamictuning/50*FALL)
I still see a problem with this: If the "frame peak" is identical to "No Compression Limit", the "target Nits" would then be identical to the "frame peak". However, if the "frame peak" is only 1 nits higher than the "No Compression Limit", the "target Nits" could suddenly jump up quite a bit. In order to remove this jump in the curve, I'd suggest this formula tweak:

DynamicScale = (FramePeak - NocompLimit) / (MaxTarget - NocompLimit)
TargetNits = Min( frame peak, 2*avgHL, NocompLimit + (2*Dynamictuning/50*FALL) * Min(1, DynamicScale))

This way if the FramePeak is only slightly above NocompLimit, also the TargetNits is only slightly above NocompLimit. And if FramePeak approaches MaxTarget, it gets the full strength of the Dynamic stuff.

Of course this change would lower the overall Dynamic effect, so the parameters might have to be adjusted a bit.
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #746 (Edited)
I still see a problem with this: If the "frame peak" is identical to "No Compression Limit", the "target Nits" would then be identical to the "frame peak". However, if the "frame peak" is only 1 nits higher than the "No Compression Limit", the "target Nits" could suddenly jump up quite a bit. In order to remove this jump in the curve, I'd suggest this formula tweak:

DynamicScale = (FramePeak - NocompLimit) / (MaxTarget - NocompLimit)
TargetNits = Min( frame peak, 2*avgHL, NocompLimit + (2*Dynamictuning/50*FALL) * Min(1, DynamicScale))

This way if the FramePeak is only slightly above NocompLimit, also the TargetNits is only slightly above NocompLimit. And if FramePeak approaches MaxTarget, it gets the full strength of the Dynamic stuff.

Of course this change would lower the overall Dynamic effect, so the parameters might have to be adjusted a bit.
No it would not.
Your forgot that we always cap at the frame peak.

So with a compression limit of 200,

if the frame peak is 199, then target nits = 199

if the frame peak is 201, and even if the FALL=201 itself, then Target Nits= Min( Frame Peak, 2*avgHL, 200+x* FALL)= Frame Peak=201 ;)

:)

That was always like that with the FALL algo, no jump whatsoever.
I just experimented a bit with the in betwwen zone, but as I said, it was bad because it could jump.

The original FALL algo nevers jumps.
And this slight tweak to replace the hardcoded 200 with No compression limit would also not jump.
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #748 (Edited)
madmeasuredynamicclipping Tool V3.6.0

So, new version: V3.6.0

Download:

http://projectiondream.com/download/madmeasuredynamicclipping/

NEW:

1) Removed experimental "middle" zone for people using at the same time a "No compression limit" below 200 and a dynamic tuning value below 100.

2) Instead, we now introduced @Dexter Kane idea, to replace the hardcoded 200 with NoCompLimit

Like before, only 2 zones:

- below "No Compression Limit":
-->target Nits = Peak Nits

- above "No Compression Limit":
instead of:
target Nits = Min( frame peak, 2*avgHL, 200 + 2*Dynamictuning/50*FALL)
we would get:
target Nits = Min( frame peak, 2*avgHL, NocompLimit + 2*Dynamictuning/50*FALL)

That way, you can use a lower a no compression limit and still have a smooth blend with the upper FALL algo.

So, basically, we replace the hardcoded 200 with "No Compression Limit".
If you choose "No Compression Limit"=200, then no change with now.
If you choose 150 for "no compression limit" but keep your old dynamic tuning value, then it may end up with a target nits 50nits lower than before. Or it may stay the same depending on the frame.
If either of the limiter 2*avgHL or peak is still reached, the nothing changes.
3) Changed default rolling avg / chapters value based on feedback from Dexter Kane and Neo-XP and my own testing:
- Rolling avg time in frames (centered): 120 -->5s with 24 content (before 240 frames)
- Merge scene: 100
- Minimum Chapter duration: 60frames-->2.5s with 24p content (before 120)
- Merge Chapter: 50

It works even better than before. :)


Enjoy,
(Anna&)Flo
 

·
Registered
Joined
·
1,208 Posts
It works even better than before. :)
I have to agree, I really like the result with this new version.
It seems to apply the right target for every condition, at least better than every previous versions IMO.

My new preferred settings did not change much:

Maximal target nits: 10000
Dynamic Tuning [50-200]: 75 (very good balance now for me between a bright image and "HDR effect")
No compression limit [nits]: 0

Time for rolling average in frames: 120
Merge scenes [FALL change in %]: 100
Minimal chapter duration in frames: 0
Merge chapters [avgFALL change in %]: 0

Well done!
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #750
I have to agree, I really like the result with this new version.
It seems to apply the right target for every condition, at least better than every previous versions IMO.

My new preferred settings did not change much:

Maximal target nits: 10000
Dynamic Tuning [50-200]: 75 (very good balance now for me between a bright image and "HDR effect")
No compression limit [nits]: 0

Time for rolling average in frames: 120
Merge scenes [FALL change in %]: 100
Minimal chapter duration in frames: 0
Merge chapters [avgFALL change in %]: 0

Well done!
Great to hear. :)

The new advanced default settings are the following:
- Maximal Target Nits= 1500
- Dynamic Tuning= 75
- No Compression Limit: 150nits

No compression limit in the algo is using your "real/minimum target nits as the minimum value" btw.

So, since I believe you are using a minimum/real display nits of 150nits, you are basically using the default settings as well (except for the max target nits which does not intervenes that often :) ).

We also use now the default settings with 150 "No compression limit", and 75 "dynamic tuning". And that's with our 50 real display nits :)
 

·
Registered
Joined
·
107 Posts
Hi,
A quick question.

I have 200 nits as my real display nits.

Regarding your info pasted below, do I gain anything if I change the No compression limit to 200 nits or can I just leave it at the default 150 nits as it uses my real target nits as the minimum value anyway?

"No compression limit in the algo is using your "real/minimum target nits as the minimum value""


Best regards,
Peter

Sent from my SM-N960F using Tapatalk
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #752
Hi,
A quick question.

I have 200 nits as my real display nits.

Regarding your info pasted below, do I gain anything if I change the No compression limit to 200 nits or can I just leave it at the default 150 nits as it uses my real target nits as the minimum value anyway?

"No compression limit in the algo is using your "real/minimum target nits as the minimum value""


Best regards,
Peter

Sent from my SM-N960F using Tapatalk
You understood properly.
In your case, the minimum value for the "No compression Limit" is 200nits since your display real nits is 200.

So you can leave it at 150, or put it at 200 yourself. There will be zero difference. :)
 

·
Premium Member
Joined
·
9,820 Posts
@Soulnight: Thanks Anna & Flo for the new version, looking forward to testing it, sounds great.

I might try to lower my 300nits compression limit to 200nits, as it sounds like the new algo might provide a good compromise between brightness and stability for 0-100nits.

I'll report back!
 

·
Registered
Joined
·
173 Posts
@Soulnight

Thanks for the new version, it seems to work really well :)

I've managed to squeeze some more light out of my TV and haven't fine tuned my new settings yet, so I tested with 100 nits real display brightness and some guesses at settings (100 dynamic tuning and 100 no comp limit) and the results were really good. I tried out that scene in Die Hard with the bright spot and it looked exactly the same as it does with my normal 200 nits. Obviously the highlights aren't as bright but the rest of the image looked (at least from memory) the same, which is I think exactly what you want. I tried out a few other dark scenes with highlights and they all looked great, I think if I were limited to 100 nits I could be very happy with it with a bit of fine tuning of the settings. Great work guys!

Looks like these settings are working well for me, I'm optimising the library now so I'll test further with these settings:

Minimal/real nits: 250
Maximal nits: 2000 (probably could use 10000, I haven't really figured out what a good value here is yet)
Dynamic tuning: 150 (200 wasn't working well in darker scenes with the higher no comp limit, but brighter scenes look the same because of the average highlight cap so 150 seems like a good value)
no comp limit: 250
 

·
Registered
Joined
·
173 Posts
@Soulnight

I've been testing the new madvr version and the dynamic clipping in that seems to be noticeably different to using the optimised measurement file. It looks to me like the measurement file clipping isn't working and in the OSD at least appears to be giving the same frame peak numbers as with clipping disabled. Looking at the optimised file and the original with the madmeasureanyliser tool there is a difference between the two which indicates that it's working, however at the least it looks like the madvr implementation is more aggressive or at least more noticeable (I'm using 100% on both).

Could it be the same issue from before?
 

·
Registered
Joined
·
466 Posts
Just wanted to say that after playing with this for a while and figuring out my preferred settings it is really a joy to watch an optimized movie. I have my base settings that work for 90% of my collection (assume) and then a few custom that I apply to individual titles as needed. Finding the sweet spot has been a journey but well worth it. I watched a couple movies today (the reason we do this right?) and really enjoyed the picture quality unlike early efforts with HDR and my projector that left me wanting more. Thanks again for the great software. For me the current sweet spot in my environment is 90 for "real" and 125 for dynamic tuning - all else as default. Not that I think this will translate for anyone else as we all have different environments and tastes and its nice this tool can deal with that.

EDIT: Sounds like I might need to find a sweet spot again for madVR if it is not apples to apples in how it works. Always moving forward.
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #758
@Soulnight

I've been testing the new madvr version and the dynamic clipping in that seems to be noticeably different to using the optimised measurement file. It looks to me like the measurement file clipping isn't working and in the OSD at least appears to be giving the same frame peak numbers as with clipping disabled. Looking at the optimised file and the original with the madmeasureanyliser tool there is a difference between the two which indicates that it's working, however at the least it looks like the madvr implementation is more aggressive or at least more noticeable (I'm using 100% on both).

Could it be the same issue from before?
We'll test that to check that it still works as intended with the dynamic clipping in the measurement file and madVR beta41.

As far as I know, Madshi implemented the dynamic clipping code we gave him. So the core algo should be very similar.

However, there are 3 majors differences between what madshi could implement and what we implemented:

1) We use the dynamic clipping scene based. Madshi has no other choice than to user it frame based.
The scene based implementation will be much more conservative and less agressive which was our goal (at least in the begining).

a) We calculate for each frame what would be the new "clipping peak" within a scene. (what madshi does)
b) Then we look at the maximum of all those clipping peak within the current scene and only change/cut the original frame peak of the frames in this scene if they were above this "maximum".
So basically, we leave a lot untouched. All the frames which had an original peak lower than the current max scene clipped peak are left untouched /unclipped

-->So as I said, I think Madshi could only implement a) and maybe it's even better. :D
We played the safe card here, especially because historitically we did not have a "smart" knee but a fixed clipping %. And we never removed the b) step. :)

2) MadVR can work with non-rounded value. In the Histogram saved in the measurement file, sometimes it's written zero in a colum when it should not because the resolution is not high enough.
@madshi can confirm if during the live algo he can use the original number unrounded to look for the "Clipping knee".

3) *maybe" madshi can use the dynamic clipping at an earlier stage/step of the tone mapping process which would yield different result as well.
 

·
Registered
Joined
·
173 Posts
We'll test that to check that it still works as intended with the dynamic clipping in the measurement file and madVR beta41.

As far as I know, Madshi implemented the dynamic clipping code we gave him. So the core algo should be very similar.

However, there are 3 majors differences between what madshi could implement and what we implemented:

1) We use the dynamic clipping scene based. Madshi has no other choice than to user it frame based.
The scene based implementation will be much more conservative and less agressive which was our goal (at least in the begining).

a) We calculate for each frame what would be the new "clipping peak" within a scene. (what madshi does)
b) Then we look at the maximum of all those clipping peak within the current scene and only change/cut the original frame peak of the frames in this scene if they were above this "maximum".
So basically, we leave a lot untouched. All the frames which had an original peak lower than the current max scene clipped peak are left untouched /unclipped

-->So as I said, I think Madshi could only implement a) and maybe it's even better. :D
We played the safe card here, especially because historitically we did not have a "smart" knee but a fixed clipping %. And we never removed the b) step. :)

2) MadVR can work with non-rounded value. In the Histogram saved in the measurement file, sometimes it's written zero in a colum when it should not because the resolution is not high enough.
@madshi can confirm if during the live algo he can use the original number unrounded to look for the "Clipping knee".

3) *maybe" madshi can use the dynamic clipping at an earlier stage/step of the tone mapping process which would yield different result as well.
That could be it. It's hard to do a back and forth comparison between clipping on/off and the measurement file. If it's just a different implementation then at least with the scenes I was looking at I think I prefer the madvr version, the difference stood out right away when I was looking at the Infinity Wars scene that @Javs was looking at in the other thread.

I think that with the way the dynamic targets work that the individual frame peaks make more of a difference than they did before.
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #760 (Edited)
That could be it. It's hard to do a back and forth comparison between clipping on/off and the measurement file. If it's just a different implementation then at least with the scenes I was looking at I think I prefer the madvr version, the difference stood out right away when I was looking at the Infinity Wars scene that @Javs was looking at in the other thread.

I think that with the way the dynamic targets work that the individual frame peaks make more of a difference than they did before.
So, we just tested.
Everything is working fine on our side with the dynamic clipping corrected to be scene based.

Madshi also provided his adaption of our code and it's mostly identical to what we sent him.

As I suspected, the difference only comes with the "scene" based dynamic clipping implementation VS frame based.
So, to test we removed step b) (scene based smoothing) in our code and tested out the frame based. We then get about the same result than madVR is outputting with the frame based approach.

Here the illustration with a fixed target nits of 200nits and rec709:

http://www.framecompare.com/image-compare/screenshotcomparison/19ECNNNU

- Original REC709 frame peak: 335nits
- MadVR dynamic clipping 100%: 172nits (clipping peak)
- Our dynamic clipping tool 100% / frame based: 161nits peak (but madVR smoothes the scene tone map target to 172nits)
- Our dynamic clipping tool 100% / scene based: 192nits peak (and also 192 tone map target which make sense since this is the max clipping peak value of the scene)

Also, there are 3 different peak value depending on BT2020, DCi-P3 and REC709.
All the dynamic clipping work is done for the BT2020. Then you need to decide what to do for the DCI-P3 and REC709.
Madshi is scaling the dynamic clipping he got for rec2020 and applied this dynamic clipping factor to the rec709 and dci-p3 peak.
We used the Bt2020 peak instead when applied clipping and kept the orginal dci-p3 and bt209 otherwise.

We will probably adopt the scaling approach between bt2020, dci and rec709 from madshi in our tool as well, which will remove one difference.
And of course, if you all agree that frame based is better than conservative scene based, we can remove the step b) and do it frame based as well. This of course will apply dynamic clipping more often and also in a stronger way. :)


EDIT: after talking further to madshi, I realized we did not give him another part of the algo to avoid doing dynamic clipping when not worth it. It was included in the scene part of the algo that he did not need since he can only work frame based.

Right now, current version of the dynamic clipping in madVR is basically clipping every single frames at the knee.

In the dynamic clipping of our tool, we have introduced safeguard:
1) Work scene based an not frame based as discussed before
2) Do not clip if the decompressed area is not big enough in comparison to the clipped area.
If decompressed area < 10* clipping area, then we say it's not worth it, and we do not apply dynamic clipping.

This can be seen for example in the mother scene with the lamp ( @Neo-XP)
--> Current version of dynamic clipping in madVR is clipping part of the lamp
--> Our tool does not apply clipping there. It looks at the potential decompressed area (75nits to clipped peak), and says decompressed area is lower than 10 times the clipped area, so better not clip there.

I have proposed to madshi to not only look at the size/area of the decompressed pixels, but also to look at how strongly would they be decompressed as a further check.

In any cases, the checks 1) and 2) are sorting out A LOT of frames. For example, we only clip (more than 10nits) 30% of the frames of Lucy. Very likely, the number is quite a lot higher in the current madVR beta V41.
 
741 - 760 of 1220 Posts
Top