Improving Madvr HDR to SDR mapping for projector - Page 137 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 4587Likes
Reply
 
Thread Tools
post #4081 of 5925 Old 11-08-2018, 09:26 AM
Member
 
stefanelli73's Avatar
 
Join Date: Jan 2008
Posts: 86
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 21 Post(s)
Liked: 15
@Manni

in your profiles you have also added "BT2390 Mode 10 (Fast)"?
stefanelli73 is offline  
Sponsored Links
Advertisement
 
post #4082 of 5925 Old 11-08-2018, 09:29 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
Quote:
Originally Posted by stefanelli73 View Post
@Manni

in your profiles you have also added "BT2390 Mode 10 (Fast)"?
Yes, that's just for the JVC, it sends 4K60p in 8bits in passthrough due to the magenta bug. You can safely ignore this if you don't have a JVC that has the magenta bug in 8bits (4K60p only with 385.28, but at all refresh rates with more recent drivers).

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
Manni01 is online now  
post #4083 of 5925 Old 11-08-2018, 09:35 AM
Advanced Member
 
clark17's Avatar
 
Join Date: Jan 2009
Location: Ottawa - Ontario
Posts: 702
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 158 Post(s)
Liked: 74
Quote:
Originally Posted by Manni01 View Post
"Enable dynamic HDR" is enabled, yes, but not "Output Video in HDR Format", as that would be guaranteed to give a worse result on the JVCs.

Thanks for a quick confirmation.



Quote:
Originally Posted by stefanelli73 View Post
@Manni

in your profiles you have also added "BT2390 Mode 10 (Fast)"?

Just to add what Manni said; the "fps > 31" can also be also used if you have slow GPU (in my case gtx1060 (6gb)) to disable highlight recovery option for 4k60p material.
clark17 is offline  
Sponsored Links
Advertisement
 
post #4084 of 5925 Old 11-08-2018, 10:55 AM
Advanced Member
 
Neo-XP's Avatar
 
Join Date: Jun 2018
Location: Switzerland
Posts: 803
Mentioned: 133 Post(s)
Tagged: 0 Thread(s)
Quoted: 554 Post(s)
Liked: 620
Quote:
Originally Posted by madshi View Post
I've changed the whole logic. The old "brightness reaction time" increased the tone mapping target from the "current" target to the newly measured peak always in the same "brightness reaction time", regardless of how high the necessary adjustment was. So if you selected e.g. 0.1s, that's 2.4 frames. So even if the "current" tone mapping target is 1nits, and the newly measured peak is 10,000nits, a brightness reaction time of 0.1s still went up from 1nits to 10,000nits in 2.4 frames. I think it was rounded down to just 2 frames. So 1nits -> 5000nits -> 10000nits. That's pretty extreme, isn't it?
It is extreme, but if you trust the "flicker risk" value and apply a very slow reaction time (5 seconds or more) when the flicker risk is high, it should not be an issue?
5 seconds is less than 100nits increase from a frame to the next (~83nits) to go from 0 nits to 10'000nits (the most extreme case).
Or is the "flicker risk" value not as reliable as I think it is?

Quote:
Originally Posted by madshi View Post
The 0.1s reaction time also meant that if e.g. the current target was 200nits, and the newly measured target was 250nits, then it still adjusted in 2 frames. So 200nits -> 225nits -> 250nits. (Or maybe it was 3 frames instead of 2, don't know for sure right now.)

IMHO the above logic didn't make too much sense. It doesn't make sense to always adjust in a specific number of frames, regardless of how big the adjustment is, IMHO.

So I changed the logic to instead adjust a certain max brightness percentage per frame. For example, let's say the new reaction speed is "double the tone mapping target each frame". So we could go from 200nits -> 250nits in one frame. But going from 200nits -> 1000nits would go in steps like 200nits -> 400nits -> 800nits -> 1000nits. That makes more sense, no?
Wasn't the purpose of the "flicker risk" value to remove this delay compared to APL-4?

Quote:
Originally Posted by madshi View Post
So the new logic now calculates a specific "max brightness adjustment factor" (based on flicker risk) which is applied to each frame. So if we need to get brighter, in each frame we do "newToneMapTarget = currentToneMapTarget * factor", until we've reached the target.

Now "Mother" is a pretty extreme example, because it goes from 5nits up to 977nits in 2 frames. Even if we use a max brightness adjustment factor of 10x (which is pretty extreme), we'd still go 5nits -> 50nits -> 500nits -> 977nits. You can see that Mother is still not behaving worse than 0.25s reaction time, though, so you can see that my flicker risk -> max brightness adjustment factor is still allowing very large adjustment factors, as long as the flicker risk is low. E.g. check the Harry Potter scene, I think it adjusts faster than even 0.1s? That's because it starts at higher nits, and doesn't ramp up as extremely quickly as the Mother scene.
In "madVRhdrMeasure27" (with 0.1s): 9nits -> 242nits -> 488nits -> 691nits -> 942nits.
In "madVRhdrMeasure28": 8nits -> 152nits -> 229nits -> 349nits -> 553nits -> 925nits -> 942nits

That seems very slow to me, and the result is blown out highlights

Quote:
Originally Posted by madshi View Post
I suppose I could allow even higher max adjustment factors, to make the Mother scene better, but I think that's probably one of the most extreme examples we'll ever see. If we optimize for that scene alone, I'm worried that we might introduce artifacts in other scenes. So I thought it would be "ok" if Mother just looked similar to how the previous "default/recommended" setting of 0.25s brightness reaction time looked.
With the new logic, what would happen if the peak nits was ~4000 instead of ~1000 for a scene like Mother!?
Would it take even more time to adapt?

Quote:
Originally Posted by madshi View Post
At the same time Harry Potter looks better, and there are no brightness jumps in either the Jurassic World or Matrix 2 test scenes.
The Harry Potter scene looks way better now (compared to 0.25s) and reacts almost immediately, but I expected the Mother! scene to behave the same if the reaction time was based on the "flicker risk" value without the added delay of the new logic.

Quote:
Originally Posted by madshi View Post
So the new logic should be a big improvement over using a fixed brightness reaction time, no?
Of course, 99% improvement, it just needs the last 1%
We are almost there to be perfect.

Edit:

The Matrix 2 scene analysis, might be interesting:

Static 5 seconds

Measured peak -> target
168 -> 203
477 -> 206
236 -> 206
360 -> 207
850 -> 212
720 -> 217
820 -> 222
877 -> 227
805 -> 232
756 -> 236
726 -> 241
784 -> 245
780 -> 250
577 -> 253
322 -> 253
211 -> 253
183 -> 253
169 -> 253

Dynamic

Measured peak -> target
157 -> 202
358 -> 203
175 -> 203
239 -> 204
865 -> 206
710 -> 207
839 -> 209
877 -> 210
805 -> 211
780 -> 213
710 -> 214
763 -> 216
813 -> 217
471 -> 219
317 -> 220
180 -> 220
164 -> 220
160 -> 220

Conclusion: Thanks madshi!

Edit2:

With stored measurements:

Measured peak -> target
157 -> 731
358 -> 738
175 -> 745
239 -> 750
865 -> 754
710 -> 757
839 -> 760
877 -> 761
805 -> 763
780 -> 763
710 -> 764
763 -> 763
813 -> 762
471 -> 761
317 -> 759
180 -> 756
164 -> 753
160 -> 749

If we can improve Mother! scene with the "live" dynamic HDR algo, I won't see any point to use the stored measurements algo, unless it is improved too

Stored measurements / Live



Edit3:

The Predator's outro scene is this time too fast:

Measured peak -> target
88 -> 119
152 -> 152
285 -> 204
564 -> 276
813 -> 382
905 -> 551
955 -> 837
955 -> 955

@madshi what about reaction time [s] = "flicker risk" value? What would be the target values for Mother!, Harry Potter, Matrix 2 and Predator's outro scenes?
If I am not mistaken, the only way to know it is to test it for real, because the "flicker risk" value changes depending on the current target (which depends on the reaction time).
Manni01, clark17, KoKlusz and 1 others like this.

Last edited by Neo-XP; 11-08-2018 at 08:23 PM.
Neo-XP is offline  
post #4085 of 5925 Old 11-08-2018, 11:12 AM
Member
 
soyhakan's Avatar
 
Join Date: Jun 2011
Posts: 131
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 67 Post(s)
Liked: 40
I installed madVRhdrMeasure28 and checked 2001 Space Oddssey again. The sun flickers very little. Looks like its improved now.
But maybe there is little flicker in source because it exist in sdr bluray versiyon also. Colors are different in sdr bluray.

I made sample file :
https://mega.nz/#!UJo2FSxT!5TL0NAsI1...XYAEXUIVMkV4eU

Also checked the gpu when madMeasureHDR.exe running. My gpu usage is 0% but cpu usage 100%.
In general settings tab "use Direct3D 11 for presentation" is checked

On Lav Video Hardware acc. Dxva2 (copy-back) selected. But selecting other options not really speed up the mesasuring.
Is there is a setting i'm not noticing?

Because madMeasureHDR.exe does not have a gui. I run it via htpccontrol.exe or simply drag-drop video file on it.
soyhakan is offline  
post #4086 of 5925 Old 11-08-2018, 11:32 AM
Advanced Member
 
hasta666's Avatar
 
Join Date: Apr 2016
Posts: 604
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 448 Post(s)
Liked: 148
Improving Madvr HDR to SDR mapping for projector

Quote:
Originally Posted by soyhakan View Post
I installed madVRhdrMeasure28 and checked 2001 Space Oddssey again. The sun flickers very little. Looks like its improved now.

But maybe there is little flicker in source because it exist in sdr bluray versiyon also. Colors are different in sdr bluray.



I made sample file :

https://mega.nz/#!UJo2FSxT!5TL0NAsI1...XYAEXUIVMkV4eU



Also checked the gpu when madMeasureHDR.exe running. My gpu usage is 0% but cpu usage 100%.

In general settings tab "use Direct3D 11 for presentation" is checked



On Lav Video Hardware acc. Dxva2 (copy-back) selected. But selecting other options not really speed up the mesasuring.

Is there is a setting i'm not noticing?



Because madMeasureHDR.exe does not have a gui. I run it via htpccontrol.exe or simply drag-drop video file on it.


D3D11 is faster but it probably depends also on your hardware. I’m using my workstation to measure with D3D11 so I can keep my HTPC to copy-back (otherwise Zoom control doesn’t work as wanted).

If GPU is not used, I would reset every settings from madVR and LAV and just check tone mapping and Direct3D 11. That’s what I did. In the end, it would be better if madMeasureHDR was not dependent on madVR and/or LAV setttings but I think that’s not the case right now. Maybe madshi can confirm but I rather have him working on tone mapping ;-) Of course madMeasureHDR might not be able to force the decoder on LAV, understanding.

Last edited by hasta666; 11-08-2018 at 11:38 AM.
hasta666 is offline  
post #4087 of 5925 Old 11-08-2018, 01:19 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
@madshi
@pandm1967

It looks like there is a bug in the MadMeasureHDR analyzer, AVGFmll in the utility is displaying AVGFALL, not AVGFmll, as far as I can see.

I stopped using BerndFfm's utility as I couldn't get a log and went back to my batch to get the actual output from MadMeasureHDR.

AVGFmll seems to be a far more useful data, as it's not always under 100nits as AVGFALL. You are correct that it might be quite close to Scene Peak Average, I need to check a few more files.

I'll edit my post earlier to correct it.

MaxFALL isn't going to be a sueful variable because metadata MAxFALL is too far away from MadVR's MaxFALL, so we can't have an algo that works both ways.

I'm going to do more testing on AVGFmll now that I've remeasured various files and can do some tests using the OSD. I'll try to posts results tonight.

@pandm1967 , please could you double check your utility and correct the label for AVGFALL and if at all possible display AVGFmll? Thanks!
clark17 likes this.

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
Manni01 is online now  
post #4088 of 5925 Old 11-08-2018, 01:47 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
[EDIT: updated algo can be found here]

Okay I've done some tests and this seems to be working pretty well with my usual test files.

I need to check more files and I will probably finetune the values later, but I'm quite happy with this already.

Let me know what you think!

if (hdr) and (srcWidth <= 3840) and (srcHeight <= 2160) and (fps > 31) "BT2390 Mode 10 (Fast)"
if (hdr) and (AVGFmll = 0) "HDR BT2390 480nits" else
if (hdr) and (AVGFmll <= 100) "HDR BT2390 200nits" else
if (hdr) and (AVGFmll <= 155) "HDR BT2390 225nits" else
if (hdr) and (AVGFmll <= 210) "HDR BT2390 250nits" else
if (hdr) and (AVGFmll <= 265) "HDR BT2390 275nits" else
if (hdr) and (AVGFmll <= 320) "HDR BT2390 300nits" else
if (hdr) and (AVGFmll <= 375) "HDR BT2390 325nits" else
if (hdr) and (AVGFmll <= 430) "HDR BT2390 350nits" else
if (hdr) and (AVGFmll <= 485) "HDR BT2390 375nits" else
if (hdr) and (AVGFmll <= 540) "HDR BT2390 400nits" else
if (hdr) and (AVGFmll <= 595) "HDR BT2390 425nits" else
if (hdr) and (AVGFmll <= 650) "HDR BT2390 450nits" else
if (hdr) and (AVGFmll <= 695) "HDR BT2390 480nits" else
if (hdr) and (AVGFmll <= 750) "HDR BT2390 500nits" else
if (hdr) and (AVGFmll <= 805) "HDR BT2390 525nits" else
if (hdr) and (AVGFmll <= 860) "HDR BT2390 550nits" else
if (hdr) and (AVGFmll <= 915) "HDR BT2390 575nits" else
if (hdr) and (AVGFmll > 915) "HDR BT2390 600nits" else
"Send Metadata SDR"
clark17 and quietvoid like this.

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 11-08-2018 at 03:38 PM.
Manni01 is online now  
post #4089 of 5925 Old 11-08-2018, 01:58 PM
Advanced Member
 
clark17's Avatar
 
Join Date: Jan 2009
Location: Ottawa - Ontario
Posts: 702
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 158 Post(s)
Liked: 74
So you like AVGFmll more than HDRVideoPeak? I will try your profiles tonight :P Thank you for sharing.



Quote:
Originally Posted by Manni01 View Post
Okay I've done some tests and this seems to be working pretty well with my usual test files.

I need to check more files and I will probably finetune the values later, but I'm quite happy with this already.

Let me know what you think!

if (hdr) and (srcWidth <= 3840) and (srcHeight <= 2160) and (fps > 31) "BT2390 Mode 10 (Fast)"
if (hdr) and (AVGFmll = 0) "HDR BT2390 480nits" else
if (hdr) and (AVGFmll <= 100) "HDR BT2390 200nits" else
if (hdr) and (AVGFmll <= 155) "HDR BT2390 225nits" else
if (hdr) and (AVGFmll <= 210) "HDR BT2390 250nits" else
if (hdr) and (AVGFmll <= 265) "HDR BT2390 275nits" else
if (hdr) and (AVGFmll <= 320) "HDR BT2390 300nits" else
if (hdr) and (AVGFmll <= 375) "HDR BT2390 325nits" else
if (hdr) and (AVGFmll <= 430) "HDR BT2390 350nits" else
if (hdr) and (AVGFmll <= 485) "HDR BT2390 375nits" else
if (hdr) and (AVGFmll <= 540) "HDR BT2390 400nits" else
if (hdr) and (AVGFmll <= 595) "HDR BT2390 425nits" else
if (hdr) and (AVGFmll <= 650) "HDR BT2390 450nits" else
if (hdr) and (AVGFmll <= 695) "HDR BT2390 480nits" else
if (hdr) and (AVGFmll <= 750) "HDR BT2390 500nits" else
if (hdr) and (AVGFmll <= 805) "HDR BT2390 525nits" else
if (hdr) and (AVGFmll <= 860) "HDR BT2390 550nits" else
if (hdr) and (AVGFmll <= 915) "HDR BT2390 575nits" else
if (hdr) and (AVGFmll > 915) "HDR BT2390 600nits" else
"Send Metadata SDR"
clark17 is offline  
post #4090 of 5925 Old 11-08-2018, 02:03 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
Quote:
Originally Posted by clark17 View Post
So you like AVGFmll more than HDRVideoPeak? I will try your profiles tonight :P Thank you for sharing.
Yes because it takes into account the average brightness of the movie, not only the peak, which can be misleading even when corrected.

I need to compare both algos, but I expect AVGFmll to be more consistently correct than HDRVideoPeak.

Running more tests with the PJ on now...
clark17 likes this.

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
Manni01 is online now  
post #4091 of 5925 Old 11-08-2018, 03:27 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
New algo to select a profile automatically according to content [Updated 29-12-18]

Note: These instructions are for advanced users. If they are not enough for you to use and adapt this algo (or anyone else's), please do NOT post in this thread to ask for help regarding your specific set-up. Wait until there is a public release of MadVR with the new measurements files, and ask your question in the usual MadVR support thread at Doom9 or in this forum. This thread isn't a support thread for end-users, and we are aware that this auto profile selection isn't a very user-friendly way to achieve this, nor a perfect way to do so. Still, that's the best we have at the moment. This thread is for people to contribute if they can provide feedback to Madshi, and this auto-selection for profiles isn't part of his road-map. More progress is on the way, so please be patient. Thank you!

All right so here is the algo I have settled on for now, using the new AvgFMLL variable to select a profile automatically. This is for my fully calibrated JVC RS500 projector in low lamp, 145nits actual peak brightness, fully dedicated room (bat loft). Screen is a Carada BW 88" diag 16/9.

I've slightly adjusted the thresholds compared to the one I posted earlier. [EDIT 11-11-18: I've implemented AvgFALL as a limiter to better deal with very dim titles or very bright titles, further revised 12-11-18, 13-11-18 and 14-11-18 to add more limiter corrections]. The target peaks are the same. This is, of course, if you use measurements files. Otherwise see below for the algo based on HDRVideoPeak. Note that my measurements value are based on 1:1 rips. If you crop the black bars when backing-up your discs, you will need to adjust the values to something similar to what @Dexter Kane does here.

[EDIT 29-12-18: from test build 38, the black bars are not taken into account anymore. I have updated my algo and for now I've decided to experiment with something very close to Dexter Kane's values, apart from a few tuned thresholds. The profiles are often higher than with my older algo as his curve for AVGFMLL is less linear than mine, but it might be a good thing so I'm going to try and see how it is. As I'm going to get close to 140nits in low lamp with my new PJ, I might be happy with this. I'm going to set my lamp to high with the rs500 to get 145nits and see what I like and don't like. Unless I'm very unhappy with a few selections, I'm unlikely to finetune this until I get my new PJ anyway. For now I've taken out all the exceptions/special cases. I haven't had the time to update the list of films attached below, I'll do this when I find the time (done, I've left the previous measurements to compare the effect of black bars/no black bars)].

[EDIT 29-12-18: here is a link to Dexter Kane's new algo/values, with a range of 200-800nits, for an actual peak brightness of 212nits.]

My range is 200-600nits [EDIT 29-12-18: for an actual peak brightness of around 107nits currently]. You will probably need to adjust the targets to your own peak brightness, but don't change the AvgFMLL/AvgFALL thresholds unless you have a good reason to.

What I suggest you do if you want to adjust this algo to your display/taste is take two extreme movies, say Blade Runner 2049 or Ghost in the Shell (super dim, little to no highlights, if you don't have either pick your dimmest title) and Starship Troopers or Kingsman - The Golden Circle (super bright, lots of highlights, if you don't have either pick your brightest title, the Meg isn't a good choice as apparently it often blows highlights). Select manually the best target for each of them, finding the best balance between dark scenes and highlights for each film. That will give you the lowest target to replace my 200nits, and the highest target to replace my 600nits. Once you have your min/max target, simply change all the other targets in between to get the targets you want to select for titles in between these extreme. Maybe check a median title to decide on your median target.

For example, some with 50nits peak brightness (around half of mine) have reported good results cutting all my target nits below by two, so 100nits instead of 200nits, 112 nits instead of 225nits, 125nits instead of 250nits, etc).

[EDIT 29-12-18: @Soulnight (Anna & Flo) have released a new version of their utility here. If you use measurements files, I highly recommend you use it as it implements the algo below and populates a target nits for each file, which makes the profiles unnecessary. It also scales the targets based on the display's peak brightness. In that case, please use the simplified algo described in this post.]

[EDIT 04-01-19: New thread for Soulnight's utility: https://www.avsforum.com/forum/26-ho...rget-nits.html with latest version and a new algo "flo" with dynamic targets. Please post any questions about this utility in that thread.]

[EDIT 07-01-19: I get excellent results with V2.9.9 of Soulnight's utility and dynamic targets, so I don't recommend my algo below anymore unless you're not using measurements files. Here are the latest settings I recommend].

[EDIT 12-01-19: even better results with V3.1.0 of Soulnight's utility with dynamic targets and chapters for more stable targets. My latest recommended settings are here.]

Here you go:

if (hdr) and (AvgFMLL = 0) "HDR BT2390 475nits" else
if (hdr) and (AvgFALL <= 6) "HDR BT2390 200nits" else
if (hdr) and (AvgFMLL <= 101) "HDR BT2390 200nits" else
if (hdr) and (AvgFALL <= 10) "HDR BT2390 225nits" else
if (hdr) and (AvgFMLL <= 160) "HDR BT2390 225nits" else
if (hdr) and (AvgFALL <= 11) "HDR BT2390 250nits" else
if (hdr) and (AvgFMLL <= 190) "HDR BT2390 250nits" else
if (hdr) and (AvgFALL <= 12) "HDR BT2390 275nits" else
if (hdr) and (AvgFMLL <= 224) "HDR BT2390 275nits" else
if (hdr) and (AvgFALL <= 13) "HDR BT2390 300nits" else
if (hdr) and (AvgFMLL <= 250) "HDR BT2390 300nits" else
if (hdr) and (AvgFALL <= 14) "HDR BT2390 325nits" else
if (hdr) and (AvgFMLL <= 270) "HDR BT2390 325nits" else
if (hdr) and (AvgFALL <= 15) "HDR BT2390 350nits" else
if (hdr) and (AvgFMLL <= 300) "HDR BT2390 350nits" else
if (hdr) and (AvgFALL <= 17) "HDR BT2390 375nits" else
if (hdr) and (AvgFMLL <= 340) "HDR BT2390 375nits" else
if (hdr) and (AvgFALL <= 20) "HDR BT2390 400nits" else
if (hdr) and (AvgFMLL <= 380) "HDR BT2390 400nits" else
if (hdr) and (AvgFALL <= 24) "HDR BT2390 425nits" else
if (hdr) and (AvgFMLL <= 430) "HDR BT2390 425nits" else
if (hdr) and (AvgFALL <= 30) "HDR BT2390 450nits" else
if (hdr) and (AvgFMLL <= 490) "HDR BT2390 450nits" else
if (hdr) and (AvgFALL <= 37) "HDR BT2390 475nits" else
if (hdr) and (AvgFMLL <= 560) "HDR BT2390 475nits" else
if (hdr) and (AvgFALL <= 44) "HDR BT2390 500nits" else
if (hdr) and (AvgFMLL <= 640) "HDR BT2390 500nits" else
if (hdr) and (AvgFALL <= 54) "HDR BT2390 525nits" else
if (hdr) and (AvgFMLL <= 750) "HDR BT2390 525nits" else
if (hdr) and (AvgFALL <= 66) "HDR BT2390 550nits" else
if (hdr) and (AvgFMLL <= 860) "HDR BT2390 550nits" else
if (hdr) and (AvgFMLL <= 980) "HDR BT2390 575nits" else
if (hdr) and (AvgFMLL > 980) "HDR BT2390 600nits" else
"Send Metadata SDR"

It comes up with fairly optimal targets for the movies I've tested, in my set-up of course (see attached list).

If you don't use measurements files, it's safer to use my old algo based on HDRVideoPeak. Here it is:

if (hdr) and (HDRVideoPeak = 0) "HDR BT2390 480nits" else
if (hdr) and (HDRVideoPeak <= 200) "HDR BT2390 200nits" else
if (hdr) and (HDRVideoPeak <= 500) "HDR BT2390 225nits" else
if (hdr) and (HDRVideoPeak <= 750) "HDR BT2390 250nits" else
if (hdr) and (HDRVideoPeak <= 950) "HDR BT2390 275nits" else
if (hdr) and (HDRVideoPeak <= 1100) "HDR BT2390 300nits" else
if (hdr) and (HDRVideoPeak <= 1500) "HDR BT2390 325nits" else
if (hdr) and (HDRVideoPeak <= 2000) "HDR BT2390 350nits" else
if (hdr) and (HDRVideoPeak <= 2250) "HDR BT2390 375nits" else
if (hdr) and (HDRVideoPeak <= 2500) "HDR BT2390 400nits" else
if (hdr) and (HDRVideoPeak <= 2625) "HDR BT2390 425nits" else
if (hdr) and (HDRVideoPeak <= 2750) "HDR BT2390 450nits" else
if (hdr) and (HDRVideoPeak <= 3000) "HDR BT2390 475nits" else
if (hdr) and (HDRVideoPeak <= 2200) "HDR BT2390 500nits" else
if (hdr) and (HDRVideoPeak <= 3500) "HDR BT2390 525nits" else
if (hdr) and (HDRVideoPeak <= 3750) "HDR BT2390 550nits" else
if (hdr) and (HDRVideoPeak <= 4000) "HDR BT2390 575nits" else
if (hdr) and (HDRVideoPeak > 4000) "HDR BT2390 600nits" else
"Send Metadata SDR"

[EDIT: I've also updated the batch file I use to generate measurements files automatically here].
Attached Thumbnails
Click image for larger version

Name:	HDR Algo.JPG
Views:	154
Size:	212.4 KB
ID:	2482974   Click image for larger version

Name:	HDR Settings.JPG
Views:	138
Size:	168.9 KB
ID:	2482976   Click image for larger version

Name:	HDR Examples.JPG
Views:	124
Size:	255.0 KB
ID:	2483374   Click image for larger version

Name:	HDR Examples (measurements without black bars).JPG
Views:	38
Size:	226.6 KB
ID:	2502266  
CoryW, carpantata, valin and 6 others like this.

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 01-12-2019 at 02:46 PM.
Manni01 is online now  
post #4092 of 5925 Old 11-08-2018, 03:43 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,540
Mentioned: 443 Post(s)
Tagged: 0 Thread(s)
Quoted: 2308 Post(s)
Liked: 2894
Quote:
Originally Posted by Manni01 View Post
I've done some quick tests and personally don't find AvgFALL useful at all. Not enough granularity, and not representative of the actual brightness of the movie, at least from a brightness factor point of view.
Strange, Dexter Kane seems to have the opposite opinion. Might make sense to test with more movies? Of course it's difficult to interpret this number because it's usually much lower than 100nits. So which AvgFALL number should be assigned to which profile? But in theory it *SHOULD* be the most objective number of them all, because you just can't get any more honest than using the average of every pixel in every frame!

Quote:
Originally Posted by Manni01 View Post
I'll try to see if I can get good results with MaxFALL, possibly AVGFALL but I'd really like to get AVGScenePeakTW if at all possible, because when I looked at all the calculated data from the last cycle, it looked like the most promising/indicative/reliable data, that's why I asked for it.
FWIW, I know AvgFall and AvgFmll were reversed in your tests. But anyway, I'd like to explain that I think AvgFmll (true correct one) should be relatively near to AVGScenePeakTW. If it differs, AvgFmll should be "better". To make it clearer why, let me explain:

Let's say the whole movie consists of only 1 scene. In that case AVGScenePeakTW should have exactly the same values as "measured MaxCLL". If the movie had only 2 scenes, one of the scenes would have the same peak as MaxCLL, so AVGScenePeakTW would probably still be noticeably too high. Generally, using the scene peak has the problem that it will only count the brightest frame in each scene, totally ignoring all other frames in the same scene. AvgFmll does not have this problem: Instead of looking at each scene's peak, it looks at each frame's peak, and builds the average on that. So AvgFmll should be a bit lower than AvgScenePeakTW. It should be AvgFmll < AvgScenePeakTW < MaxCLL, because AvgFramePeak < AvgScenePeak < MoviePeak. Or in other words: In the same way that AvgScenePeakTW is better than MaxCLL, AvgFmll should be better than AvgScenePeakTW. Which is why I implemented AvgFmll instead of AvgScenePeakTW.

Quote:
Originally Posted by xxxx5 View Post
each time i delete the measurements file and play the file with mpc-hc or mpc-be (no kodi, no jriver)

in v26 i create a file in a d:\video_d\madvr_mesures : e.!audio_video_test!bt2020!The_World_in_HDR_in_4K_ HDR10.mkv.measurements was create and when i play the mkv all is ok i see frame/scene/movie xx/xx/xx nits tone maps xx nits in osd

if a do the same thing in v27 or 28

when i play the file i see : measured frame xx nites tone map xx nits.
i need to rename the file The_World_in_HDR_in_4K_HDR10.mkv.measurements and put it in the same folder as the mkv file to see again
frame/scene/movie xx/xx/xx nits tone maps xx nits
So you're saying madMeasureHDR.exe creates a file in "c:\video_d\madvr_measures", but this file is ignored during playback? If so, please create a debug log (then zip it and upload it for me to look at) when trying to play the video with MPC-HC, with the measurement file in "c:\video_d\madvr_measures". Just the first 2 seconds of playback are enough. Afterwards you can close MPC-HC.

Quote:
Originally Posted by quietvoid View Post
AvgFALL doesn't really work for some files. This is some measurements I got:

Dunkirk (2017)
Frames: 153404, MaxCLL 100%: 352, 99.9%: 328, 99.8%: 325, 99.0%: 317, MaxFALL: 270, AvgFALL: 38, AvgFMLL: 189
Ant-Man and the Wasp (2018)
Frames: 169978, MaxCLL 100%: 1098, 99.9%: 1017, 99.8%: 981, 99.0%: 805, MaxFALL: 862, AvgFALL: 9, AvgFMLL: 181

For Dunkirk you'd end up with a target peak nits that's too high, because the brightness is pretty consistent and there's little dark scenes.
For Ant-Man and the Wasp, MaxFALL is 862 which is pretty high so you'll end up compressing a lot of highlights.

So I think I'd agree with Manni that it's not really representative.
You're saying that Dunkirk has a high consistent brightness, and AvgFALL confirms that with 38 (which is relatively high value for AvgFALL). So why do you say that AvgFALL is not representative? I don't understand your logic here.

Nobody asks you to use a target peak nits setting of 38 in madVR for Dunkirk. The only purpose of AvgFALL is to allow you to pick a good profile. You're not supposed to use AvgFALL as your target peak nits setting.

Quote:
Originally Posted by clark17 View Post
FYI. I did (still crunching thru them) about 60 files and none of them reported negative AvgFALL.
Thanks, that's good to know.

Quote:
Originally Posted by Neo-XP View Post
It is extreme, but if you trust the "flicker risk" value and apply a very slow reaction time (5 seconds or more) when the flicker risk is high, it should not be an issue?
5 seconds is less than 100nits increase from a frame to the next (~83nits) to go from 0 nits to 10'000nits (the most extreme case).
Or is the "flicker risk" value not as reliable as I think it is?
I don't know how reliable the flicker risk is. It should be pretty good, but is it always perfect? I don't know, probably not.

Quote:
Originally Posted by Neo-XP View Post
Wasn't the purpose of the "flicker risk" value to remove this delay compared to APL-4?
The purpose of flicker risk was to improve the live algo. Of course it would be great to have everything work perfecty, but I'm not sure how realistic that is. The live algo simply does not know measurements of future frames in advance, and that's a problematic situation, because of which we have to accept that sometimes this limitation may cause small(ish) problems.

Quote:
Originally Posted by Neo-XP View Post
In "madVRhdrMeasure27" (with 0.1s): 9nits -> 242nits -> 488nits -> 691nits -> 942nits.
In "madVRhdrMeasure28": 8nits -> 152nits -> 229nits -> 349nits -> 553nits -> 925nits -> 942nits

That seems very slow to me, and the result is blown out highlights
But before I added APL4 and "flicker risk", our plan actually was to always use 0.25s for all movies. And then we found that this wouldn't work for Jurassic World and Matrix 2, where we needed *much* more (for Matrix 2 at least) than 0.25s.

So what we have now is near perfect playback for Harry Potter on the one side of the spectrum, and near perfect playback for Matrix 2 on the other side of the spectrum. So we're already much better than what we originally planned to do (always 0.25s)!

Quote:
Originally Posted by Neo-XP View Post
With the new logic, what would happen if the peak nits was ~4000 instead of ~1000 for a scene like Mother!?
Would it take even more time to adapt?
Yes, but not *much* more time. I'm actually applying the "brightness adjustment factor" in PQ, because PQ is more perceptually correct. Which means, the higher the Nits numbers, the faster I can adjust. You can see that in the Mother numbers: 152nits (+ 77nits = ) 229nits (+ 120nits = ) 349nits (+ 204nits = ) 553nits (+ 372nits = ) 925nits. So you can see that the nits increase gets higher and higher. So the next step up from 925nits would be somewhere around 1600nits, and then already above 3000nits.

Quote:
Originally Posted by Neo-XP View Post
The Matrix 2 scene analysis, might be interesting:

Static 5 seconds

Measured peak -> target
168 -> 203
477 -> 206
236 -> 206
360 -> 207
850 -> 212
720 -> 217
820 -> 222
877 -> 227
805 -> 232
756 -> 236
726 -> 241
784 -> 245
780 -> 250
577 -> 253
322 -> 253
211 -> 253
183 -> 253
169 -> 253

Dynamic

Measured peak -> target
157 -> 202
358 -> 203
175 -> 203
239 -> 204
865 -> 206
710 -> 207
839 -> 209
877 -> 210
805 -> 211
780 -> 213
710 -> 214
763 -> 216
813 -> 217
471 -> 219
317 -> 220
180 -> 220
164 -> 220
160 -> 220

Conclusion: Thanks madshi!

Edit2:

With stored measurements:

Measured peak -> target
157 -> 731
358 -> 738
175 -> 745
239 -> 750
865 -> 754
710 -> 757
839 -> 760
877 -> 761
805 -> 763
780 -> 763
710 -> 764
763 -> 763
813 -> 762
471 -> 761
317 -> 759
180 -> 756
164 -> 753
160 -> 749

If we can improve Mother! scene with the "live" dynamic HDR algo, I won't see any point to use the stored measurements algo, unless it is improved too
That's very weird - my results with stored measurements are *MUCH* more dynamic than yours! It starts at 195nits, goes up to 765nits, and then back down to 394nits. Are we testing with the same sample? And with the same madVR settings? Which target nits setting are you testing with? I tested with various nits settings to try to replicate your results. The numbers I wrote I got with 100nits target peak nits.

Quote:
Originally Posted by Neo-XP View Post
The Predator's outro scene is this time too fast:

Measured peak -> target
88 -> 119
152 -> 152
285 -> 204
564 -> 276
813 -> 382
905 -> 551
955 -> 837
955 -> 955
Which flicker risk do you get for these Predator frames?

Quote:
Originally Posted by Manni01 View Post
Yes because it takes into account the average brightness of the movie, not only the peak, which can be misleading even when corrected.

I need to compare both algos, but I expect AVGFmll to be more consistently correct than HDRVideoPeak.
AvgFmll should be better than HDRVideoPeak. However, it's only the average of the peaks of all the frames. It does *not* take the average brightness of all pixels in each frame into account. If you want the average brightness of the movies, you need to use a value with "FALL" in the name. Either "MaxFALL", or ideally "AvgFALL". In theory "AvgFALL" should be better than "MaxFALL" in the same way that "AvgFmll" should be better than "MaxCLL".

Quote:
Originally Posted by SamuriHL View Post
Not all, no. 9 of them and I don't see any pattern.

http://www.mediafire.com/file/9qrziy...Blonde.mkv.zip

I zipped one up so you can take a look and maybe see what's going on. Happy to help if you need any additional tests or information. Thanks!
Does this one fix it?

http://madshi.net/madVRsamuri.zip

Quote:
Originally Posted by soyhakan View Post
I installed madVRhdrMeasure28 and checked 2001 Space Oddssey again. The sun flickers very little. Looks like its improved now.
But maybe there is little flicker in source because it exist in sdr bluray versiyon also. Colors are different in sdr bluray.

I made sample file :
https://mega.nz/#!UJo2FSxT!5TL0NAsI1...XYAEXUIVMkV4eU

Also checked the gpu when madMeasureHDR.exe running. My gpu usage is 0% but cpu usage 100%.
In general settings tab "use Direct3D 11 for presentation" is checked

On Lav Video Hardware acc. Dxva2 (copy-back) selected. But selecting other options not really speed up the mesasuring.
Is there is a setting i'm not noticing?

Because madMeasureHDR.exe does not have a gui. I run it via htpccontrol.exe or simply drag-drop video file on it.
Thanks for the sample. Yes, it looks like it's in the source.

Try using "D3D11" with the "hardware device to use" set to "automatic (native)" in the LAV Video Decoder settings. The madVR settings don't matter much.
SamuriHL, clark17 and quietvoid like this.
madshi is online now  
post #4093 of 5925 Old 11-08-2018, 04:07 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
Quote:
Originally Posted by madshi View Post
Strange, Dexter Kane seems to have the opposite opinion. Might make sense to test with more movies? Of course it's difficult to interpret this number because it's usually much lower than 100nits. So which AvgFALL number should be assigned to which profile? But in theory it *SHOULD* be the most objective number of them all, because you just can't get any more honest than using the average of every pixel in every frame!
I'm not convinced with AVGFALL due to the closeness of the data for two harry potter movies that I've used as an example to show why it doesn't look very useful (AVGFALL of 10 and 11). Unless we use 100 different profiles, I don't see how we can implement something reliable with data that seems to have a range of 0-100 or so.

That's why I zeroed in on AVGFmll. Also I like the idea of integrating the peak into the algo, rather than the frame average.

Quote:
Originally Posted by madshi View Post
FWIW, I know AvgFall and AvgFmll were reversed in your tests. But anyway, I'd like to explain that I think AvgFmll (true correct one) should be relatively near to AVGScenePeakTW. If it differs, AvgFmll should be "better". To make it clearer why, let me explain:
You're late to the party and have missed a few posts . I've corrected this already, it was due to a bug in one of the utilities and the absence of log/feedback when using another. I resolved this using my batch files for measurements and looking at the OSD when I got home. There is no need for AvgScenePeakTW as far as I can see.

Anyway, let's see what the feedback is on both algos (Dexter Kane's and my latest one linked in my sig).

I'll measure 50 more files tomorrow while I'm at work to check a few more files.

Goodnight, and thanks again for all your good work

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
Manni01 is online now  
post #4094 of 5925 Old 11-08-2018, 04:08 PM
Member
 
Join Date: Oct 2018
Posts: 21
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 18 Post(s)
Liked: 5
Quote:
Originally Posted by madshi View Post
You're saying that Dunkirk has a high consistent brightness, and AvgFALL confirms that with 38 (which is relatively high value for AvgFALL). So why do you say that AvgFALL is not representative? I don't understand your logic here.
What I mean is that it's not very useful for profile switching (to retain as much highlight detail as possible).
Because a film very bright in only 1% of the frames would have a lower AvgFALL and that means lower target peak nits than a file with consistent brightness (but not necessarily brighter), so that bright 1% is gonna get compressed a lot.
At least that's my understanding of the purpose for profile switching.
quietvoid is online now  
post #4095 of 5925 Old 11-08-2018, 04:18 PM
AVS Forum Special Member
 
SamuriHL's Avatar
 
Join Date: Jan 2005
Posts: 4,855
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 49 Post(s)
Liked: 62
Quote:
Originally Posted by madshi View Post
Does this one fix it?

http://madshi.net/madVRsamuri.zip
Yup, that fixed it. Atomic Blonde AvgFALL: 23. Thank you, sir!
SamuriHL is online now  
post #4096 of 5925 Old 11-08-2018, 04:37 PM
Member
 
Join Date: Nov 2018
Posts: 172
Mentioned: 45 Post(s)
Tagged: 0 Thread(s)
Quoted: 111 Post(s)
Liked: 98
I'm pretty happy with my profile script, I've modified it a little just to add some more steps between 200 and 300 nits but the logic is basically the same. What I'm finding works well is to set target nits based on avgFall basically by multiplying it by 10 although I suspect a nonlinear multiplication would work better multiplying more when avgFall is lower and leveling off as it gets higher, and for a different display peak it may need to be higher or lower too. Anyway, target nits based on avgFall but then use avgFmll as a limiter to prevent it setting a target nits much higher than the peak of most scenes. Basically with a avgFmll higher than the target nits there will be more compression but also more scenes reaching the maximum display brightness, with avgFmll under the target nuts there is less compression but also less dynamic. For me I use avgFmll <= target nits as a limiter and it works well in the tests I've done so far.
Dexter Kane is offline  
post #4097 of 5925 Old 11-08-2018, 04:44 PM
Member
 
Join Date: Mar 2018
Posts: 52
Mentioned: 18 Post(s)
Tagged: 0 Thread(s)
Quoted: 43 Post(s)
Liked: 67
Quote:
Originally Posted by Manni01 View Post
@pandm1967 , please could you double check your utility and correct the label for AVGFALL and if at all possible display AVGFmll? Thanks!
Yes, you are right, my mistake, the newly added 2 DWORD in version 5 are "MAXFALL" and "AVGFALL".
Manni01, clark17 and quietvoid like this.

Last edited by pandm1967; 11-08-2018 at 05:34 PM.
pandm1967 is offline  
post #4098 of 5925 Old 11-08-2018, 05:14 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
Quote:
Originally Posted by pandm1967 View Post
Yes, you are right, my mistake, the newly added 2 DWORD in version 5 are "MAXFALL" and "AVGFALL".
Thanks!

So AVGFALL isn't available as a variable to display in the utility? It is displayed by MadMeasurementsHDR at the end of the measurements though, so it should be available? Also I think you were displaying it formerly instead of AVGFmll, so it must be available somewhere?

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
Manni01 is online now  
post #4099 of 5925 Old 11-08-2018, 05:17 PM
Member
 
Join Date: Apr 2018
Posts: 136
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 91 Post(s)
Liked: 10
This new build using Manni's profile is beautiful. Alone, it's just a little too dark for me. I am measured at a 154 peak nit, but am using 100 peak nits in madvr which is giving me the contrast and detail still there. Haven't tried my usual tests films, but what I am seeing so far looks really good.
Manni01 and clark17 like this.
toby5 is offline  
post #4100 of 5925 Old 11-08-2018, 05:45 PM
Member
 
Join Date: Mar 2018
Posts: 52
Mentioned: 18 Post(s)
Tagged: 0 Thread(s)
Quoted: 43 Post(s)
Liked: 67
Quote:
Originally Posted by Manni01 View Post
Thanks!

So AVGFALL isn't available as a variable to display in the utility? It is displayed by MadMeasurementsHDR at the end of the measurements though, so it should be available? Also I think you were displaying it formerly instead of AVGFmll, so it must be available somewhere?
The AVGFALL value is now displayed. The formerly displayed AVGFMLL is actually AVGFALL. Since AVGFMLL is not saved in the measurement file, it cannot be displayed at this time.

A small bug has been fixed. Please download again.
Attached Files
File Type: zip madMeasurementAnalyzer.zip (22.9 KB, 30 views)
Manni01 and clark17 like this.
pandm1967 is offline  
post #4101 of 5925 Old 11-08-2018, 06:45 PM
Advanced Member
 
Neo-XP's Avatar
 
Join Date: Jun 2018
Location: Switzerland
Posts: 803
Mentioned: 133 Post(s)
Tagged: 0 Thread(s)
Quoted: 554 Post(s)
Liked: 620
Quote:
Originally Posted by madshi View Post
That's very weird - my results with stored measurements are *MUCH* more dynamic than yours! It starts at 195nits, goes up to 765nits, and then back down to 394nits. Are we testing with the same sample? And with the same madVR settings? Which target nits setting are you testing with? I tested with various nits settings to try to replicate your results. The numbers I wrote I got with 100nits target peak nits.
I tested with 100nits target peak nits too, it is from "The Matrix Reloaded (2003) UHD scene 2", frames 221 to 238.

http://www.mediafire.com/file/9144q7...ene_2.mkv/file

Quote:
Originally Posted by madshi View Post
Which flicker risk do you get for these Predator frames?
With the dynamic algo:

1.34%
2.08%
2.16%
2.26%
2.03%
1.57%
1.06%
0.52%

But with the static algo and 5s of reaction time:

19.82%
20.06%
20.33%
20.60%
21.00%
21.32%
21.56%
21.90%

If you compare with Mother!, you don't get values this high with 5s of reaction time, they stay extremely low.
And 5s of reaction time will never be used for scenes like Mother! because the flicker risk is very low from the start (and stays very low, even more if you apply a very fast reaction time from the start).

But by applying a slower reaction time from the start for Predator's outro, the flicker risk stays very high.
For this scene, with the current algo, the luminance adaptation is very very noticeable with 100nits target peak nits.

That is that I was trying to explain here:

Quote:
Originally Posted by madshi View Post
@madshi what about reaction time [s] = "flicker risk" value? What would be the target values for Mother!, Harry Potter, Matrix 2 and Predator's outro scenes?
If I am not mistaken, the only way to know it is to test it for real, because the "flicker risk" value changes depending on the current target (which depends on the reaction time).
So reaction time [s] = "flicker risk" value could work better than the current algo to improve both ends?
A top end limit is not even needed IMO, or you can make it very high like 20s or so.

Last edited by Neo-XP; 11-08-2018 at 08:40 PM.
Neo-XP is offline  
post #4102 of 5925 Old 11-08-2018, 10:10 PM
Member
 
Join Date: Sep 2018
Posts: 46
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 26 Post(s)
Liked: 11
each time i delete the measurements file and play the file with mpc-hc or mpc-be (no kodi, no jriver)

in v26 i create a file in a d:\video_d\madvr_mesures : e.!audio_video_test!bt2020!The_World_in_HDR_in_4K_ HDR10.mkv.measurements was create and when i play the mkv all is ok i see frame/scene/movie xx/xx/xx nits tone maps xx nits in osd

if a do the same thing in v27 or 28

when i play the file i see : measured frame xx nites tone map xx nits.
i need to rename the file The_World_in_HDR_in_4K_HDR10.mkv.measurements and put it in the same folder as the mkv file to see again
frame/scene/movie xx/xx/xx nits tone maps xx nits

So you're saying madMeasureHDR.exe creates a file in "c:\video_d\madvr_measures", but this file is ignored during playback? If so, please create a debug log (then zip it and upload it for me to look at) when trying to play the video with MPC-HC, with the measurement file in "c:\video_d\madvr_measures". Just the first 2 seconds of playback are enough. Afterwards you can close MPC-HC.


here is the log
Attached Files
File Type: zip madVR - log.zip (935.6 KB, 9 views)
xxxx5 is offline  
post #4103 of 5925 Old 11-09-2018, 12:08 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
Quote:
Originally Posted by pandm1967 View Post
The AVGFALL value is now displayed. The formerly displayed AVGFMLL is actually AVGFALL. Since AVGFMLL is not saved in the measurement file, it cannot be displayed at this time.

A small bug has been fixed. Please download again.
Thanks. Your Average Frame Nits is in fact fairly close, you might want to check with Madshi's formula for AVGFmll because most of the time you're only a few nits away [EDIT: I checked a few titles, you seem to be the same or one nit below]. Then you could rename it AVGFmll to clarify it's the same data.

In any case, virtually you are displaying AVGFmll already, as the slight variation with your AVG Frame nits only makes a difference if it changes the threshold for profiles.

Is there a way to switch the debug console off if we don't need it?

EDIT: also would it be possible to make MaxFALL editable, the way MaxCLL is? This will be useful to correct some measurements file that still do not complete due to the MakeMKV bug. Thanks!

EDIT2: and would it be possible to change the app so that it accepts a file as an argument? I tried to set the default for .measurements files to your app, but when I double click on it, the selection for which app always appears, and if you select it then the app launches and it doesn't display the info for the file I double clicked on. IT would be great if we could set windows so that when we double click on a .measurements file, you app pops up and displays the info for the file.

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 11-09-2018 at 03:54 AM.
Manni01 is online now  
post #4104 of 5925 Old 11-09-2018, 12:44 AM - Thread Starter
AVS Forum Special Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 1,252
Mentioned: 188 Post(s)
Tagged: 0 Thread(s)
Quoted: 913 Post(s)
Liked: 1318
@madshi :

last update fixed back the Xmen apocalypse scene with a much more dynamic tone mapping target (like in V26) compared to V27.
Thank you.
Manni01 likes this.
Soulnight is online now  
post #4105 of 5925 Old 11-09-2018, 01:13 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
Quote:
Originally Posted by madshi View Post
Strange, Dexter Kane seems to have the opposite opinion. Might make sense to test with more movies? Of course it's difficult to interpret this number because it's usually much lower than 100nits. So which AvgFALL number should be assigned to which profile? But in theory it *SHOULD* be the most objective number of them all, because you just can't get any more honest than using the average of every pixel in every frame!
I've checked a few films to compare my algo's results and @Dexter Kane 's, and despite his clever use of AvgFmll as a limiter, I still think at this stage that it compresses highlights too much (to my taste) by focusing almost exclusively on the actual average brightness of the content.

There might be ways to improve my algo with the use of AvgFALL, but here are a few examples selecting more or less the same profile (200nits or 212nits) using Dexter's algo because AvgFALL is roughly identical (between 9 and 11) while mine based on AVGFmll selects a wider range of profiles (200 to 325nits) to give more room to the highlights and increase contrast/saturation, sure at the expense of absolute brightness, but to me it's about finding the best compromise.

When I look at the graphs for these examples, I would select the profile that my algo selects rather than a brighter profile that compresses the highlights similarly for all these titles. I'll try to check more films at the other end of the spectrum, maybe Dexter's algo is better there.

In () are (AvgFALL/AvgFmll)
Ant-Man and the Wasp (9/181) selects 200nits with Dexter's and 250nits with mine (don't have that disc so no screenshot).
Blade Runner (9/96) selects 200nits for both algos.
The Fifth Element (10/281) selects 212nits with Dexter's and 300nits with mine.
Harry Potter and the Deathly Hallow Part1 (10/373) selects 212nits with Dexter's and 325nits with mine.
Harry Potter and the Chamber of Secrets (11/281) selects 212nits with Dexter's and 275nits with mine.

This illustrates the lack of granularity I was talking about. Because the values for AvgFALL are so close to each other, it's very difficult to get the right target unless you have literally 100 of profiles, and even then you are compressing highlights more than you should (IMO), at least if you have any headroom to show them without getting a too dark picture.

I personally wouldn't be happy to use the same profile for Blade Runner 2049 (no highlights at all, very dim movie overall with a MaxFALL of 134 and a MaxCLL of 215) and Harry Potter and the Deathly Hallow Part 1 (MaxFALL 2008, MaxCLL 4098) or The Fifth Element (MaxFALL 530, MaxCLL 8379), both dim movies overall but with significant highlights.

As Dexter's target range is similar to mine (200-600nits), I assume that his display has a similar actual peak brightness to mine (around 100nits) in a similar environment (bat cave). If it wasn't the case and if he had a lower target peak and or was in a non-dedicated room, it could explain why he is happy with his algo which is consistently brighter for rather dim films, without taking into account how much highlights they contain to select a brightness factor.

@Dexter Kane , please can you tell us what your set-up is (actual peak brightness of your display/PJ if you know it, and type of display/room)? Thanks!

@Everyone : if your display is very dim ( @Soulnight , @clark17 ) and if you don't have much headroom for highlights, or if you are in a non-dedicated room with ambient light, you might prefer to use Dexter's algo as it compresses highlights further to privilege brightness, while I'm trying to find a better balance between the two.
Attached Thumbnails
Click image for larger version

Name:	Blade Runner 2049.JPG
Views:	27
Size:	726.0 KB
ID:	2479938   Click image for larger version

Name:	The 5th Element.JPG
Views:	20
Size:	537.3 KB
ID:	2479940   Click image for larger version

Name:	HP & The Deathly Hallow P1.JPG
Views:	17
Size:	619.1 KB
ID:	2479942   Click image for larger version

Name:	HP & The Chamber of Secrets.JPG
Views:	18
Size:	517.4 KB
ID:	2479944  

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 11-09-2018 at 03:55 AM.
Manni01 is online now  
post #4106 of 5925 Old 11-09-2018, 01:46 AM - Thread Starter
AVS Forum Special Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 1,252
Mentioned: 188 Post(s)
Tagged: 0 Thread(s)
Quoted: 913 Post(s)
Liked: 1318
@Manni01 : I agree with you that average pixels brightness of the whole movie (avgFALL) is not very usefull since from what I saw with my movies analysis, more than 90% of the pixels are in average below 100nits.

So the whole exercise is to know what to do with the 10% highlights above 100nits.

If you take the 90% of the pixels below 100nits, it just weights to heavily and compress A LOT what information you get about the 10% highlights.

Average frame Peak that I provide in the excel (now called avgFmLL by Madshi) is much more consistent at saying how bright are the peak through out the movie.
(it's of course always slightly lower than the "time weighted scene peak avg").
However, that's still a very basic statistic (but much better than maxFALL, avgFall or maxCLL).

Something that's even more representative that the basic "average frame peak / avgFmLL)" would be based on percentile.
For example, first calculate for each frame with the histogram, below what NITS number are 90% of the pixels:
-->you get with that what I call: the 90% percentile frame peak
and then of course you can do the average of this 90% percentile frame peak over each frame of the movie.
--> what I call: avg 90,00% percentile frame peak

In our excel with provide the number for various percentile per frame:
avg 90,00% percentile frame peak
avg 99,00% percentile frame peak
avg 99,90% percentile frame peak
avg 99,95% percentile frame peak
avg 99,98% percentile frame peak
avg 99,99% percentile frame peak

With this kind of numbers, you avoid building an average of the frame peak which may be based on a few stray bright pixels only.
avg 99,99% percentile frame peak, already provides a significantly lower number than the basic frame peak avg, because we have eliminated those 0,01% brightest pixels for each frame.
----
Of course we could be even more movie representative, if we would:
1) calculate 99,99% percentile frame peak for each frame
2) then we would calculate what is the 99,99 percentile frame peak for which 99,99% of the frames of the movie peak out
3) and then build the average of the 99,99 percentile frame peak for those 99,99% frames of the movie

Like this you would sort out
a) the stray pixel per frame
b) the stray frame per movie

----

Another approach would be look at at percentile NITS of "highlights pixels".
If we define 100nits as the highlights limit (since we have seen than in avg more than 90% of all the pixels of a movie are below 100nits).
We can then look at the distribution of those highlights.

For a movie like "Blade Runner 2049" or "The Mountain Between us", most frame peaks below 100nits.
So if we would look at the 50% percentile NITS of the highlights above 100nits, we would very likely end up with 100 nits (lower limit).

But for brighter movie, those 10% highlights would be distributed to much higher nits.
And the median of the highlights could become a very good indicator.

I am saying median, but who knows, maybe 10% percentile of the highlights or 90% percentile of the highlights would be even better.

Anyway, avg frame peak while basic statistic is already muuuuch better than maxCLL and maxFALL to use.
So my thanks to @madshi to make it directly selectable as profile variable

Manni01 and clark17 like this.

Last edited by Soulnight; 11-09-2018 at 02:25 AM.
Soulnight is online now  
post #4107 of 5925 Old 11-09-2018, 02:00 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
Thanks, I mostly agree with the above in principle.

From a practical point of view, I'm very happy with the results given by AVGFmll. Far better than anything we had before to select a profile, and "good enough" for now.

What I'm curious about is what Madshi has in mind for the "final destination".

The current profile selecting algo based on AVGFmll makes it 100% possible for me to wait happily until we finish work on the next stage, which was the main reason why I requested a few more variables to test after the measurements file breakthrough. I'm very grateful to Madshi that he took some time to do so (and grateful to you and Anna and the other utility developers for all the data provided), and extremely happy with the preliminary results, even if more testing/feedback is needed.

Now I'll wait for Madshi to tell us when he's ready to start the next stage. He has got a lot of information from all the measurements files experiments (including what you just suggested above), and I'm not sure he's entirely ready or willing to discuss this further at the moment, so I'd rather wait for his prompt.
clark17 likes this.

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 11-09-2018 at 02:24 AM.
Manni01 is online now  
post #4108 of 5925 Old 11-09-2018, 03:56 AM
Member
 
BerndFfm's Avatar
 
Join Date: Jan 2018
Location: Frankfurt / Main, Germany
Posts: 99
Mentioned: 19 Post(s)
Tagged: 0 Thread(s)
Quoted: 94 Post(s)
Liked: 104
Small update:

- No reading of the measurement file if logfile exists
- Better structure in the log file
- Entry in the "NotCompleted" file if "Not completed" or if MaxCLL is 0.
- Better scaling of the settings dialog

Download: http://download.seven-c.de/files/madvr/htpccontrol.zip

Manni : I write the whole output of madMeasureHDR in my logfile, e.g.

Code:
Measurement File : e:\Movies4K\Alien 5 - Alien Covenant (2017)\ALIEN__COVENANT.Title800.mkv.measurements
Created : 09.11.2018 11:37:24

using D3D11 (native)
Metadata: Mastering display peak brightness: 1000, MaxCLL: 0, MaxFALL: 0
Measurements: Frames: 175563, MaxCLL 100%: 1217, 99.9%: 1132, 99.8%: 1122, 99.0%: 938, MaxFALL: 744, AvgFALL: 12, AvgFMLL: 402

Scene Count : 4978
Frames Count : 175563
Duration : 02:02:02
Completed : 1
MaxCLL : 1217
Meta Data Mastering Display Luminance min: 0.0050 nits, max: 1000 nits
Meta Data MaxCLL 0 MaxFALL 0

Average scene peak nits : 517
Time Weighted avg. scene peak nits : 493
Max peak nits (00:43:10-00:43:10) : 1217
Max peak nits without trailer/credits (00:43:10-00:43:10) : 1217
 2. peak nits (00:43:10-00:43:10) : 1206
 3. peak nits (00:50:28-00:50:29) : 1195
 3. peak nits (00:54:16-00:54:17) : 1195
Bernd
Manni01 and clark17 like this.

Home Cinema with : Onkyo 1009, Nubert, JVC RS-500, madVR
BerndFfm is offline  
post #4109 of 5925 Old 11-09-2018, 04:04 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 8,934
Mentioned: 305 Post(s)
Tagged: 0 Thread(s)
Quoted: 5311 Post(s)
Liked: 5303
Quote:
Originally Posted by BerndFfm View Post
Small update:

- No reading of the measurement file if logfile exists
- Better structure in the log file
- Entry in the "NotCompleted" file if "Not completed" or if MaxCLL is 0.
- Better scaling of the settings dialog

Download: http://download.seven-c.de/files/madvr/htpccontrol.zip

Manni : I write the whole output of madMeasureHDR in my logfile, e.g.

Code:
Measurement File : e:\Movies4K\Alien 5 - Alien Covenant (2017)\ALIEN__COVENANT.Title800.mkv.measurements
Created : 09.11.2018 11:37:24

using D3D11 (native)
Metadata: Mastering display peak brightness: 1000, MaxCLL: 0, MaxFALL: 0
Measurements: Frames: 175563, MaxCLL 100%: 1217, 99.9%: 1132, 99.8%: 1122, 99.0%: 938, MaxFALL: 744, AvgFALL: 12, AvgFMLL: 402

Scene Count : 4978
Frames Count : 175563
Duration : 02:02:02
Completed : 1
MaxCLL : 1217
Meta Data Mastering Display Luminance min: 0.0050 nits, max: 1000 nits
Meta Data MaxCLL 0 MaxFALL 0

Average scene peak nits : 517
Time Weighted avg. scene peak nits : 493
Max peak nits (00:43:10-00:43:10) : 1217
Max peak nits without trailer/credits (00:43:10-00:43:10) : 1217
 2. peak nits (00:43:10-00:43:10) : 1206
 3. peak nits (00:50:28-00:50:29) : 1195
 3. peak nits (00:54:16-00:54:17) : 1195
Bernd
Thanks!

Two questions:

1) Is this output in the .txt file in each measured files folder?
2) Which settings do we need to check so that you generate a .txt log file for each file from the measurements file, when it already exists, without having the utility to remeasure it?

As it's not possible to get the completion progress using your utility, which is an important element for my use, I'm using my batch files to generate the measurements files now.

But it would be great to get the detailed info in a .txt log file in each measured file's folder, so I'd love to use your utility to do a pass to generate the log files from the measurements file when they exist.

Alternatively, if Madshi could output the summary that MadMeasurementsHDR displays at the end into a .txt file, that would be great. Maybe with a /log parameter to make it optional?

[EDIT: no worries, I have found a solution to create the log with my batch files AND keep real-time progress, I will post revised files soon]

JVC Autocal Software V11 Calibration for 2019 Models
Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders

Last edited by Manni01; 11-09-2018 at 05:35 AM.
Manni01 is online now  
post #4110 of 5925 Old 11-09-2018, 04:26 AM
Advanced Member
 
clark17's Avatar
 
Join Date: Jan 2009
Location: Ottawa - Ontario
Posts: 702
Mentioned: 7 Post(s)
Tagged: 0 Thread(s)
Quoted: 158 Post(s)
Liked: 74
@madshi
Great job with last v28 algo. I spent maybe an hour last along with @Manni01 new profile night trying different movies and I haven’t noticed anything that would stood out like weird flickering etc. I really like the new avgFmLL variable on which we pick our target peak nits profiles. I think @Soulnight also likes it. Both of us using 50nits displays. Also my flick collection v28 measurement sweep finished, without any negative values for avgFALL. I have a couple of incomplete measurement files and a couple could not be create flicks, but that is ripping problem, which I will address in the future. Thanks again for all your hard work!

@Manni01
Your new profiles work very well. (mind you I cut everything in half, being 50nits guy). I tried about 20-30 different titles with different avgFmLL values to test different profiles, and I’m very happy with the end results. I do agree with you that even at 50nits I don’t mind sacrificing a tad of brightness to get more/better highlight recovery. I will test it more on the weekend and if I encounter any major problems I will let you know. Again last night I had problem (nothing to do with madVR) where my projector after starting movie would kick in into magenta colors  I will send you PM as I don’t want to pollute this thread with not related topics.

EDIT: cannot send PM to Manni01 Manni assuming this is the JVC magenta problem you were describing before, what NVidia drivers are you using to avoid the issue?
Manni01 and Dexter Kane like this.

Last edited by clark17; 11-09-2018 at 04:29 AM.
clark17 is offline  
Sponsored Links
Advertisement
 
Reply Digital Hi-End Projectors - $3,000+ USD MSRP

Tags
hdr , madvr , sdr , ton mapping

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

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
Trackbacks are Off
Pingbacks are Off
Refbacks are Off