[PD] multiblob tracking in Gem while objects keep their IDs

Jack jack at rybn.org
Mon May 27 02:24:17 CEST 2013

Le 27/05/2013 01:26, Max a écrit :
> Am 27.05.2013 um 01:00 schrieb Jack <jack at rybn.org>:
>> Le 26/05/2013 20:56, Max a écrit :
>>> hi list, a student of mine, Jakob Gomoll, did solve how to track multiple blobs while every blob keeps its ID.
>>> Here is where i scratch my head: It works fine until you render the output of the multiblob tracker to a rectangle.
>>> I'd like to understand why this is.
>>> Is it a bug or a feature?
>>> connect the tracker to the pix_texture (where the red line is) and it will mess up the result:
>> Hello Max,
>> This could be interesting for you :
>> http://www.mail-archive.com/pd-list@iem.at/msg42343.html
> Thanks Jack,
> I know – I have posted on this thread too. We solved this problem differently. Because our application was microscopy and we had specimen who were stopping their movement for a while before moving on, the continuity approach wasn't working. Since we based the blob detection on frame differences [pix_movement] rather than background subtraction from a reference frame [pix_background] blobs who were resting for a few frames simply disappeared and got a new ID assigned.
> Our approach is to set a time-out after we declare a blob dead. If it starts moving in the same region (size is settable too) again before the time-out, we pick up the old ID. So rather than using movement vectors as reference we used proximity. All data is stored in tables.
> The patch works beautifully without any externals. Have you tried?
> So this problem is already solved - my question was rather a Gem thing: why does is stop working when I want to render the image behind it? Do you know this?
> Max
Sorry, i didn't see your patch in your previous post.
If I try to open it, i get :
 arraysize blob_ids
... couldn't create

What is [arraysize] ?


More information about the Pd-list mailing list