In terms of the way this algorithm works, I can't make sense of what you mean by this. The algorithm simply matches where a particular percentile falls on the histogram from one frame to the next. I'm not sure what you mean by 'exposure graph'.
Okay, let me call it
average brightness of each frame.
I f I am not mistaken if there is flicker between keyframes, the algorithm evens that out - no matter what, especially with multiple passses.
With my proposed method, it would just reduce the flicker leading to a more natural result. This is important when there are clouds blocking the sunlight and the exposure decreases significantly, for a natural result one would like to have a darker image in the shadow, but not 3EV darker as it was in reality.
Red graph = average image brightness (per frame)
Green graph = brutally averaged brightness target
Blue graph = gentle brightness target for
pleasing and natural results©
Black bars = keyframes
The blue graph could be adjusted to anything in between from beeing like the red one (no changed brightness target) or the green one (smoothed out totally).
The deflickering strength then determines how hard the algorithm tries to match that target graph.
Do you understand now what I mean?
I could easily implement something like this (see the 'evCoefficient' at the top of the script, simply make it smaller), but...
...
If you're already making two different layers, you could just only partially blend the ground of fully deflickered footage (i.e. your layer mask makes the sky of the original 100% opaque, and the ground 50% or whatever). That should be basically the same I should think.
That would be possible, but in my case that means adding 50% more render time to that particular render and having to manage another iteration of the same sequence (3 instead of 2). I am also not sure if the blending would lead to the same natural looking results that you get with proper deflickering because that exposure slider of ACR acts really filmlike (in the sense of how chemical film behaves).
