Le 27/05/2013 04:10, Max a écrit : > Am 27.05.2013 um 02:57 schrieb Jack <[email protected]>: > >> Le 27/05/2013 02:32, Max a écrit : >>> Am 27.05.2013 um 02:24 schrieb Jack <[email protected]>: >>> >>>> Le 27/05/2013 01:26, Max a écrit : >>>>> Am 27.05.2013 um 01:00 schrieb Jack <[email protected]>: >>>>>> 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/[email protected]/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
small_exemple.pd
Description: application/puredata
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
