[Neo-XP]

1) In which scene(s)/movie(s) did you notice those brightness jumps? Everywhere? Or just some movies/scenes?

With Murder on the Orient Express scene 1 for instance.

2) Did you get those brightness jumps only with "fast" darkness values, or also with the default (rather slow) darkness values?

Yes, only with no delay + immediate for darkness.

I don't get them if I use 1 second for the darkness reaction time, like this

brightness delay: no delay
brightness reaction time: 0.1s
darkness delay: no delay
darkness reaction time: 1s

0.25s is still too slow, but 0.1s is enough to fix the Harry Potter scene

 

[Manni01]

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).

 

[madshi]

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.

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.

Yes, you can't use "no delay/immediately" for both "darkness" and "brightness" at the same time, or else you'll get flickering.

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?

0.25 causes visible brightness jumps

Did you get those brightness jumps only with "fast" darkness values, or also with the default (rather slow) darkness values?

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!

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.

 

[Neo-XP]

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.

 

[madshi]

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.)

 

[Neo-XP]

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
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/g7wbtvg2qta8bdn/Mother!_scene_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?

 

[stevenjw]

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.

 

[Chronoptimist]

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.

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.

 

[madshi]

@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.

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.

 

[Neo-XP]

@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/9vb64u01wiw722c/Jurassic_World_-_Fallen_Kingdom_scene_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.

 

[madshi]

I definitely can see it at frame 79 here with 0.1s : http://www.mediafire.com/file/9vb64u01wiw722c/Jurassic_World_-_Fallen_Kingdom_scene_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.

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.

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?

 

[Manni01]

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.

 

[Neo-XP]

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.

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.

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"?

 

[madshi]

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

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).

 

[Neo-XP]

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.

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:

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.

 

[Manni01]

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!

 

[madshi]

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...

 

[Neo-XP]

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.

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.

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!

 

[Soulnight]

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.

 

[madshi]

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.

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.