Originally Posted by Neo-XP
I like this idea of a max speed.
The only problem I have found is with fade ins/out, because the speed is not fast enough (first scene of Samsung Chasing The Light Demo for instance).
But these special cases can be treated in a special way (immediately adapting the target on fade ins/outs, and only allowing the target going UP for fade ins and DOWN for fade outs), and for all other cases the max speed should be respected.
It also seems very easy to implement in the live algo, and safer than the brightness speeds
Thanks a for the feedback.
Can you explain a bit more:
You used PRESET 3 and saw something distracting with fade in/out? Can you describe it /document it?
How is "slow" being distracting?
The "max speed" idea could very easily be implemented in madVR LIVE algo, and it would look probably very bad most of the time.
The reason why is that the LIVE algo does not know the future, and even when it will it will be only for a few frames.
Knowing ALL the future, the "max speed" can turn to a a "SMART max speed" instead and will then look good.
I already explained it in the bigger post but let's try here a diffrent version of the explanation
Let's say we have identified a 10min long "Chapter".
- The new "Smart max Speed algo", will first calculate a LARGE rolling average of 1min for each single frames.
- Then it will look for all the "crossing points" where the ideal target value for each single frames is crossing the rolling average values.
To make it even more simple, let's imagine one single average Target Nits value of 300nits for the whole 10min chapter (That's how we had started anyway
Then we scan the whole chapters and create sub-section of the chapters:
- Consecutive Frames with ideal target nits ABOVE the chapter average target nits
- Consecutive Frames with ideal target nits BELOWthe chapter average target nits
Each time, the ideal target cross the "Chapter average", we set a new crossing point.
Then we give to EACH crossing point frame, a target nits equal to the average of the whole chapter.
And in between 2 consecutive crossing point, we can now calculate the MAX SPEED.
But you need to meet the other crossing point set at the average target nits.
So with start from the first crossing point, use the max speed and go forward: we get a "LEFT MAX SPEED Target nits for every frames between the 2 corner points.
But of course the last frame will not be back "by it self" at the average target Nits.
So we do the same thing, but backwards in time starting from the next crossing point: we get a "RIGHT MAX SPEED Target nits for every frames between the 2 corner points.
And then we look for where the LEFT and RIGHT Max Speed Target Nits intersect, and keep the left part of the LEFT target nits lists, and the right part of the RIGHT target nits LIST.
Like this, no matter what, you are always close to the "Chapter Average" at the crossing points.
And actually, we even use a more local "LARGE rolling average of 1minute" instead of the chapter average to make it more local than the full 10min chapter length.
-->In any case, the LIVE algo does not know the chapter average, or the local 1min rolling average, of the chapter length even.
If you fix the speed at a certain rate in the LIVE algo (which is somehow already what is beiing done even if the speed can vary), you have to start from somewhere and from a certain target nits.
And this target nits will probably NOT be (except if your lucky) the chapter average.
Now let's say the target nits goes down for 5s, and then go back up VERY quickly and cross the average again while always going higher.
What will happen is that the LIVE algo will be surprised, will now try to go up again, but will be WAY too low (not at the average of the chapter) when it crosses the average, and the next bright scenes requireíng higher target nits will be overblown.
That's actually already the case to some extend with the LIVE algo. But it#s mitigated with target nits RESET at each camera cut.
And as we know, resetting at each camera cuts leads to sometimes strange brightness jump like in the "little girl intro scene of the MEG" or the "Interrogation scene" in Venom.
What we have implemented with the new "SMART Max Speed" is actually very similar to what Madshi implemented with together with the measurement file for the frame peak nits
(We got the idea from what he did there, the difficulty was to translate it to the target nits world).
The measurement file was at the begining created for the sole purpose of knowing the future so that madshi could exactly always choose a frame peak nits which would NEVER CLIP while always moving at a FIXED invisible Speed.
Only, for him the "local scene peak maximums" during a identified scene were his crossing points.
Where for us, those crossing point relate to the "Chapter average, or local 1min rolling average".
So as good and impressive as the LIVE algo is, it has its limitations because it can and will get surprised and CLIP (peak nits) or be a bit late to adapt brightness (too dark, too bright) with dynamic target nits.
Hopes this clarify what we are doing.