Memory Leak with Optical Flow Downloader

offonoll's picture

I have recently work with motion detection from the teapot example, witch I have seen it in many other compositions... (queue for difference frame + open CL + optical flow downloader + JS position-direction) ... but using this technique I have memory leaks. Instruments says it is optical flow downloader or at least it is listed many times. Leaking in 32bits and 64 bits.

Is there any other technique out there??

PreviewAttachmentSize
Captura de pantalla 2011-01-09 a las 19.06.41.png
Captura de pantalla 2011-01-09 a las 19.06.41.png455.36 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

offonoll's picture
Re: Memory Leak with Optical Flow Downloader

I attach two samples with optical flow 'motion detection' work. Does this compositions leak memory to you?

I will really appreciate your comments. Thank you so much.

PreviewAttachmentSize
MOTION DETECTION.qtz6.87 MB

gtoledo3's picture
Re: Memory Leak with Optical Flow Downloader

Somewhere around here there is an OpenCL optical flow kernel that Cybero ported from a web article (I believe). That kernel works ok.

OpenCV can do some similar operations as well.

By the way, you say that you use open CL in your message, but this is Core Image (10.5 era). What you may want to try to do is to use OpenCL and see if that works better.

It may not be the actual "optical flow" CI leaking, but the plugin that does those velocity calculations after the actual optical flow. I guess that part could probably be done in CL as well.

offonoll's picture
Re: Memory Leak with Optical Flow Downloader

Thank you George! the open CL isn't really working as expected. I took it from : http://kineme.net/composition/cybero/OpticalFlowOpenCLParticleMesh and the file attached shows you that it only goes down and left.

PreviewAttachmentSize
Motion Detection Op CL.qtz44.67 KB

cybero's picture
Re: Memory Leak with Optical Flow Downloader

The requirements of your construct are out of the scope of the OpenCL Optical Flow kernel; it does only flow one way :-). I don't think it will work as you require within your Image Flow macro.

Within that iterated step macro, it at best flutters and seems to otherwise falter.

Still, no memory leak.