why so slow?

[ryanjay0]

It takes me 4 seconds per 331x331 image. That's significantly slower than the 0.06 seconds Zisserman reports in the original two stream paper. Can i make this code work on the GPU somehow? Or do you know of a GPU implementation?

[pathak22]

This is a CPU implementation and does not use GPU. One way is to resize the image to smaller size and later upsample the flow image.

[jremmons]

I agree with @ryanjay0, this code is pretty slow... at least compared to other methods. It takes ~0.8 seconds on 256x256 frames compared to ~0.02 seconds for the Farneback opencv implementation (which is similar to the Brox algorithm used in two-stream paper I believe) on the CPU not GPU (I have an Intel E5-2687Wv4 CPU). I would love to use it in my research because the flow fields seem better than the Farneback algorithm, but at 40x slower than the Farneback opencv CPU implementation, it is unusable...

[pathak22]

@jremmons I would recommend using it at 100x100 and then resize flow field back to 256x256. I wrote pyflow only because Farneback and other default algorithms in OpenCV were too inaccurate to be usable on anything but simplest of cases.
However, if Farneback is good enough for your use-case, then perhaps you can go ahead with it for the speed difference?

[pathak22]

@ryanjay0 @jremmons There is also an OpenMP multi-processing pull request here #3 . Depending on how many cores you have that can significantly improve the running time.

[jremmons]

@pathak22 I'll give resizing from 100x100 images a shot. Unfortunately, the multicore version won't help because I will already be computing the flow fields in a data parallel way.

[dmenig]

This repo is laughable. "super fast" what a joke

[dhruvsasuke]

A really great and a useful repository for optical flow calculation. Is it possible though that we might be getting a GPU based implementation of the same sometime in the future, because I am really looking forward to that... :)