I would suggest you try to modify pix_multiblob for better performance.  This will get you familiar with C++, pixel processing, and how GEM is written.  Also, and perhaps most important, you would learn what makes code fast or slow. 

The first clues for why pix_multiblob takes for ever to process are that it uses floating point processing and makes function calls inside the processing loop.  

AS far as 'wrapping' OpenCV the most basic method would be to build a lib and make calls to it for all of the processing.  I don't think that will necessarily be very efficient though.

Since you are a novice programmer you might also find a CV/tracking application that uses OSC or other network protocol to communicate with Pd.

On 5/17/07, nosehair911@bellsouth.net <nosehair911@bellsouth.net> wrote:
I am trying to get an FTIR setup going and I need a good motion tracker for os 10.4.9.  I cant get gridflow
to compile, I love the pix_multiblob but its way to cpu hungry so I decided to write my own.  I have never
programed in C nor have I ever read any manuals but I'm willing to try.  My question is do I need to know
C before hand or can I get away with reading this:
http://iem.at/pd/externals-HOWTO/
BTW I am not starting from scratch, if that were so I would never try this.  I am trying to go the opencv
route and wrap these for Pd:
http://opencvlibrary.sourceforge.net/cvBlobsLib
Anothe question is would it be easier to try to write it as a standalone external or as part of Gem like a
pix_cvBlobs object?  Where can I find information on developing for Gem like the externals how-to?
Thanks,
Alain


_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list