I found a great looking set of vision libraries that might work: http://sourceforge.net/projects/vxl/ I dont have any programming skills but I'm going to poke around and see what I can do. I think that anyone with a little bit of C++ skills would be able to wrap the vcsl library within vxl to come up with a good computer vision/tracking set of objects. The question is how cpu efficient it will be? Alain > > From: <[EMAIL PROTECTED]> > Date: 2007/05/15 Tue AM 09:21:34 EDT > To: Tim Boykett <[EMAIL PROTECTED]>, "Kyle Klipowicz" <[EMAIL PROTECTED]> > CC: Pure Data List <pd-list@iem.at> > Subject: Re: [PD] pix_multiblob cpu usage > > The buigest problem with opencv (a great option I believe) is that it only > works on intell processors, so > anyone on an amd or a ppc (like me) would be screwed. If there was something > like that for all > processors it would be awsome. I think this kind of computer vision > framework is needed in PD, > specially concidering how easy an FTIR setup is to build and the > possibilities it could open. > Alain > > > > From: Tim Boykett <[EMAIL PROTECTED]> > > Date: 2007/05/15 Tue AM 07:41:45 EDT > > To: "Kyle Klipowicz" <[EMAIL PROTECTED]> > > CC: "Nose Hair" <[EMAIL PROTECTED]>, > > Pure Data List <pd-list@iem.at> > > Subject: Re: [PD] pix_multiblob cpu usage > > > > > > Of course the "obvious" solution is to port the OpenCV bits and pieces > > to PD/Gem externals :-) We did some last year for VVVV, using some > > existing > > framework, it worked within one day or so. > > > > There are several vision/video external frameworks out there; are any > > of them in Gem or elsewhere in PD (pdp, gridflow, etc)? > > > > tim > > > > > > On 15/05/2007, at 12:36 PM, Kyle Klipowicz wrote: > > > > > On 5/14/07, Nose Hair <[EMAIL PROTECTED]> wrote: > > >> I tried running it with a low res 400x300 clip and it still did > > >> the same > > >> thing. I am trying to get a game going using an FTIR setup. Here > > >> is a > > >> reference: > > >> http://cs.nyu.edu/~jhan/ftirsense/ > > > > > > Jeff Han, sweet reference of course. > > > > > >> pix_mutiblob is way to slow, I cant get gridflow compiled, and > > >> pidip is not > > >> working currently on the extended version. Is there another > > >> option to do > > >> functional multitracking on a mac with pure data? I really cant > > >> fork over > > >> the dough for max/msp/jitter, but there is a free jitter plugin > > >> called > > >> cv.jit that looks great: > > >> http://www.iamas.ac.jp/~jovan02/cv/ > > >> Is there a posibility that anyone will port this over to PD I wonder? > > > > > > I dunno if this will happen or if it is possible to port directly from > > > Jitter to Pd (maybe Gridflow or PDP/PIDIP?), but I think we could all > > > benefit with some super DSP-geek "keeping up with the Joneses" on many > > > fronts! > > > > > > ~Kyle > > > -- > > > > > > http://theradioproject.com > > > http://perhapsidid.blogspot.com > > > > > > (((())))(()()((((((((()())))()(((((((())()()())()))) > > > (())))))(()))))))))))))(((((((((((()()))))))))((()))) > > > ))(((((((((((())))())))))))))))))))__________ > > > _____())))))(((((((((((((()))))))))))_______ > > > ((((((())))))))))))((((((((000)))oOOOOOO > > > > > > _______________________________________________ > > > PD-list@iem.at mailing list > > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > > > listinfo/pd-list > > > > > > > > > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
