» Optical Flow DX11 GPU
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

Optical Flow DX11 GPU

Credits: its simply copied from foo | andrew benson


Optical flow solution on GPU.

i have x and y both negative and positive in the r and g channel...hope this works for everyobne

Im new to vvvv so please excuse me if i violated name or coding conventions...if so please point me in the right direction



Optical Flow.7z
16.01.14 [15:30 UTC] by princemio | 1313 downloads
vers. 2 --- adapted to name conventions
Show 1 older revisions

Older Revisions

Optical Flow.7z
16.01.14 [15:04 UTC] by princemio | 377 downloads

catweasel 16/01/2014 - 16:11

Looks cool :)
You can loose the Mio bit on the module name if you like and then it keeps with the naming conventions, but you can add tags in the shader
//@author: vux
//@help: template for texture fx
//@tags: texture

for example, and in the patch with ctl+m

Nice first contribution!

princemio 16/01/2014 - 16:18

ah k will change that ...just always typed that to see in node browser which ones are mine...and which ones i can trust...lol...thx

catweasel 16/01/2014 - 20:56

I'll be honest I tend to put cat in the file name too ;)

DiMiX 23/01/2014 - 18:37

hey princemio. Thanks for contribution.
Is it possible to get values of direction and speed of the average movement?
Which color scheme i have to use for decode?

princemio 24/01/2014 - 02:59

hmm if i did everything right then the x value should be in r and the y channel in g of the colored texture ... plus and minus should be available in 32 bit float tex. i think a compute shader would be necessary - like the pipet example in dx11 ...MAYBE ...and then read back ...but i think someone who is more experienced could jump in this topic...sorry if that didnt help

DiMiX 24/01/2014 - 18:09

i saw these things
and thought maybe this encoding scheme is more understandable

princemio 24/01/2014 - 19:19

hey thx for the feedback.

The Shader calculates a certain offset in x and y for each pixel. The hue color coding would imply that we calculate from this x and y values a certain angle which represents a particular hue color.
i do believe its sth like this

float angle = atan2(y,x);

now when we reuse the optical flow in the next pass or shader we often use the individual vector to distort the image or for example to accelerate particles in a certain direction. in order to do so, we then need to restore the x and y for the acceleration from this angle again.

Hence we would convert the x and y into an angle in order to restore the x and y later from that angle. Which is think is redundant. (correct me if im wrong)

another problem is that this unneeded conversion is doen via atan which ( like sin,cos, log or texture lookups) increases the cost per pixel tremendously.

tekcor 27/01/2014 - 19:56

super cool

DiMiX 05/02/2014 - 13:52

hi princemio,
I cant code, so my ideas are more theoretical
The Shader calculates a certain offset in x and y for each pixel.
If we map this offset to some color scheme which let us retrieve hue changing for direction, saturation changing for speed?

gen4 25/02/2015 - 14:19

How i can run it?
There is some addons missed?

gen4 26/02/2015 - 18:19

now i start it - it just was dx11 not for 64bit.
installing right pack - resolve my problem

anonymous user login


~20h ago

~1d ago

joreg: reminder: 12th #vvvv online meetup tonight, 8pm CET: 12.-worldwide-vvvv-meetup

~20d ago

domj: https://youtu.be/omqlZepW69g sonic pi live @ tami

~26d ago

benju: Job: Lehrkraft mit Kentnissen in Python, Machine Learning und Grundlagen der Informationstechnologie gesucht: https://bit.ly/2TtgOoJ

~26d ago

david: reminder: starting at 2pm CET today: online-workshop-shiny-generative-graphics-with-vvvv

~28d ago

readme: Let's appreciate the most important feature being the flat UI redesign. Even though blueprints still remain ugly ...