Improving Madvr HDR to SDR mapping for projector - Page 109 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 7200Likes
Reply
 
Thread Tools
post #3241 of 7841 Old 10-20-2018, 06:09 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,292
Mentioned: 354 Post(s)
Tagged: 0 Thread(s)
Quoted: 5596 Post(s)
Liked: 5887
Quote:
Originally Posted by madshi View Post
But the official v0.92.17 works fine?


Sounds promising. So maybe you can now use a target nits value of ~200nits for the Revenant, too? That would be roughly the 2:1 compression factor you were aiming for, right?
I had tried to set my default for 1000nits titles to 250nits, and it works well for some very dark movies, but for the Revenant I still prefer around 300-350nits. 200-250nits feels too flat/bright here. Of course we need 200nits for the campfire scene, so unfortunately it looks like we still need a proper 2:1 factor for 0-100nits or similar and a higher factor for the rest of the curve. Also even if we could use 200nits target for up to 1000nits titles, this is definitely not an option for brighter titles, so I don’t see a way around specific handling of the low end (preferably in a non dynamic way as far as I’m concerned).

Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
JVC Macro feature on Vertex/Vertex2/Integral2/Maestro

Last edited by Manni01; 10-20-2018 at 06:15 PM.
Manni01 is offline  
Sponsored Links
Advertisement
 
post #3242 of 7841 Old 10-21-2018, 02:22 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,846
Mentioned: 568 Post(s)
Tagged: 0 Thread(s)
Quoted: 2735 Post(s)
Liked: 3817
Quote:
Originally Posted by madshi View Post
new test build

http://madshi.net/madVRhdrMeasure11.zip

[...]

For the "darkness" options, I think probably higher/slower is generally better, to avoid unnecessary image pumping. But you can test what works well for you.
Quote:
Originally Posted by Neo-XP View Post
When setting everything to no delay/immediately, I get bad flickering with Murder on the Orient Express at 00:59:34.

Edit2:

It is way better if I add some darkness delay / reaction time. Then, I don't get flickering, just brightness jumps.
Quote:
Originally Posted by madshi View Post
Yes, you can't use "no delay/immediately" for both "darkness" and "brightness" at the same time, or else you'll get flickering.
Quote:
Originally Posted by madshi View Post
And I'm not sure if I like the idea to do darkness changes faster, too. I think it might be less dangerous to do them quite slowly, and *with* a delay. Or are you aware of any scenes where the slow darkness change produces visible problems?
Quote:
Originally Posted by Neo-XP View Post
0.25 causes visible brightness jumps
Quote:
Originally Posted by madshi View Post
Did you get those brightness jumps only with "fast" darkness values, or also with the default (rather slow) darkness values?
Quote:
Originally Posted by Neo-XP View Post
Yes, only with no delay + immediate for darkness.

I don't get them if I use 1 second for the darkness reaction time
How often do I have to repeat that I recommend using darkness delay + slow darkness reaction times??

Could you kindly revert to default darkness values (2 seconds delay, 5 seconds reaction time) and leave them untouched for a while?

So with default darkness values, is there any brightness settings combination which works for Harry Potter for you, and does not cause brightness jumps (or other artifacts) in other scenes/movies?

Thanks!

Quote:
Originally Posted by Manni01 View Post
I had tried to set my default for 1000nits titles to 250nits, and it works well for some very dark movies, but for the Revenant I still prefer around 300-350nits. 200-250nits feels too flat/bright here. Of course we need 200nits for the campfire scene, so unfortunately it looks like we still need a proper 2:1 factor for 0-100nits or similar and a higher factor for the rest of the curve. Also even if we could use 200nits target for up to 1000nits titles, this is definitely not an option for brighter titles, so I don’t see a way around specific handling of the low end (preferably in a non dynamic way as far as I’m concerned).
Ok.
madshi is online now  
post #3243 of 7841 Old 10-21-2018, 03:28 AM
AVS Forum Special Member
 
Neo-XP's Avatar
 
Join Date: Jun 2018
Location: Switzerland
Posts: 1,129
Mentioned: 193 Post(s)
Tagged: 0 Thread(s)
Quoted: 854 Post(s)
Liked: 1176
Quote:
Originally Posted by madshi View Post
So with default darkness values, is there any brightness settings combination which works for Harry Potter for you, and does not cause brightness jumps (or other artifacts) in other scenes/movies?
Those are the only settings that work (with default darkness values) for HP, without causing too much artifacts:

brightness delay: no delay
brightness reaction time: 0.1s
darkness delay: 2s
darkness reaction time: 5s

I still notice a small luminance drop with Murder on the Orient Express at 00:59:34, right after the cut, when the peak jumps from 154 to 197 nits.

And of course a big drop with Predator's intro, right after the fade in to the helicopter.

Last edited by Neo-XP; 10-21-2018 at 03:34 AM.
Neo-XP is offline  
Sponsored Links
Advertisement
 
post #3244 of 7841 Old 10-21-2018, 03:32 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,846
Mentioned: 568 Post(s)
Tagged: 0 Thread(s)
Quoted: 2735 Post(s)
Liked: 3817
Quote:
Originally Posted by Neo-XP View Post
Those are the only settings that work (with default darkness values) for HP, without causing too much artifacts:

brightness delay: no delay
brightness reaction time: 0.1s
darkness delay: 2s
darkness reaction time: 5s

I still notice a small luminance drop with Murder on the Orient Express at 00:59:34, right after the cut, when the peak jumps from 154 to 197 nits.

And of course a big drop with Predator's intro, right after the fade in to the helicopter.
Thanks, that's helpful! So we have two different scenes here: Murder wants a slower brightness reaction time, HP wants a faster one. Could your idea of changing the brightness reaction time depending on histogram changes help here? How much does the histogram change for the HP and Murder scenes?

(Of course one problem with the histogram change idea is that the amount of change will differ from frame to frame, so I may have to adjust the brightness reaction times constantly during the same scene.)
madshi is online now  
post #3245 of 7841 Old 10-21-2018, 03:57 AM
AVS Forum Special Member
 
Neo-XP's Avatar
 
Join Date: Jun 2018
Location: Switzerland
Posts: 1,129
Mentioned: 193 Post(s)
Tagged: 0 Thread(s)
Quoted: 854 Post(s)
Liked: 1176
Quote:
Originally Posted by madshi View Post
Thanks, that's helpful! So we have two different scenes here: Murder wants a slower brightness reaction time, HP wants a faster one. Could your idea of changing the brightness reaction time depending on histogram changes help here? How much does the histogram change for the HP and Murder scenes?

(Of course one problem with the histogram change idea is that the amount of change will differ from frame to frame, so I may have to adjust the brightness reaction times constantly during the same scene.)
Murder stays under 1% of lum changes

The Harry Potter scene is at minimum 5% lum changes where it would need to react in 0.1s to hide the artifacts, but with higher changes just not catched by the scene detection (max 9.70%).

The Predator's intro stays under 2-3% (2.69% max) where it would need to react in 5s to completely hide the artifacts and the slow luminance drop.

But if the brightness/darkness delay is immediate, the Harry potter scene changes a lot (~7% lum changes overall for the few frame that are causing the issue), while the Predator's intro stays calm (most of the time under 2%), so it should adapt (in theory) ?

Also, could it be worse to add a delay before madVR reacts?
I mean... when the nits peak is increasing/decreasing progressively, madVR don't do anything during this delay and then has to adapt faster to catch up.
For the same reaction time, if it reacts immediately, it has more time to adapt, hence less visible brightness change from frame to frame?

For "darkness", if the reaction time is slow enough not to notice the increase in brightness (let's say 5s), adding a delay will just make us lose the image dynamic, without any benefice?

For me, "luminance" and "darkness" are equally important for the dynamic HDR.

Something exponential like this to be safe?

y = reaction time [s]
x = luminance change [%]

y = 12,5*(e^(-0,644*x))

luminance change -> reaction time
0% -> 12.5s
2.5% -> 2.5s
5.0% -> 0.5s
7.5% -> 0.1s
10.0% -> 0.02s (0s)

Just adapting with the latest tests.

Edit:

This scene from Mother! needs an immediate reaction time not to blown out highlights: https://www.mediafire.com/file/g7wbt...ene_1.mkv/file
0.05s is not fast enough (358nits target for a measured peak of 707nits), but probably acceptable.

Problem: the luminance graph does not change much

So my solution will not work better than the current one, this is the best I came up with:

brightness delay: no delay
brightness reaction time: 0.1s (causes minor brightness jumps, but slower reaction times blow out highlights too much)
darkness delay: no delay
darkness reaction time: 5s (slow enough not to notice the increase in brightness, fast enough not to cause a lot of dynamic loss)

To test one of the minor brightness jumps (with default darkness values), Jurassic World: Fallen Kingdom at 00:18:19.


Edit2:

A possible solution to improve and protect the current algo: (only for brightness) applying a slow reaction time when the nits peak change is small and a fast one when it is big?

Or more precisely, when the difference between the current target and the measured peak is small/big?
Manni01 likes this.

Last edited by Neo-XP; 10-21-2018 at 09:20 AM.
Neo-XP is offline  
post #3246 of 7841 Old 10-21-2018, 04:13 AM
AVS Forum Special Member
 
stevenjw's Avatar
 
Join Date: Jul 2001
Location: Palm Coast, Florida, USA
Posts: 2,961
Mentioned: 8 Post(s)
Tagged: 0 Thread(s)
Quoted: 647 Post(s)
Liked: 870
Quote:
Originally Posted by Chronoptimist View Post
I've been busy and have not had a chance to catch up with the latest builds yet, but something changed between madVRhdrSat5 and madVRhdrMeasure1 which causes JRiver Media Center to freeze on a black screen when stopping playback.
For what it's worth, I was experiencing the same thing before I fixed my network throughput issue. JRiver would freeze if I hit stop. I could get the top menu to show and close the display, but it would not stop the movie fully so I couldn't play it or another title again. I had to recycle MC to play anything again. I did find that if I fast forwarded the title to near the end, it would stop normally and work, but just not during playback using the stop button. And this was not all the time, but frequent when I was having issues and testing setting changes. The problem is gone now that I improved my network speed which stopped the stuttering playback.

...Steve
"Opinions are like orgasms… mine matters most and I really don’t care if you have one or not." ;)
 
My HT gear
stevenjw is offline  
post #3247 of 7841 Old 10-21-2018, 10:14 AM
AVS Forum Special Member
 
Chronoptimist's Avatar
 
Join Date: Sep 2009
Posts: 3,118
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 557
Quote:
Originally Posted by madshi View Post
But the official v0.92.17 works fine?
The official build works fine, as does madVRhdrSat5. It's something that changed with the madVRhdrMeasure builds.

Quote:
Originally Posted by stevenjw View Post
For what it's worth, I was experiencing the same thing before I fixed my network throughput issue. JRiver would freeze if I hit stop. I could get the top menu to show and close the display, but it would not stop the movie fully so I couldn't play it or another title again. I had to recycle MC to play anything again. I did find that if I fast forwarded the title to near the end, it would stop normally and work, but just not during playback using the stop button. And this was not all the time, but frequent when I was having issues and testing setting changes. The problem is gone now that I improved my network speed which stopped the stuttering playback.
That seems like a different issue. Everything is local playback on my machine.
stevenjw likes this.

Last edited by Chronoptimist; 10-21-2018 at 10:22 AM.
Chronoptimist is offline  
post #3248 of 7841 Old 10-21-2018, 11:14 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,846
Mentioned: 568 Post(s)
Tagged: 0 Thread(s)
Quoted: 2735 Post(s)
Liked: 3817
@Neo-XP :

Hmmmm... I think I prefer blowing out highlights for 1-2 frames over visible (even if faint) brightness jumps. Can we try to find the fastest brightness reaction time setting which does not cause any visible brightness jumps? For that purpose I've uploaded build 13 here, with added 0.015 and 0.020 options:

http://madshi.net/madVRhdrMeasure13.zip

Your argument for the "delay" setting does make sense. However, please also take into account that the peak measurements often jitter around quite a bit. So they may appear to go up for a short time, then they go down again for a short time, then up, then down. Without a delay, the tone mapping "target" will change all the time between higher and lower values, which may cause the image to appear slightly unstable. The delay helps stabilizing the overall image. I guess we can't use the delay if the image gets brighter, though, because that will cause too much problems with blown out highlights. But I think if the image gets darker, we should take our time to adjust, to make the image overall more stable.

Quote:
Originally Posted by Chronoptimist View Post
The official build works fine, as does madVRhdrSat5. It's something that changed with the madVRhdrMeasure builds.
Ok, will check if I can reproduce the issue here.
stevenjw, Manni01 and Neo-XP like this.
madshi is online now  
post #3249 of 7841 Old 10-21-2018, 11:53 AM
AVS Forum Special Member
 
Neo-XP's Avatar
 
Join Date: Jun 2018
Location: Switzerland
Posts: 1,129
Mentioned: 193 Post(s)
Tagged: 0 Thread(s)
Quoted: 854 Post(s)
Liked: 1176
Quote:
Originally Posted by madshi View Post
@Neo-XP :

Hmmmm... I think I prefer blowing out highlights for 1-2 frames over visible (even if faint) brightness jumps. Can we try to find the fastest brightness reaction time setting which does not cause any visible brightness jumps? For that purpose I've uploaded build 13 here, with added 0.015 and 0.020 options:

http://madshi.net/madVRhdrMeasure13.zip
I definitely can see it at frame 79 here with 0.1s : http://www.mediafire.com/file/9vb64u...ene_1.mkv/file

I don't see it with 0.15s... it seems... hard to say for sure. Others can confirm maybe.

What do you think about slower reaction times for small nits peak changes (like this one) and faster ones for big changes (like with Harry Potter, Mother!, etc.)?
I also noticed that the image "feels" more stable with slower reaction times, but not necessarily with longer delays.
Neo-XP is offline  
post #3250 of 7841 Old 10-21-2018, 03:03 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,846
Mentioned: 568 Post(s)
Tagged: 0 Thread(s)
Quoted: 2735 Post(s)
Liked: 3817
Quote:
Originally Posted by Neo-XP View Post
I definitely can see it at frame 79 here with 0.1s : http://www.mediafire.com/file/9vb64u...ene_1.mkv/file

I don't see it with 0.15s... it seems... hard to say for sure. Others can confirm maybe.
0.1s is really bad. 0.15s is much better, but I think I still see it a bit. At 0.20s it seems ok. Still not perfect, maybe, but good enough.

Quote:
Originally Posted by Neo-XP View Post
What do you think about slower reaction times for small nits peak changes (like this one) and faster ones for big changes (like with Harry Potter, Mother!, etc.)?
What about Predator, though? It has big peak changes, too. The peak measurement changes in Predator are pretty similar to Harry Potter.

Quote:
Originally Posted by Neo-XP View Post
I also noticed that the image "feels" more stable with slower reaction times, but not necessarily with longer delays.
Did you find any scenes where the darkness delay produced visible problems? To give you some numbers:

without darkness delay with darkness delay

100 -> 100 -> 100
110 -> 110 -> 110
120 -> 120 -> 120
90 -> 115 -> 120
80 -> 110 -> 120
90 -> 105 -> 120
110 -> 110 -> 120
120 -> 120 -> 120
130 -> 130 -> 130
110 -> 125 -> 130
100 -> 120 -> 130
90 -> 115 -> 130
80 -> 110 -> 130
80 -> 105 -> 130
90 -> 100 -> 130
110 -> 110 -> 130
130 -> 130 -> 130

Do you see the purpose of the darkness delay? It really helps making things much more stable. FWIW, HDR10+ would have this whole scene tone mapped at 130nits. So the darkness delay helps a lot getting nearer to HDR10+. The only *big* disadvantages I see are that: 1) If madVR misses a true scene change, the darkness delay will cause madVR to take longer to adjust to a new darker scene. And 2) if a scene gets darker without a scene cut, madVR takes longer to adjust. But in situation 2), HDR10+ would probably not adjust at all - but keep tone mapping at each scene's peak luminance! So I'm not actually sure if the darkness delay has any real big disadvantages?
madshi is online now  
post #3251 of 7841 Old 10-21-2018, 03:49 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,292
Mentioned: 354 Post(s)
Tagged: 0 Thread(s)
Quoted: 5596 Post(s)
Liked: 5887
Quote:
Originally Posted by madshi View Post
0.1s is really bad. 0.15s is much better, but I think I still see it a bit. At 0.20s it seems ok. Still not perfect, maybe, but good enough.


What about Predator, though? It has big peak changes, too. The peak measurement changes in Predator are pretty similar to Harry Potter.


Did you find any scenes where the darkness delay produced visible problems? To give you some numbers:

without darkness delay with darkness delay

100 -> 100 -> 100
110 -> 110 -> 110
120 -> 120 -> 120
90 -> 115 -> 120
80 -> 110 -> 120
90 -> 105 -> 120
110 -> 110 -> 120
120 -> 120 -> 120
130 -> 130 -> 130
110 -> 125 -> 130
100 -> 120 -> 130
90 -> 115 -> 130
80 -> 110 -> 130
80 -> 105 -> 130
90 -> 100 -> 130
110 -> 110 -> 130
130 -> 130 -> 130

Do you see the purpose of the darkness delay? It really helps making things much more stable. FWIW, HDR10+ would have this whole scene tone mapped at 130nits. So the darkness delay helps a lot getting nearer to HDR10+. The only *big* disadvantages I see are that: 1) If madVR misses a true scene change, the darkness delay will cause madVR to take longer to adjust to a new darker scene. And 2) if a scene gets darker without a scene cut, madVR takes longer to adjust. But in situation 2), HDR10+ would probably not adjust at all - but keep tone mapping at each scene's peak luminance! So I'm not actually sure if the darkness delay has any real big disadvantages?
Also, if we do find a solution for 0-100nits, we won't need to finetune darkness delay because the low end will be shown without any fluctuation. It's really the part of the picture where we need the most stability, so I've kept the default of 2s / 5s for now. I'm all up for faster changes in the top end, but I prefer rock stable at the low end. Otherwise it becomes too noticeable (and possibly wrong regarding the filmmaker's intent).

If 0-100nits is shown with a lower brightness factor than 100-maxCLL, there should be no need to change the tonemapping of the low end during the whole film.
stevenjw likes this.

Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
JVC Macro feature on Vertex/Vertex2/Integral2/Maestro
Manni01 is offline  
post #3252 of 7841 Old 10-21-2018, 07:36 PM
AVS Forum Special Member
 
Neo-XP's Avatar
 
Join Date: Jun 2018
Location: Switzerland
Posts: 1,129
Mentioned: 193 Post(s)
Tagged: 0 Thread(s)
Quoted: 854 Post(s)
Liked: 1176
Quote:
Originally Posted by madshi View Post
0.1s is really bad. 0.15s is much better, but I think I still see it a bit. At 0.20s it seems ok. Still not perfect, maybe, but good enough.
You seem more sensitive than I do to spot this.
I will set it to 0.25s to be safe.

Quote:
Originally Posted by madshi View Post
What about Predator, though? It has big peak changes, too. The peak measurement changes in Predator are pretty similar to Harry Potter.
The nits peak in Predator's intro is not increasing has fast as in the Harry Potter scene, so this can work maybe to improve both:

Difference between nits peak and target -> reaction time
000 -> slow (2.00s)
100 -> 1.00s
200 -> 0.50s
300 -> 0.25s
400 -> 0.125s
500 -> immediate

Scenes like the Jurassic Park one should also be more stable.

Quote:
Originally Posted by madshi View Post
Did you find any scenes where the darkness delay produced visible problems?
No, but I am thinking those numbers would be different by applying a slower reaction time (2s) for "brightness" for small nits peak changes
It would help to stabilize the image even more. It looks like you used a very fast reaction time for "brightness" in this test.
What would those numbers be with a reaction time of 5s for "darkness" and 2s for "brightness"?

Last edited by Neo-XP; 10-21-2018 at 07:41 PM.
Neo-XP is offline  
post #3253 of 7841 Old 10-22-2018, 02:58 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,846
Mentioned: 568 Post(s)
Tagged: 0 Thread(s)
Quoted: 2735 Post(s)
Liked: 3817
Quote:
Originally Posted by Neo-XP View Post
The nits peak in Predator's intro is not increasing has fast as in the Harry Potter scene
The difference is pretty small. See here:

Predator:
148 + 16% =
171 + 56% =
267 + 57% =
418 + 43% =
596 + 14% =
682 + 7% =
733 + 5% =
767 + 6% =
816 + 4% =
846

Goblet of Fire:
173 + 27% =
220 + 19% =
261 + 59% =
415 + 84% =
763 + 3% =
784 + 14% =
893 + 64% =
1468 + 15% =
1695 + 0% =
1695 + 8% =
1829 + 14% =
2093 + 16% =
2438 + 18% =
2867 + 1% =
2893

Quote:
Originally Posted by Neo-XP View Post
I am thinking those numbers would be different by applying a slower reaction time (2s) for "brightness" for small nits peak changes
It would help to stabilize the image even more. It looks like you used a very fast reaction time for "brightness" in this test.
What would those numbers be with a reaction time of 5s for "darkness" and 2s for "brightness"?
Of course any slowdown will make things more stable. But if you don't use any delay, the tone mapping target will *never* be completely stable. It will always go up and down all the time, never staying the same. The delay allows is to stay completely identical for relatively long periods of time, cleaning up most jitter completely. Also, as I said, the darkness delay makes the whole tone mapping much nearer to HDR10+ (or to how madVR would behave if it knew all measurements in advance).
madshi is online now  
post #3254 of 7841 Old 10-22-2018, 10:28 AM
AVS Forum Special Member
 
Neo-XP's Avatar
 
Join Date: Jun 2018
Location: Switzerland
Posts: 1,129
Mentioned: 193 Post(s)
Tagged: 0 Thread(s)
Quoted: 854 Post(s)
Liked: 1176
Quote:
Originally Posted by madshi View Post
The difference is pretty small
The Predator's intro can not be fixed I guess, it can just be improved a bit so it is less noticeable.

But all other calm scenes can be stabilized with this trick I think, and that is the most important thing.
Having a 0.25s delay for calm scenes is very dangerous IMO, the image "feels" more stable with longer reaction times.
And as a bonus, it can avoid to blow out highlights.

Quote:
Originally Posted by madshi View Post
Of course any slowdown will make things more stable. But if you don't use any delay, the tone mapping target will *never* be completely stable. It will always go up and down all the time, never staying the same. The delay allows is to stay completely identical for relatively long periods of time, cleaning up most jitter completely. Also, as I said, the darkness delay makes the whole tone mapping much nearer to HDR10+ (or to how madVR would behave if it knew all measurements in advance).
Of course, it is not necessarily a bad thing for darkness. You lose dynamic, but you gain stability.

I was saying this:

Quote:
Originally Posted by madshi View Post
I also noticed that the image "feels" more stable with slower reaction times, but not necessarily with longer delays.
for brightness.

For darkness, I am using darkness delay 2s + darkness reaction time 5s.

Last edited by Neo-XP; 10-22-2018 at 10:37 AM.
Neo-XP is offline  
post #3255 of 7841 Old 10-22-2018, 11:01 AM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,292
Mentioned: 354 Post(s)
Tagged: 0 Thread(s)
Quoted: 5596 Post(s)
Liked: 5887
Quote:
Originally Posted by Neo-XP View Post
Having a 0.25s delay for calm scenes is very dangerous IMO, the image "feels" more stable with longer reaction times.
Not sure I understand you here. Minimum delay is 1s, did you mean reaction time? And what do you mean by "very dangerous"? Can you clarify? Thanks!

Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
JVC Macro feature on Vertex/Vertex2/Integral2/Maestro
Manni01 is offline  
post #3256 of 7841 Old 10-22-2018, 11:28 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,846
Mentioned: 568 Post(s)
Tagged: 0 Thread(s)
Quoted: 2735 Post(s)
Liked: 3817
Quote:
Originally Posted by Neo-XP View Post
The Predator's intro can not be fixed I guess, it can just be improved a bit so it is less noticeable.

But all other calm scenes can be stabilized with this trick I think, and that is the most important thing.
Having a 0.25s delay for calm scenes is very dangerous IMO, the image "feels" more stable with longer reaction times.
And as a bonus, it can avoid to blow out highlights.
Do you still think we should try to scale the brightness reaction time, even after looking at the new build? Or maybe we can pick a static brightness reaction time which achieves a good compromise between stability and blowing out highlights? E.g. 0.5 seconds?

-------

Here's a big new test build:

http://madshi.net/madVRhdrMeasure14.zip

It now collects and then stores (to disk) all measurements, which means any scene that you already played in the past, will be perfectly optimized the 2nd time you play it...
madshi is online now  
post #3257 of 7841 Old 10-22-2018, 11:37 AM
AVS Forum Special Member
 
Neo-XP's Avatar
 
Join Date: Jun 2018
Location: Switzerland
Posts: 1,129
Mentioned: 193 Post(s)
Tagged: 0 Thread(s)
Quoted: 854 Post(s)
Liked: 1176
Quote:
Originally Posted by Manni01 View Post
Not sure I understand you here. Minimum delay is 1s, did you mean reaction time? And what do you mean by "very dangerous"? Can you clarify? Thanks!
I wanted to write "reaction time" of course.
By very dangerous I mean it can change target very fast and be noticeable (brightness drops) on calm scenes.

Quote:
Originally Posted by madshi View Post
Do you still think we should try to scale the brightness reaction time, even after looking at the new build? Or maybe we can pick a static brightness reaction time which achieves a good compromise between stability and blowing out highlights? E.g. 0.5 seconds?
This time, I don't know (yet?) what could go wrong with it. It seems logical.

Quote:
Originally Posted by madshi View Post
Here's a big new test build:

http://madshi.net/madVRhdrMeasure14.zip

It now collects and then stores (to disk) all measurements, which means any scene that you already played in the past, will be perfectly optimized the 2nd time you play it...
I am very tired today, but I have to try this

Thanks!
Manni01 likes this.

Last edited by Neo-XP; 10-22-2018 at 12:26 PM.
Neo-XP is offline  
post #3258 of 7841 Old 10-22-2018, 11:49 AM - Thread Starter
AVS Forum Special Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 1,464
Mentioned: 222 Post(s)
Tagged: 0 Thread(s)
Quoted: 1110 Post(s)
Liked: 1794
Quote:
Originally Posted by madshi View Post

Here's a big new test build:

http://madshi.net/madVRhdrMeasure14.zip

It now collects and then stores (to disk) all measurements, which means any scene that you already played in the past, will be perfectly optimized the 2nd time you play it...
Great! Sounds awesome!
How do you optimize it perfectly?

Can't we do the same but LIVE with a 30s or 1min buffering or even 5min?

Also can we get the detail of the data so we can post-process it?

Would be interesting to know the avg nits of a picture, the median nits, the 90% quantil nits.

Last edited by Soulnight; 10-22-2018 at 11:55 AM.
Soulnight is offline  
post #3259 of 7841 Old 10-22-2018, 12:31 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,846
Mentioned: 568 Post(s)
Tagged: 0 Thread(s)
Quoted: 2735 Post(s)
Liked: 3817
Quote:
Originally Posted by Soulnight View Post
Great! Sounds awesome!
How do you optimize it perfectly?

Also can we get the detail of the data so we can post-process it?

Would be interesting to know the avg nits of a picture, the median nits, the 90% quantil nits.
I think you may have a bit too high expectations. What I meant with perfect optimization is just that for each detected scene, madVR now knows/remembers the highest measured peak, so the tone mapping will be adjusted for each scene separately. So the tone mapping target will be perfectly stable (not move at all) during the duration of each detected scene, without blowing out any highlight detail.

I don't actually even look at things like median nits, avg nits, 90% quantil nits (whatever that even is) etc.

Quote:
Originally Posted by Soulnight View Post
Can't we do the same but LIVE with a 30s or 1min buffering or even 5min?
No, that's not possible because the measurement is done as part of the rendering, and I can't render 5mins ahead, or even just one. One minute is 24*60 frames for a 24fps movie, which means I'd have to have a GPU queue size of 24*60 frames, which means the GPU would need to have 89GB VRAM (if I calculated correctly). For 60fps, it would be 2.5x 89GB.

However, maybe I could write a little command line tool, which could pre-parse a movie.
SamuriHL likes this.
madshi is online now  
post #3260 of 7841 Old 10-22-2018, 12:47 PM
Member
 
VerGreeneyes's Avatar
 
Join Date: May 2013
Posts: 141
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 21 Post(s)
Liked: 17
Quote:
Originally Posted by madshi View Post
No, that's not possible because the measurement is done as part of the rendering, and I can't render 5mins ahead, or even just one. One minute is 24*60 frames for a 24fps movie, which means I'd have to have a GPU queue size of 24*60 frames, which means the GPU would need to have 89GB VRAM (if I calculated correctly). For 60fps, it would be 2.5x 89GB.
Hmm, I guess that would make the current maximum for 24fps footage 1 second with madVR's GPU queue size set to 24. That seems like it could already help stability a lot (though dependent on user settings, which isn't ideal). Does madVR look ahead at all currently?
VerGreeneyes is offline  
post #3261 of 7841 Old 10-22-2018, 01:02 PM - Thread Starter
AVS Forum Special Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 1,464
Mentioned: 222 Post(s)
Tagged: 0 Thread(s)
Quoted: 1110 Post(s)
Liked: 1794
Quote:
Originally Posted by madshi View Post
No, that's not possible because the measurement is done as part of the rendering, and I can't render 5mins ahead, or even just one. One minute is 24*60 frames for a 24fps movie, which means I'd have to have a GPU queue size of 24*60 frames, which means the GPU would need to have 89GB VRAM (if I calculated correctly). For 60fps, it would be 2.5x 89GB.

However, maybe I could write a little command line tool, which could pre-parse a movie.
So: 89gb for 60s at 24p.
1s pre buffering costs then : 1.48gb

My gtx 1080ti has 11gb vram.
So in theory, I could render 7s in buffering.

It would definetely makes everything much more stable. :-)

Edit:
Gtx1070 has 8gb vram: so 5s
Gtx1060: 3gb or 6gb: 2s or 4s

Last edited by Soulnight; 10-22-2018 at 01:06 PM.
Soulnight is offline  
post #3262 of 7841 Old 10-22-2018, 01:15 PM
Advanced Member
 
grendelrt's Avatar
 
Join Date: Jun 2004
Location: Richmond, VA
Posts: 962
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 578 Post(s)
Liked: 310
Quote:
Originally Posted by madshi View Post
I think you may have a bit too high expectations. What I meant with perfect optimization is just that for each detected scene, madVR now knows/remembers the highest measured peak, so the tone mapping will be adjusted for each scene separately. So the tone mapping target will be perfectly stable (not move at all) during the duration of each detected scene, without blowing out any highlight detail.

I don't actually even look at things like median nits, avg nits, 90% quantil nits (whatever that even is) etc.


No, that's not possible because the measurement is done as part of the rendering, and I can't render 5mins ahead, or even just one. One minute is 24*60 frames for a 24fps movie, which means I'd have to have a GPU queue size of 24*60 frames, which means the GPU would need to have 89GB VRAM (if I calculated correctly). For 60fps, it would be 2.5x 89GB.

However, maybe I could write a little command line tool, which could pre-parse a movie.
I was thinking of something like this the other day. How long would it take to scan a file and pull all of the luminance information and store it? If we are already ripping the disc and storing it, wouldn't be that big of deal to run a scan of the file afterwards. Would it be too hard to reference an external file though during the playback of the movie vs real time calculating during the movie?
grendelrt is online now  
post #3263 of 7841 Old 10-22-2018, 01:18 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,846
Mentioned: 568 Post(s)
Tagged: 0 Thread(s)
Quoted: 2735 Post(s)
Liked: 3817
Quote:
Originally Posted by VerGreeneyes View Post
Hmm, I guess that would make the current maximum for 24fps footage 1 second with madVR's GPU queue size set to 24. That seems like it could already help stability a lot (though dependent on user settings, which isn't ideal). Does madVR look ahead at all currently?
Quote:
Originally Posted by Soulnight View Post
So in theory, I could render 7s in buffering.

It would definetely makes everything much more stable. :-)
Sorry guys, no pre-buffering planned. It would take a lot of development effort, and the benefit would be relatively small, IMHO. I will only offer standard playback without any pre-parsing. Or fully pre-parsed, by storing measurements to a file on disk. I don't plan to offer any solutions in between.
madshi is online now  
post #3264 of 7841 Old 10-22-2018, 01:21 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,846
Mentioned: 568 Post(s)
Tagged: 0 Thread(s)
Quoted: 2735 Post(s)
Liked: 3817
Quote:
Originally Posted by grendelrt View Post
How long would it take to scan a file and pull all of the luminance information and store it?
I don't know, it would mostly depend on the decoding speed, I think.

Quote:
Originally Posted by grendelrt View Post
Would it be too hard to reference an external file though during the playback of the movie vs real time calculating during the movie?
Not sure what you mean with that? Referencing an external file is already in the latest test build!
madshi is online now  
post #3265 of 7841 Old 10-22-2018, 01:27 PM
Advanced Member
 
grendelrt's Avatar
 
Join Date: Jun 2004
Location: Richmond, VA
Posts: 962
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 578 Post(s)
Liked: 310
Quote:
Originally Posted by madshi View Post
I don't know, it would mostly depend on the decoding speed, I think.


Not sure what you mean with that? Referencing an external file is already in the latest test build!
Well I guess that part is easy then I think pre-parsing would be great addition if it has an measurable benefit, I would just add it to my work list when ripping a disc.
grendelrt is online now  
post #3266 of 7841 Old 10-22-2018, 01:42 PM
AVS Forum Special Member
 
Neo-XP's Avatar
 
Join Date: Jun 2018
Location: Switzerland
Posts: 1,129
Mentioned: 193 Post(s)
Tagged: 0 Thread(s)
Quoted: 854 Post(s)
Liked: 1176
The beauty of it is to do it in real time, without knowing what will come next

Writing a file on the disk is already cheating

@madshi I don't think my second solution will work by looking at mad max scenes, the measured peak often jumps by more than 75% from frame to frame(!) on calm scenes (the lum graph is not changing).

Better find the fastest limit which does not cause any issue I guess, even if it blows out highlights a bit.

The Jurassic Park scene was totally random by the way, but you already found that 0.20s was too fast.

So now we have to find if 0.25s is safe enough? because it is already pretty bad for Harry Potter
Neo-XP is offline  
post #3267 of 7841 Old 10-22-2018, 01:48 PM
Member
 
Join Date: Apr 2018
Posts: 190
Mentioned: 3 Post(s)
Tagged: 0 Thread(s)
Quoted: 127 Post(s)
Liked: 16
Where is the file that the information is on please?
toby5 is online now  
post #3268 of 7841 Old 10-22-2018, 02:00 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 7,846
Mentioned: 568 Post(s)
Tagged: 0 Thread(s)
Quoted: 2735 Post(s)
Liked: 3817
Quote:
Originally Posted by Neo-XP View Post
Writing a file on the disk is already cheating


FWIW, of course my goal is to make the first playback already as good as possible. But if using a file on disk helps making the 2nd playback even better, why not?

Quote:
Originally Posted by Neo-XP View Post
I don't think my second solution will work by looking at mad max scenes, the measured peak often jumps by more than 75% from frame to frame(!) on calm scenes (the lum graph is not changing).

Better find the fastest limit which does not cause any issue I guess, even if it blows out highlights a bit.

The Jurassic Park scene was totally random by the way, but you already found that 0.20s was too fast.

So now we have to find if 0.25s is safe enough? because it is already pretty bad for Harry Potter
Yes, I think we should try to find the fastest brightness reaction time which doesn't cause any issues. From what I've seen it could be 0.20s, but there might be scenes where that might be too fast. It could be as high as 2.0 seconds, but I sure hope not. Only testing a lot with real movies will tell...

Quote:
Originally Posted by toby5 View Post
Where is the file that the information is on please?
The file is stored to the same folder where the movie file is located. E.g. if you play "c:\someFolder\some.mkv", then the measurements should be stored to "c:\someFolder\some.mkv.measurements". Of course this is only done if madVR has write access to that folder. And the saving only happens if either the movie has run through, or if you stop playback. If you stop before the movie has run through, madVR will save to the file whatever information it has collected. It doesn't have to be complete yet.
stevenjw and Manni01 like this.
madshi is online now  
post #3269 of 7841 Old 10-22-2018, 02:36 PM
AVS Forum Special Member
 
Manni01's Avatar
 
Join Date: Sep 2008
Posts: 9,292
Mentioned: 354 Post(s)
Tagged: 0 Thread(s)
Quoted: 5596 Post(s)
Liked: 5887
Quote:
Originally Posted by Neo-XP View Post
I wanted to write "reaction time" of course.
By very dangerous I mean it can change target very fast and be noticeable (brightness drops) on calm scenes.
Sorry, I still I don't understand why a longer reaction time is more dangerous than a shorter one. In a previous post, you said that after trying 0.1 and 0.15 you would set it to 0.25s to be safe, that made complete sense (that's the delay I had chosen too), and then you are saying that 0.25 is "very dangerous". How can 0.25 be more dangerous than 0.15 or 0.20 for calm scenes? That's what I don't understand. If you're saying that it's less stable than 0.50, then it makes sense, but it's kind of obvious so I'm wondering if I'm missing something regarding "calm scenes" or if you were just stating the obvious.

Batch Utility V4.02 May 16 2019 to automate measurements files for madVR with support for BD Folders
JVC Macro feature on Vertex/Vertex2/Integral2/Maestro
Manni01 is offline  
post #3270 of 7841 Old 10-22-2018, 03:36 PM - Thread Starter
AVS Forum Special Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 1,464
Mentioned: 222 Post(s)
Tagged: 0 Thread(s)
Quoted: 1110 Post(s)
Liked: 1794
Quote:
Originally Posted by madshi View Post
Sorry guys, no pre-buffering planned. It would take a lot of development effort, and the benefit would be relatively small, IMHO. I will only offer standard playback without any pre-parsing. Or fully pre-parsed, by storing measurements to a file on disk. I don't plan to offer any solutions in between.
But I already pre-buffer 24 frames in the queue in madvr.

So you are already offering it.
Or is the queue something different and you don't have access to the histogram for those 24?
Soulnight is offline  
Sponsored Links
Advertisement
 
Reply Digital Hi-End Projectors - $3,000+ USD MSRP

Tags
dynamic tone mapping , 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