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

[Jack]

Le 27/05/2013 04:10, Max a écrit :
> Am 27.05.2013 um 02:57 schrieb Jack <jack at rybn.org>:
>
>> Le 27/05/2013 02:32, Max a écrit :
>>> Am 27.05.2013 um 02:24 schrieb Jack <jack at rybn.org>:
>>>
>>>> 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] ?
>>> oh, darn - seems it isn't completely vanilla then. it is an external by Juha Vehviläinen
>>> http://puredata.info/downloads/arraysize
>> Ah ok, maybe with [expr size("table_name")].
>> About the problem : you need to render the [rectangle] before "draw_blobs".
>> See the patch attached…
> thank you jack (but still scratching my head why exactly that is, will revisit tomorrow).
> updated here: https://github.com/mxa/Bewegungsmelder
>
Hello Max,

In your patch, you need to put the crosses "on" the rectangle showing
movement. These crosses and rectangle are in the same plan. Therefore,
you need to render, first, the rectangle and after the crosses.
Inside the subpatch "draw_blob", you have a [gemhead 90], which one is
banged each time it has a cross to render. But, this [gemhead 90] is
rendered many times (or not) during your main [gemhead] (in the main
windows).
If you open the subpatch "draw_blob", you can see that i add a
[loadbang] and a [0 ( to stop the render of [gemhead 90] each frame,
because the render is forced (many times or not) by a bang from the main
[gemhead] and because you needn't to render this [gemhead 90] during the
'normal' render cycle.
You can easily replace [gemhead 90] with [gemhead 10] and get exactly
the same result.
If you want, it should be possible to replace this [gemhead 90] with a
[gemlist].
Hope the explanations are clear. I give here a small example to understand.
++

Jack


-------------- next part --------------
A non-text attachment was scrubbed...
Name: small_exemple.pd
Type: application/puredata
Size: 1436 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130527/d9f7a434/attachment.bin>