Why flickering in this frame-difference Jitter patch?
Although I've used this technique for years, I don't understand why there is flickering in this patch... It must be due to the way Jitter handles matrix copy, and to how [t l l] works in low priority thread, but I would love to understand better what's happening, and to get an elegant solution (more elegant programming than lowering the frame rate).
Thanks for any insight!
PS: the effect is not linked to Max 8! I'm pretty sure it's also why Andrew Benson used a [jit.slide] in his Max 4.6 "Recipe #32 Hold Still"!
The source .mov file is 15fps, so you are temporally oversampling the movie with lower qmetro intervals. Set @unique 1 in jit.movie and you'll see the flickering is gone.
Subtracting the frame from itself will return a black frame, leading to flicker.
dozer.mov is a 15fps file and you are oversampling (20ms=50fps). This therefore outputs duplicate frames which are going to output zero difference between frames. To only ever output unique frames use @unique 1 as an argument to jit.movie
That makes complete sense, indeed, thanks!
Now, my follow-up question: that also happen when I use [jit.grab]. I actually don't know what the "maximum sampling rate" is for my built-in laptop camera. Is it what is reported when I set "framereport" to 1? It doesn't seem to make sense to me: I also get a "0" frame difference when I set a qmetro at, say, 20 ms, but the framecalc I get is always less than 2.
So, I guess the "real" sampling rate for my built-in camera is some other number, right?
J-F
The answer is the same, simply use the @unique 1 attribute argument :)
For some devices this can depend on lighting conditions (under low light they sometimes drop to 15 fps to reduce noise by frame averaging), but otherwise likely 30fps or 60fps. Sometimes this can be configured in the video capture devices settings. However, still best to use @unique for frame differencing purposes rather than rely on exact synchronization of the qmetro and the device/driver's clockrate.
Wonderful, very cool Joshua, thanks! I guess I never realized that flickering in the past because I was never fast enough to get into oversampling!