I tried to use the Gem from the latest pd extended autobuilds and I have also compiled my own from CVS with the same results. If you can point me in the right direction on how to get this going I would apreciate it. BTW I dont know any C or C+ but I am willing to give it a go. Thanks, Alain
From: "chris clepper" cgclepper@gmail.com Date: 2007/05/14 Mon AM 10:56:03 EDT To: "nosehair911@bellsouth.net" nosehair911@bellsouth.net CC: pd-list@iem.at Subject: Re: [PD] pix_multiblob cpu usage
pix_multiblob is not the most efficient code but it should run at that low resolution. Where did you get the GEM binary? It could be built without optimization.
On 5/11/07, nosehair911@bellsouth.net nosehair911@bellsouth.net wrote:
I made a 400x300 motion JPEG-a movie 15 fps with 5 solid blue circles moving on a black background to test pix_mutiblob. I open it up with pix_film, flip it with pix_flip and send it to pix_multiblob. I suddenly notices PD getting very, very slow. When I look at the cpu usage in activity monitor (if you can believe activity monitor) I get 100-104% cpu usage. I cant do anything else in PD because PD gets so slow. I am using a dual 2Ghz G5 with ATI Radeon 9800 XT and 3GB of internal memory. Is this normal? What can I do to lower cpu usage? What else can I use within Gem to get the same results? I eventually want to be able to track 20-30 objects but It looks like it would be imposible at this rate. Thanks, Alain
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I ran the pix_multiblob example on the same 640x480 clip on CoreDuo, G5 and Xeon CPUs at 2 Ghz and it destroys all of those processors. I guess it was designed to work on really low resolutions since none of the current CPUs can handle full sized standard def video as the code is written.
If the code could be written without the numerous function calls and int to float to int conversions in the processing loop it would be much faster.
On 5/14/07, nosehair911@bellsouth.net nosehair911@bellsouth.net wrote:
I tried to use the Gem from the latest pd extended autobuilds and I have also compiled my own from CVS with the same results. If you can point me in the right direction on how to get this going I would apreciate it. BTW I dont know any C or C+ but I am willing to give it a go. Thanks, Alain
From: "chris clepper" cgclepper@gmail.com Date: 2007/05/14 Mon AM 10:56:03 EDT To: "nosehair911@bellsouth.net" nosehair911@bellsouth.net CC: pd-list@iem.at Subject: Re: [PD] pix_multiblob cpu usage
pix_multiblob is not the most efficient code but it should run at that
low
resolution. Where did you get the GEM binary? It could be built
without
optimization.
On 5/11/07, nosehair911@bellsouth.net nosehair911@bellsouth.net wrote:
I made a 400x300 motion JPEG-a movie 15 fps with 5 solid blue circles moving on a black background to test pix_mutiblob. I open it up with pix_film, flip it with
pix_flip
and send it to pix_multiblob. I suddenly notices PD getting very, very slow. When I look at the cpu usage in activity monitor (if you can believe activity monitor) I get 100-104% cpu usage. I cant do anything else
in PD
because PD gets so slow. I am using a dual 2Ghz G5 with ATI Radeon 9800 XT and 3GB of internal memory. Is this normal? What can I do to lower cpu usage? What else can I use within Gem to get
the
same results? I eventually want to be able to track 20-30 objects but It looks like it would be
imposible
at this rate. Thanks, Alain
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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/
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?
Alain
On May 14, 2007, at 12:49 PM, chris clepper wrote:
I ran the pix_multiblob example on the same 640x480 clip on
CoreDuo, G5 and Xeon CPUs at 2 Ghz and it destroys all of those
processors. I guess it was designed to work on really low
resolutions since none of the current CPUs can handle full sized
standard def video as the code is written.If the code could be written without the numerous function calls
and int to float to int conversions in the processing loop it would
be much faster.On 5/14/07, nosehair911@bellsouth.net nosehair911@bellsouth.net
wrote: I tried to use the Gem from the latest pd extended autobuilds and I
have also compiled my own from CVS with the same results. If you can point me in the right
direction on how to get this going I would apreciate it. BTW I dont know any C or C+ but I am willing to give
it a go. Thanks, AlainFrom: "chris clepper" cgclepper@gmail.com Date: 2007/05/14 Mon AM 10:56:03 EDT To: " nosehair911@bellsouth.net" nosehair911@bellsouth.net CC: pd-list@iem.at Subject: Re: [PD] pix_multiblob cpu usage
pix_multiblob is not the most efficient code but it should run at
that low
resolution. Where did you get the GEM binary? It could be built
without
optimization.
On 5/11/07, nosehair911@bellsouth.net nosehair911@bellsouth.net
wrote:
I made a 400x300 motion JPEG-a movie 15 fps with 5 solid blue
circles
moving on a black background to test pix_mutiblob. I open it up with pix_film, flip it with
pix_flip
and send it to pix_multiblob. I suddenly notices PD getting very, very slow. When I look at the cpu
usage in
activity monitor (if you can believe activity monitor) I get 100-104% cpu usage. I cant do anything
else in PD
because PD gets so slow. I am using a dual 2Ghz G5 with ATI Radeon 9800 XT and 3GB of
internal
memory. Is this normal? What can I do to lower cpu usage? What else can I use within Gem to
get the
same results? I eventually want to be able to track 20-30 objects but It looks like it would be
imposible
at this rate. Thanks, Alain
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 5/14/07, Nose Hair nosehair911@bellsouth.net 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
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 nosehair911@bellsouth.net 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
On 5/15/07, Tim Boykett tim@timesup.org wrote:
There are several vision/video external frameworks out there; are any of them in Gem or elsewhere in PD (pdp, gridflow, etc)?
There's pix_artoolkit which is ARToolkit based and pix_fiducialtrack which implements the tracking system used by the reacTable.
wiouw!
pix_artoolkit would be very cool. I have seen some of the ARtoolKit
stuff and
it looks good. I am currently in OSX land, does anyone know whether
the building of pix_artoolkit for OSX can be done?
chrz,
tm
On 15/05/2007, at 4:30 PM, chris clepper wrote:
On 5/15/07, Tim Boykett tim@timesup.org wrote:
There are several vision/video external frameworks out there; are any of them in Gem or elsewhere in PD (pdp, gridflow, etc)?
There's pix_artoolkit which is ARToolkit based and
pix_fiducialtrack which implements the tracking system used by the
reacTable.
pix_artoolkit builds and appears to run. I have no idea how to effectively use it though.
On 5/15/07, Tim Boykett tim@timesup.org wrote:
wiouw!
pix_artoolkit would be very cool. I have seen some of the ARtoolKit stuff and it looks good. I am currently in OSX land, does anyone know whether the building of pix_artoolkit for OSX can be done?
chrz,
tm
chris, are you using it on OSX? Was it hard to compile?
I am trying to stick with the autobuilds and installers from .hc
because I
want to be using the same system that colleagues, students, etc can
use without major compilation hassles. Is it likely that we can get
this into the standard GEM build, or are there reasons not to?
Cheers,
tim
On 15/05/2007, at 6:34 PM, chris clepper wrote:
pix_artoolkit builds and appears to run. I have no idea how to
effectively use it though.On 5/15/07, Tim Boykett < tim@timesup.org> wrote: wiouw!
pix_artoolkit would be very cool. I have seen some of the ARtoolKit stuff and it looks good. I am currently in OSX land, does anyone know whether the building of pix_artoolkit for OSX can be done?
chrz,
tm
-
chris clepper -
Kyle Klipowicz -
Nose Hair -
nosehair911＠bellsouth.net
-
Tim Boykett