<div dir="ltr">hi all, <div><br></div><div style>thanks Max for sharing your (very good) work !</div><div style><br></div><div style>I have a strange behavior here, some cross appear in the middle of nowhere...</div><div style>
but the blobs are keeping their ID well</div><div style><br></div><div style>did you tried pix_opencv_blobtrack ?</div><div style>it's a work in progress and I know the parameters are quiet opaque</div><div style>but I didn't find any documentation about the blobtracker modules in OpenCV...</div>
<div style>nevertheless, it works quite good </div><div style>I attached a pix_opencv_blobtrack based patch </div><div style>it doesn't work exactly the same as yours but it keeps the IDs</div><div style><br></div><div style>
the main thing is to make the foreground detection module to not update to quickly to keep static blob ID</div><div style><br></div><div style>i've packed an Ubuntu 64 bit binary with</div><div style><br></div><div style>
cheers</div><div style><br></div><div style>antoine</div><div class="gmail_extra"><br clear="all"><div>--<br>do it yourself <br><a href="http://antoine.villeret.free.fr" target="_blank">http://antoine.villeret.free.fr</a><br>
</div>
<br><br><div class="gmail_quote">2013/5/27 Jack <span dir="ltr"><<a href="mailto:jack@rybn.org" target="_blank">jack@rybn.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 27/05/2013 04:10, Max a écrit :<br>
<div><div class="h5">> Am 27.05.2013 um 02:57 schrieb Jack <<a href="mailto:jack@rybn.org">jack@rybn.org</a>>:<br>
><br>
>> Le 27/05/2013 02:32, Max a écrit :<br>
>>> Am 27.05.2013 um 02:24 schrieb Jack <<a href="mailto:jack@rybn.org">jack@rybn.org</a>>:<br>
>>><br>
>>>> Le 27/05/2013 01:26, Max a écrit :<br>
>>>>> Am 27.05.2013 um 01:00 schrieb Jack <<a href="mailto:jack@rybn.org">jack@rybn.org</a>>:<br>
>>>>>> Le 26/05/2013 20:56, Max a écrit :<br>
>>>>>>> hi list, a student of mine, Jakob Gomoll, did solve how to track multiple blobs while every blob keeps its ID.<br>
>>>>>>> Here is where i scratch my head: It works fine until you render the output of the multiblob tracker to a rectangle.<br>
>>>>>>> I'd like to understand why this is.<br>
>>>>>>><br>
>>>>>>> Is it a bug or a feature?<br>
>>>>>>> connect the tracker to the pix_texture (where the red line is) and it will mess up the result:<br>
>>>>>>><br>
>>>>>> Hello Max,<br>
>>>>>> This could be interesting for you :<br>
>>>>>> <a href="http://www.mail-archive.com/pd-list@iem.at/msg42343.html" target="_blank">http://www.mail-archive.com/pd-list@iem.at/msg42343.html</a><br>
>>>>> Thanks Jack,<br>
>>>>> 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.<br>
>>>>> 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.<br>
>>>>><br>
>>>>> The patch works beautifully without any externals. Have you tried?<br>
>>>>><br>
>>>>> 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?<br>
>>>>><br>
>>>>> Max<br>
>>>>><br>
>>>> Sorry, i didn't see your patch in your previous post.<br>
>>>> If I try to open it, i get :<br>
>>>> arraysize blob_ids<br>
>>>> ... couldn't create<br>
>>>><br>
>>>> What is [arraysize] ?<br>
>>> oh, darn - seems it isn't completely vanilla then. it is an external by Juha Vehviläinen<br>
>>> <a href="http://puredata.info/downloads/arraysize" target="_blank">http://puredata.info/downloads/arraysize</a><br>
>> Ah ok, maybe with [expr size("table_name")].<br>
>> About the problem : you need to render the [rectangle] before "draw_blobs".<br>
>> See the patch attached…<br>
> thank you jack (but still scratching my head why exactly that is, will revisit tomorrow).<br>
> updated here: <a href="https://github.com/mxa/Bewegungsmelder" target="_blank">https://github.com/mxa/Bewegungsmelder</a><br>
><br>
</div></div>Hello Max,<br>
<br>
In your patch, you need to put the crosses "on" the rectangle showing<br>
movement. These crosses and rectangle are in the same plan. Therefore,<br>
you need to render, first, the rectangle and after the crosses.<br>
Inside the subpatch "draw_blob", you have a [gemhead 90], which one is<br>
banged each time it has a cross to render. But, this [gemhead 90] is<br>
rendered many times (or not) during your main [gemhead] (in the main<br>
windows).<br>
If you open the subpatch "draw_blob", you can see that i add a<br>
[loadbang] and a [0 ( to stop the render of [gemhead 90] each frame,<br>
because the render is forced (many times or not) by a bang from the main<br>
[gemhead] and because you needn't to render this [gemhead 90] during the<br>
'normal' render cycle.<br>
You can easily replace [gemhead 90] with [gemhead 10] and get exactly<br>
the same result.<br>
If you want, it should be possible to replace this [gemhead 90] with a<br>
[gemlist].<br>
Hope the explanations are clear. I give here a small example to understand.<br>
++<br>
<span class="HOEnZb"><font color="#888888"><br>
Jack<br>
<br>
<br>
</font></span><br>_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div></div>