[PD] opencv motion tracker external HELP!

chris clepper cgclepper at gmail.com
Tue May 29 17:34:28 CEST 2007


The Intel library struct is a different data type than the Pd symbol
data type.  Pd doesn't have any idea what your frame pointer is
pointing to so it throw that error.  You really need to have a working
knowledge of C data types to do what you want to do.

On 5/29/07, nosehair911 at bellsouth.net <nosehair911 at bellsouth.net> wrote:
> I dont think I quite understood.  I tried:
>
> #define FRAMEOUT frame
>
> IplImage *frame = 0;
>
> x->x_outlet = outlet_new(&x->x_obj, &s_anything);
> outlet_anything(x->x_outlet, FRAMEOUT);
>
> with the same results.  Maybe someone can dumb it down for me?
> Alain
> >
> > From: IOhannes m zmoelnig <zmoelnig at iem.at>
> > Date: 2007/05/29 Tue AM 10:40:29 EDT
> > To: nosehair911 at bellsouth.net
> > CC: Tim Boykett <tim at timesup.org>,   pd-list at iem.at
> > Subject: Re: [PD] opencv motion tracker external HELP!
> >
> > nosehair911 at bellsouth.net wrote:
> > > Thanks for helping.  Well I basically have a rough sketch of all the objects but I am having a tough
> > > time with the outlet system.  In a nutshell opencv uses an image structure called "typedef struct
> > > _IplImage."  Acording to them "The structure IplImage came from Intel Image Processing Library
> > > where the format is native."  I can give you more information about it if you need it.  My problem is
> > > sending the result from IplImage to an outlet and being able to receive it from an inlet.  So far that
> is
> > > my bigest hurdle.  I have this code:
> > >
> > > IplImage *frame = 0;
> > >
> > > x->x_outlet = outlet_new(&x->x_obj, &s_anything);
> > > outlet_anything(x->x_outlet, frame);
> > >
> > > Obviously with more stuff in the middle but I keep getting this error from the compiler:
> >
> >
> > whoa don't do that.
> >
> > if you are sure that you have to send pointers around, then you should
> > a) have a look at Gem (where this is done) or GridFlow and
> > b) don't do it (Gem is using this for legacy reasons); really. even
> > though pd has "pointers", they are not meant for passing arbitrary data
> > around.
> >
> > if you want to do it the clean way, you will have to create ids (numeric
> > or symbolic), associate your data-chunks with ids, pass the ids through
> > pd's messaging system and look them up at the receiving side.
> > pdp does it like this.
> >
> > an alternative might be mrpeach's "string/blob" patch, but then you
> > would rely on a patched pd, which is not a very good idea.
> >
> > if you are not sure, then i suggest to not do it that way (unless you
> > want to spend some time in getting into coding)
> >
> >
> > otoh, why don't you just use the Gem framework?
> > i guess that you could fit the IplImage into an imageStruct with not
> > much overhead (but then i don't know this structure; if it is
> > fundamentally different from Gem's imageStruct you might lose everything
> > you gained speedwise)
> >
> >
> >
> > if nothing else works, it might be simplest to just write your own
> > application (without pd) and send the data to pd via your favourite
> > protocol (FUDI, OSC, SMTP...)
> >
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>




More information about the Pd-list mailing list