hi list,
some week ago I wrote a little gem external to have hit test on images
we can check for single points, rectangle areas or lines. the user can define new areas and assign them id, the output of the external is a list of 2 numbers where the first number is the id and the second is the new state. points and rectangles have only 2 states (0=off, 1=on), lines output a float between 0 and 1 where 0 if the hit was in the first point and 1 if the hit was in the second point (a line is created specifying 2 points).
I wanted to fix a couple of minor bugs (loading/saving areas, showing areas) before announcing but it seems that i never have spare time, so here it is..
you can find the source code and API here: http://www.davidemorelli.it/dokuwiki/doku.php?id=interfaces:interfaces
I'd be happy if the external would be added to GEM's CVS..
ciao, davide.
Hi!
This sounds cool, but I'm a little confused.
I'm guessing your testing for white pixels that happen to become visible within the pix in the correct region?
If this is right then you feed it pix_motion for motion hits, and pix_background for "presence" hits?
sounds cool...
b.
davide wrote:
hi list,
some week ago I wrote a little gem external to have hit test on images
we can check for single points, rectangle areas or lines. the user can define new areas and assign them id, the output of the external is a list of 2 numbers where the first number is the id and the second is the new state. points and rectangles have only 2 states (0=off, 1=on), lines output a float between 0 and 1 where 0 if the hit was in the first point and 1 if the hit was in the second point (a line is created specifying 2 points).
I wanted to fix a couple of minor bugs (loading/saving areas, showing areas) before announcing but it seems that i never have spare time, so here it is..
you can find the source code and API here: http://www.davidemorelli.it/dokuwiki/doku.php?id=interfaces:interfaces
I'd be happy if the external would be added to GEM's CVS..
ciao, davide.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
davide wrote:
hi list,
some week ago I wrote a little gem external to have hit test on images
I'd be happy if the external would be added to GEM's CVS..
thanks for the object. seems like it is detection/tracking-week in Gem-land: first the reacTable*-object, now yours. let's see what's next...
i have added it to the CVS, with small changes (like making show work). i am not sure what to do with the file-io: for one thing, i don't understand why it needs to be a binary format. what is more important, i don't understand why the load/save needs to be there at all. i guess [textfile] could handle this perfectly. probably it would be nice to have a [dump( message, which sends all the area-definitions to the 2nd outlet, so the saving could be done easier.
what do you think?
mf.adsr. IOhannes
Someone was asking me about the possibility to do what this object does in GEM just this week.
I only quickly looked at the code, but I think it would be more efficient to test per pixel in a linear fashion especially for more than a few test areas. The current way is a true cache basher. I don't see the reason for points, lines and rects either. A point is a 1x1 rect and a line is a rect with a really narrow x or y. Testing for single pixel bounds is not very useful for motion detection in my experience anyway. Just having rects would make messaging simpler as well. Finally, there's no reason to do floating point computation especially in an object that is essentially a 1 bit boolean test.
I see plans to incorporate shapes like a circle, but I would propose adding the ability to test based on a mask which would cover more intricate shapes. The mask could be fed in live via an inlet or loaded from a file. One could use pix_write to display the current test areas on screen and write that out to a file. Maybe that is a different object though.
cgc
On 12/15/05, IOhannes m zmoelnig zmoelnig@iem.at wrote:
davide wrote:
hi list,
some week ago I wrote a little gem external to have hit test on images
I'd be happy if the external would be added to GEM's CVS..
thanks for the object. seems like it is detection/tracking-week in Gem-land: first the reacTable*-object, now yours. let's see what's next...
i have added it to the CVS, with small changes (like making show work). i am not sure what to do with the file-io: for one thing, i don't understand why it needs to be a binary format. what is more important, i don't understand why the load/save needs to be there at all. i guess [textfile] could handle this perfectly. probably it would be nice to have a [dump( message, which sends all the area-definitions to the 2nd outlet, so the saving could be done easier.
what do you think?
mf.adsr. IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hi Chris, list,
points are there only because they were the first type of area I implemented.. (i agree that they are not that usefull!) then I suddently realized that I needed rectangles and I wrote them.. then wip asked me to implement lines which have a different behaviour: * rects only have 2 states: ON/OFF * lines return the normalized distance between the hit point and the first point, the idea is that they can be used as invisible "sliders" (that's how I use them)
so, I agree in taking points away but I'd leave lines.
your idea of using masks is great!
about code efficency: I wrote this external in a hurry (I needed it for an installation with just 8 test areas) so I contented myself... but obviously anyone is welcome to make the code better! I'd try myself but I don't have time ATM...
ciao, Davide.
----- Original Message ----- From: "chris clepper" cgc@humboldtblvd.com To: "IOhannes m zmoelnig" zmoelnig@iem.at Cc: "davide" davide.morelli@tin.it; gem-dev@iem.at Sent: Thursday, December 15, 2005 2:41 PM Subject: Re: [GEM-dev] pix_hit
Someone was asking me about the possibility to do what this object does in GEM just this week.
I only quickly looked at the code, but I think it would be more efficient to test per pixel in a linear fashion especially for more than a few test areas. The current way is a true cache basher. I don't see the reason for points, lines and rects either. A point is a 1x1 rect and a line is a rect with a really narrow x or y. Testing for single pixel bounds is not very useful for motion detection in my experience anyway. Just having rects would make messaging simpler as well. Finally, there's no reason to do floating point computation especially in an object that is essentially a 1 bit boolean test.
I see plans to incorporate shapes like a circle, but I would propose adding the ability to test based on a mask which would cover more intricate shapes. The mask could be fed in live via an inlet or loaded from a file. One could use pix_write to display the current test areas on screen and write that out to a file. Maybe that is a different object though.
cgc
i have added it to the CVS, with small changes (like making show work). i am not sure what to do with the file-io: for one thing, i don't understand why it needs to be a binary format. what is more important, i don't understand why the load/save needs to be there at all. i guess [textfile] could handle this perfectly. probably it would be nice to have a [dump( message, which sends all the area-definitions to the 2nd outlet, so the saving could be done easier.
what do you think?
you're right! simply dumping into a textfile is ok!
using [textfile] simply didn't come in my mind when I was writing the external..
ciao, davide.
mf.adsr. IOhannes
yes, I'd remove the points mess.. ASAP I'll write a dump function..
BTW, thanks for making show work! I'll check what you changed, so I'll understand what I did wrong..
ciao, Davide.
----- Original Message ----- From: "IOhannes m zmoelnig" zmoelnig@iem.at To: "Davide Morelli" davide.morelli@tin.it Cc: gem-dev@iem.at Sent: Thursday, December 15, 2005 6:28 PM Subject: Re: [GEM-dev] pix_hit
Davide Morelli wrote:
you're right! simply dumping into a textfile is ok!
using [textfile] simply didn't come in my mind when I was writing the external..
ok, i'll remove the file-io parts from the file.
should i remove the point-tests as well?
mfg.adr IOhannes
-
B. Bogart -
chris clepper -
davide -
Davide Morelli
-
IOhannes m zmoelnig