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