Hi,
I was wondering if the following is possible in Nuke:
Consider a plugin that processes a video stream. Now processing frame N
not only depends on input frame N, but it also depends on the _output_
of the computation of frame N-1. A simple example would be something
like this:
out_N = in_N * 0.9 + out_{N-1} * 0.1
i.e. the output color of frame N (out_N) is a mix between the input
frame N (in_N) and the output frame N-1 (out_{N-1}), resulting in a time
blur effect. The output for frame N thus depends on all input frames up
to N (1, 2, ..., N).
One way of implementing this would be to split the input in the Nuke
plugin and request input frames (1, 2, ..., N) for the input. However, I
assume this would be quite expensive (O(N) for frame N). Is there a
better way of doing it?
To make things more difficult, what if the mix weight is actually a knob
and thus can change over time, i.e.:
out_N = in_N * alpha_N + out_{N-1} * (1 - alpha_N)
where alpha_N is the knob value at frame N? I think in this case,
requesting all input frames up to N won't work, because when computing
frame N, we only know alpha_N but not the previous alpha values. Or is
there a way to retrieve the knob value for an arbitrary frame?
One way I could imagine to do it is to store out_{N-1} in the plugin
after processing frame N-1, and when processing frame N, re-use that
data. If frame N should be processed and out_{N-1} is not available,
simply output black or an error message. So as long as the user only
moves forward in time, the output is ok. However, if the user then goes
ahead and changes e.g. alpha_{N-2}, we would have to throw away the
stored out_{N-1} because it would look differently. But we don't know
when alpha_{N-2} changes, so with this approach there can be
inconsistencies. And what's worse, Nuke might cache the out_N because it
doesn't know it depends on alpha_{N-2}, so our plugin doesn't get run
for frame N and we don't get a chance to update out_N at all.
So, is there a nice way of handling these kind of things in Nuke?
Something like requesting out_{N-1} when computing out_N, and telling
Nuke about this dependency (using hashes) so caching doesn't break?
If not, the only practical solution I can imagine is to live with the
above inconsistencies and provide a Py script button in the GUI which,
using the Executable interface, processes all frames as a serial
sequence, and writes the output for every frame to disk (i.e. caches its
output). So while editing, the user has to be aware of the fact that the
button has to be pressed to make sure the output is consistent. And
Nuke's caching needs to be disabled for that plugin.
Any other ideas on how to do this? Any help appreciated...
Thanks,
Peter
--
-------------------------------------------
Peter Kaufmann
The Walt Disney Studios (Schweiz) GmbH
[email protected]
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
