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

[Antoine Villeret]

hi all,

thanks Max for sharing your (very good) work !

I have a strange behavior here, some cross appear in the middle of
nowhere...
but the blobs are keeping their ID well

did you tried pix_opencv_blobtrack ?
it's a work in progress and I know the parameters are quiet opaque
but I didn't find any documentation about the blobtracker modules in
OpenCV...
nevertheless, it works quite good
I attached a pix_opencv_blobtrack based patch
it doesn't work exactly the same as yours but it keeps the IDs

the main thing is to make the foreground detection module to not update to
quickly to keep static blob ID

i've packed an Ubuntu 64 bit binary with

cheers

antoine

--
do it yourself
http://antoine.villeret.free.fr


2013/5/27 Jack <jack at rybn.org>

> 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
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130527/e3e97e1e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tracker-opencv_version.zip.tar.gz
Type: application/x-gzip
Size: 599722 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130527/e3e97e1e/attachment-0001.bin>