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