Forums > MaxMSP

cv.jit.centroids resulting in low fps — help??

May 27, 2008 | 12:01 am

hi,

i working on a patch that uses cv.jit.centroids to do some IR tracking. i’m getting a fps of anywhere between 6 – 20, which is really slow. i’m a newbie with cv.jit, but i’m wondering if anyone has tried some optimizations to overcome any latency experience. help/pointers would be greatly appreciate.

thanks,
amal


May 27, 2008 | 12:28 am

What do you mean by framerate? Is it the framerate of the output
matrix with the little cross-hairs, or is it the "framerate" (really
just _rate_) at which is gives you the coordinates for the centroid?

Or is centroids slowing down your whole patch so that the input
framerate is slow (cpu / i/o issue)?

In general when you’re working with computationally intensive jitter
patches on a multi-core/proc. machine you can make a copy of Max and
name it something like "MaxMSP 2". You can then open two copies of Max
and do your tracking in one and other stuff in another copy. Your
machine will allocate each copy to it’s own processor/core.

Otherwise, minimizing GUI objects always helps immensely.

Also, are you sending matrices over a network?

On Mon, May 26, 2008 at 8:01 PM, amal wrote:
>
> hi,
>
> i working on a patch that uses cv.jit.centroids to do some IR tracking. i’m getting a fps of anywhere between 6 – 20, which is really slow. i’m a newbie with cv.jit, but i’m wondering if anyone has tried some optimizations to overcome any latency experience. help/pointers would be greatly appreciate.
>
> thanks,
> amal
>


Morgan Sutherland


May 27, 2008 | 1:53 am

hey,
how intensive is the rest of your patch?
I generally always split these things in two.
have one computer running only cv and capture devices then another computer running the output and jitter patch then run and osc/udp link in between.
this may not a apply to this specific patch. a thought anyway.
best
adam


May 27, 2008 | 7:34 am

make sure you enable @unique 1 for your grabbing object
(jit.qt.grabjit.dx.grab) this makes it output only new frames when
available and not based on your qmetro rate (which should probably match
your camera fps anyways).

On Tue, May 27, 2008 at 4:53 AM, adam synnott wrote:

>
> hey,
> how intensive is the rest of your patch?
> I generally always split these things in two.
> have one computer running only cv and capture devices then another computer
> running the output and jitter patch then run and osc/udp link in between.
> this may not a apply to this specific patch. a thought anyway.
> best
> adam
>


Viewing 4 posts - 1 through 4 (of 4 total)