[PD] PDP and/or GEM for live video processing
marius.schebella at gmail.com
Wed Jul 9 16:35:32 CEST 2008
you can do everything in GEM. the pdp-gem bridge is slow afaik, so
staying in either the pdp domain or the gem domain is a good idea.
and I guess both will do background subtraction. look at pix_background
for a quickstart. it depends what else you need, whether you want to
track motion or objects against a reference frame, whether you want the
actual result of the background subtraction, which will work best with a
writing the movies into the memory can eat quite a lot of memory, but
writing to disk is slow, so you may want to find a good solution for that.
no issues with macbook pro except make sure that you have drivers for
your video source, usually no problem. the native format on mac is YUV,
so maybe you will have to add pix_rgba at some place, but just try it out.
Spencer Russell wrote:
> I recently convinced the video guy for a play I'm sound designing to
> use PD instead of Max/MSP/Jitter so that we can work together and run
> the audio and video off of the same laptop. The problem is that I
> don't have a lot of experience doing video in PD or using PD on OSX,
> but I've been doing PD on linux for live audio processing for about 4
> He's done about a month's worth of research into using Jitter, so I
> want to make the transition as easy as possible, and perhaps win
> another PD convert. Mostly what we need to do is record video with
> background subtraction, and then play multiple layers of it back with
> some effects so that the actor can interact with himself. Is it more
> computationally efficient to use straight PDP, straight GEM, or some
> combination? I'd like to use GEM's [pix_video] object, because it can
> talk to the OSX video system, but I'd imagine the PDP video processing
> stuff is more efficient, as it's not concerned with texturing a
> rectangle and displaying it in 3D. We're running the show on a Macbook
> pro, so it's hardware accelerated. I've got the GEM<->PDP conversion
> figured out in both directions using [pix_2pdp] and [pdp2gem].
> Any OSX pitfalls I should be aware of? I don't have access to a
> macbook pro myself, so I can't test things before I try to get it
> working on his machine. Should I expect any problems from GEM display
> or from the [pdp_glx] output?
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list