I made a quick makefile and build for GNU/Linux and Mac OS X/Intel of
William Brent's [pix_motion_sector] which gives you sector-based video
tracking:
http://puredata.info/Members/hans/PixMotionSector
.hc
Information wants to be free. -Stewart Brand
On Fri, May 14, 2010 at 1:28 AM, Hans-Christoph Steiner hans@at.or.atwrote:
I made a quick makefile and build for GNU/Linux and Mac OS X/Intel of William Brent's [pix_motion_sector] which gives you sector-based video tracking:
http://puredata.info/Members/hans/PixMotionSector
.hc
Hi Hans and list,
gemwin object seems to be missed in the help file. It should be added. One question: pix_movement_sector seems a pix_movement object with a pix_crop implementation, it is right? BTW great work William! and good job Hans to binarize it! husk
Yes - it's exactly that: an adaptation of pix_movement that lets you specify an area to analyze. That way you can use several instances to create multiple regions for triggering different events. I haven't looked at this in two years! I'll take a look at the helpfile and see what's missing/unclear.
On Thu, May 13, 2010 at 5:47 PM, Husk 00 husk00@gmail.com wrote:
On Fri, May 14, 2010 at 1:28 AM, Hans-Christoph Steiner hans@at.or.at wrote:
I made a quick makefile and build for GNU/Linux and Mac OS X/Intel of William Brent's [pix_motion_sector] which gives you sector-based video tracking:
http://puredata.info/Members/hans/PixMotionSector
.hc
Hi Hans and list, gemwin object seems to be missed in the help file. It should be added. One question: pix_movement_sector seems a pix_movement object with a pix_crop implementation, it is right? BTW great work William! and good job Hans to binarize it! husk _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you specify an area to analyze. That way you can use several instances to create multiple regions for triggering different events. I haven't looked at this in two years! I'll take a look at the helpfile and see what's missing/unclear.
what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Yeah, it's just fewer objects, and [pix_motion_sector] reports the % of pixels that have changed in the region. That makes it easy to set up triggers with an instance of moses. I worked on that a couple years ago and haven't really thought about it until Hans posted the link. I don't mean to hijack the thread, but right now I'm interested in getting feedback on this table info/manip extern:
http://williambrent.conflations.com/pages/research.html#tabletool
I posted it on another thread earlier today and added several more functions since. Nothing that you can't do in other ways, but I think these things are useful to have easy access to:
- dumping a table to a list
- reporting the length of a table
- offsetting (adding a constant to all values)
- scaling (multiplying all values by a scalar)
- curve smoothing
- shifting values forward or back by index
- shuffling values randomly
- sorting values from low to high
- sorting a sub-range of values from low to high
- reversing
- inverting
- normalizing to a specified range
- normalizing so values sum to 1.0
- copying a source table to a target table
- copying a specified range of a source table to a target table
- lacing alternating values from two tables into one table
- table sum
- table mean
- table arithmetic mean
- table geometric mean
- table integration
- table differentiation
- adding two tables
- subtracting two tables
- multiplying two tables
- dividing two tables
- dot product between two tables
- Euclidean distance between two tables
- Manhattan distance between two tables
- Pearson correlation coefficient between two tables
- reporting minimum value (and its index)
- reporting maximum value (and its index)
- reporting the closest value in the table to a given value (and its index)
- number of occurrences of a given value (and a list of their indices)
- number of occurrences of a value less than a given value (and a list
of their indices)
- number of occurrences of a value greater than a given value (and a
list of their indices)
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you specify an area to analyze. That way you can use several instances to create multiple regions for triggering different events. I haven't looked at this in two years! I'll take a look at the helpfile and see what's missing/unclear.
what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard matju@artengine.cawrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you
specify an area to analyze. That way you can use several instances to create multiple regions for triggering different events. I haven't looked at this in two years! I'll take a look at the helpfile and see what's missing/unclear.
what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard matju@artengine.cawrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you
specify an area to analyze. That way you can use several instances to create multiple regions for triggering different events. I haven't looked at this in two years! I'll take a look at the helpfile and see what's missing/unclear.
what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard matju@artengine.cawrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you
specify an area to analyze. That way you can use several instances to create multiple regions for triggering different events. I haven't looked at this in two years! I'll take a look at the helpfile and see what's missing/unclear.
what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region?
[pix_movement] + [pix_blob] ? ++
Jack
Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard matju@artengine.cawrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you
specify an area to analyze. That way you can use several instances to create multiple regions for triggering different events. I haven't looked at this in two years! I'll take a look at the helpfile and see what's missing/unclear.
what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard matju@artengine.cawrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you
specify an area to analyze. That way you can use several instances to create multiple regions for triggering different events. I haven't looked at this in two years! I'll take a look at the helpfile and see what's missing/unclear.
what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I see - [pix dump] will give you a list you can search to accumulate the number of pixels associated with movement. I was hoping for an object that would return that value, but maybe accumulating in Pd is no slower in this case. To me it's just a preference...I'd rather have an extern than an abstraction for some things. But that's the beautiful thing about Pd - you can make what you want however you like. :)
2010/5/14 Jack jack@rybn.org:
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard matju@artengine.cawrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you
specify an area to analyze. That way you can use several instances to create multiple regions for triggering different events. I haven't looked at this in two years! I'll take a look at the helpfile and see what's missing/unclear.
what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'd love to see an example implementation of this as a patch, if
anyone is up for it. A lot of students ask me for this kind of video
tracking. It would be good to add to the video tracking examples.
.hc
On May 14, 2010, at 10:11 AM, Jack wrote:
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much
for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements
in a large table is much faster in an extern than with an [until] loop.In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels
that crossed [pix_movement]'s threshold in the cropped region?[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard <matju@artengine.ca
wrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets
youspecify an area to analyze. That way you can use several
instances to create multiple regions for triggering different events. I
haven't looked at this in two years! I'll take a look at the helpfile and see
what's missing/unclear.what's the difference between that, and using [pix_crop] and
[pix_movement] with [pix_separator] ?Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually
quite small, compared to the pixel operations.you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would
suggest looking into abstractions :-) it's definitely less lines of code
(at a minimum 10 lines of Pd code) and still only a single object...mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
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
"We have nothing to fear from love and commitment." - New York Senator
Diane Savino, trying to convince the NY Senate to pass a gay marriage
bill
2010/5/14 Hans-Christoph Steiner hans@at.or.at
I'd love to see an example implementation of this as a patch, if anyone is up for it. A lot of students ask me for this kind of video tracking. It would be good to add to the video tracking examples.
.hc
I'm exactly on this... I was preparing a little video tracking patch with pix_movement+pix_crop for my next workshop, but now I'll use pix_movement_sector.
soon some news. cheers husk
On May 14, 2010, at 12:04 PM, Husk 00 wrote:
2010/5/14 Hans-Christoph Steiner hans@at.or.at
I'd love to see an example implementation of this as a patch, if
anyone is up for it. A lot of students ask me for this kind of
video tracking. It would be good to add to the video tracking
examples..hc
I'm exactly on this... I was preparing a little video tracking patch with pix_movement +pix_crop for my next workshop, but now I'll use pix_movement_sector.
soon some news. cheers husk
Well, a patch version would be nicer, since it would be easier to use,
and could easily be included with the Gem examples.
.hc
If you are not part of the solution, you are part of the problem.
I'll update the helpfile for [pix_motion_sector] to include a subpatch that does the same thing with [pix_crop], [pix_movement], and [pix_dump]. I think I might also change the source and try taking the distance between current/previous frames using all RGB info instead of a greyscale approximation. The speed issue aside, that may be a significant difference from [pix_movement] worth investigating.
On Fri, May 14, 2010 at 8:43 AM, Hans-Christoph Steiner hans@at.or.at wrote:
I'd love to see an example implementation of this as a patch, if anyone is up for it. A lot of students ask me for this kind of video tracking. It would be good to add to the video tracking examples.
.hc
On May 14, 2010, at 10:11 AM, Jack wrote:
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard matju@artengine.cawrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you > > specify an area to analyze. That way you can use several instances > to > create multiple regions for triggering different events. I haven't > looked > at this in two years! I'll take a look at the helpfile and see > what's > missing/unclear. > what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
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
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
On 2010-05-14 18:27, William Brent wrote:
I'll update the helpfile for [pix_motion_sector] to include a subpatch that does the same thing with [pix_crop], [pix_movement], and [pix_dump]. I think I might also change the source and try taking the distance between current/previous frames using all RGB info instead of a greyscale approximation. The speed issue aside, that may be a significant difference from [pix_movement] worth investigating.
btw, instead of [pix_dump] (which will kill performance), why not use [pix_mean_color]?
fgmasdr IOhannes
The seventh outlet of [pix_info] return [1 0( when the pix change (instead of [0 0(). ++
Jack
Le vendredi 14 mai 2010 à 18:40 +0200, IOhannes m zmoelnig a écrit :
On 2010-05-14 18:27, William Brent wrote:
I'll update the helpfile for [pix_motion_sector] to include a subpatch that does the same thing with [pix_crop], [pix_movement], and [pix_dump]. I think I might also change the source and try taking the distance between current/previous frames using all RGB info instead of a greyscale approximation. The speed issue aside, that may be a significant difference from [pix_movement] worth investigating.
btw, instead of [pix_dump] (which will kill performance), why not use [pix_mean_color]?
fgmasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sorry, [pix_info] is irrelevant in your case. ++
Jack
Le vendredi 14 mai 2010 à 19:05 +0200, Jack a écrit :
The seventh outlet of [pix_info] return [1 0( when the pix change (instead of [0 0(). ++
Jack
Le vendredi 14 mai 2010 à 18:40 +0200, IOhannes m zmoelnig a écrit :
On 2010-05-14 18:27, William Brent wrote:
I'll update the helpfile for [pix_motion_sector] to include a subpatch that does the same thing with [pix_crop], [pix_movement], and [pix_dump]. I think I might also change the source and try taking the distance between current/previous frames using all RGB info instead of a greyscale approximation. The speed issue aside, that may be a significant difference from [pix_movement] worth investigating.
btw, instead of [pix_dump] (which will kill performance), why not use [pix_mean_color]?
fgmasdr IOhannes
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
how come it is irrelevant?
btw i included your shader to the patches http://web.uni-weimar.de/medien/wiki/Bewegungsmelder
m.
Am 14.05.2010 um 19:27 schrieb Jack:
Sorry, [pix_info] is irrelevant in your case. ++
Jack
Le vendredi 14 mai 2010 à 19:05 +0200, Jack a écrit :
The seventh outlet of [pix_info] return [1 0( when the pix change (instead of [0 0(). ++
Jack
Le vendredi 14 mai 2010 à 18:40 +0200, IOhannes m zmoelnig a écrit :
On 2010-05-14 18:27, William Brent wrote:
I'll update the helpfile for [pix_motion_sector] to include a subpatch that does the same thing with [pix_crop], [pix_movement], and [pix_dump]. I think I might also change the source and try taking the distance between current/previous frames using all RGB info instead of a greyscale approximation. The speed issue aside, that may be a significant difference from [pix_movement] worth investigating.
btw, instead of [pix_dump] (which will kill performance), why not use [pix_mean_color]?
fgmasdr IOhannes
Hello Max,
Le vendredi 14 mai 2010 à 20:33 +0200, Max a écrit :
how come it is irrelevant?
Because this is not the purpose for the William's patch ;)
btw i included your shader to the patches http://web.uni-weimar.de/medien/wiki/Bewegungsmelder
OK, nice ! :) ++
Jack
m.
Am 14.05.2010 um 19:27 schrieb Jack:
Sorry, [pix_info] is irrelevant in your case. ++
Jack
Le vendredi 14 mai 2010 à 19:05 +0200, Jack a écrit :
The seventh outlet of [pix_info] return [1 0( when the pix change (instead of [0 0(). ++
Jack
Le vendredi 14 mai 2010 à 18:40 +0200, IOhannes m zmoelnig a écrit :
On 2010-05-14 18:27, William Brent wrote:
I'll update the helpfile for [pix_motion_sector] to include a subpatch that does the same thing with [pix_crop], [pix_movement], and [pix_dump]. I think I might also change the source and try taking the distance between current/previous frames using all RGB info instead of a greyscale approximation. The speed issue aside, that may be a significant difference from [pix_movement] worth investigating.
btw, instead of [pix_dump] (which will kill performance), why not use [pix_mean_color]?
fgmasdr IOhannes
Am 14.05.2010 um 18:40 schrieb IOhannes m zmoelnig:
On 2010-05-14 18:27, William Brent wrote:
I'll update the helpfile for [pix_motion_sector] to include a subpatch that does the same thing with [pix_crop], [pix_movement], and [pix_dump]. I think I might also change the source and try taking the distance between current/previous frames using all RGB info instead of a greyscale approximation. The speed issue aside, that may be a significant difference from [pix_movement] worth investigating.
btw, instead of [pix_dump] (which will kill performance), why not use [pix_mean_color]?
like this?
Perfect...
On Fri, May 14, 2010 at 10:08 AM, Max abonnements@revolwear.com wrote:
Am 14.05.2010 um 18:40 schrieb IOhannes m zmoelnig:
On 2010-05-14 18:27, William Brent wrote:
I'll update the helpfile for [pix_motion_sector] to include a subpatch that does the same thing with [pix_crop], [pix_movement], and [pix_dump]. I think I might also change the source and try taking the distance between current/previous frames using all RGB info instead of a greyscale approximation. The speed issue aside, that may be a significant difference from [pix_movement] worth investigating.
btw, instead of [pix_dump] (which will kill performance), why not use [pix_mean_color]?
like this?
I've updated the helpfile and source for pix_motion_sector. It now compares pixels using RGB vectors instead of just grayscale. Husk - if you're planning to use it, definitely update to this version:
http://williambrent.conflations.com/pages/research.html#pix_motion_sector
Hans, would you mind updating the version you're hosting as well?
On Fri, May 14, 2010 at 9:27 AM, William Brent william.brent@gmail.com wrote:
I'll update the helpfile for [pix_motion_sector] to include a subpatch that does the same thing with [pix_crop], [pix_movement], and [pix_dump]. I think I might also change the source and try taking the distance between current/previous frames using all RGB info instead of a greyscale approximation. The speed issue aside, that may be a significant difference from [pix_movement] worth investigating.
On Fri, May 14, 2010 at 8:43 AM, Hans-Christoph Steiner hans@at.or.at wrote:
I'd love to see an example implementation of this as a patch, if anyone is up for it. A lot of students ask me for this kind of video tracking. It would be good to add to the video tracking examples.
.hc
On May 14, 2010, at 10:11 AM, Jack wrote:
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard matju@artengine.cawrote:
> On Thu, 13 May 2010, William Brent wrote: > > Yes - it's exactly that: an adaptation of pix_movement that lets you >> >> specify an area to analyze. That way you can use several instances >> to >> create multiple regions for triggering different events. I haven't >> looked >> at this in two years! I'll take a look at the helpfile and see >> what's >> missing/unclear. >> > what's the difference between that, and using [pix_crop] and > [pix_movement] > with [pix_separator] ? >
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
> _ _ __ ___ _____ ________ _____________ _____________________ ... > | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 > _______________________________________________ > 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
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
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com
I can update it, but I think it makes more sense for you to have it on
your website. Just running "make" with that makefile should do it,
after you point it to the Pd and Gem sources.
.hc
On May 14, 2010, at 8:50 PM, William Brent wrote:
I've updated the helpfile and source for pix_motion_sector. It now compares pixels using RGB vectors instead of just grayscale. Husk - if you're planning to use it, definitely update to this version:
http://williambrent.conflations.com/pages/research.html#pix_motion_sector
Hans, would you mind updating the version you're hosting as well?
On Fri, May 14, 2010 at 9:27 AM, William Brent <william.brent@gmail.com
wrote: I'll update the helpfile for [pix_motion_sector] to include a
subpatch that does the same thing with [pix_crop], [pix_movement], and [pix_dump]. I think I might also change the source and try taking
the distance between current/previous frames using all RGB info instead
of a greyscale approximation. The speed issue aside, that may be a significant difference from [pix_movement] worth investigating.On Fri, May 14, 2010 at 8:43 AM, Hans-Christoph Steiner <hans@at.or.at
wrote:
I'd love to see an example implementation of this as a patch, if
anyone is up for it. A lot of students ask me for this kind of video
tracking. It would be good to add to the video tracking examples..hc
On May 14, 2010, at 10:11 AM, Jack wrote:
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C
and was amazed to see that the CPU load was exactly the same. So
much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the
elements in a large table is much faster in an extern than with an [until] loop.In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in
the region? Is there an obvious way to count up the number of
pixels that crossed [pix_movement]'s threshold in the cropped region?[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote: > > On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard > matju@artengine.cawrote: > >> On Thu, 13 May 2010, William Brent wrote: >> >> Yes - it's exactly that: an adaptation of pix_movement that
>> lets you >>> >>> specify an area to analyze. That way you can use several
>>> instances >>> to >>> create multiple regions for triggering different events. I
>>> haven't >>> looked >>> at this in two years! I'll take a look at the helpfile and
>>> see >>> what's >>> missing/unclear. >>> >> what's the difference between that, and using [pix_crop] and >> [pix_movement] >> with [pix_separator] ? >> > > Please correct me if I'm wrong, > Doesn't having these as externals instead of abstractions,
> make it > significantly faster/efficient? > particularly if you have many of them? >no not necessarily. the overhead for message communication between objects is
usually quite small, compared to the pixel operations.you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i
haven't looked at the code), is that you wouldn't have to copy the data
for cropping at all, but only use the pixels in the ROI.as for williams argument, that you need less objects, i would
suggest looking into abstractions :-) it's definitely less lines of
code (at a minimum 10 lines of Pd code) and still only a single object...mfgasdr IOhannes
> best, > > J > >> _ _ __ ___ _____ ________ _____________
>> _____________________ ... >> | Mathieu Bouchard, Montréal, Québec. téléphone:
>> +1.514.383.3801 >> _______________________________________________ >> 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-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
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
"We have nothing to fear from love and commitment." - New York
Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com
Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice,
it can change entire economies. - Amy Smith
On Fri, 14 May 2010, William Brent wrote:
I've updated the helpfile and source for pix_motion_sector. It now compares pixels using RGB vectors instead of just grayscale. Husk - if you're planning to use it, definitely update to this version: http://williambrent.conflations.com/pages/research.html#pix_motion_sector
There's a space at the beginning of the zip's filename.
It doesn't state how it is computing the distance between two RGB colours : is it using different weights for the channels ? are you using a L1 metric, a L2 metric, anything else ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Oops - the .zip with the space shouldn't have been up there - that was an earlier draft from today. Just trash anything you downloaded previously and get the current version via the link if you ever intend to use this.
The distance between the two RGB pixels is Euclidean, and there's no weighting. I guess I could set up messages for weight arguments and distance metrics to let people fine tune.
On Fri, May 14, 2010 at 7:39 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Fri, 14 May 2010, William Brent wrote:
I've updated the helpfile and source for pix_motion_sector. It now compares pixels using RGB vectors instead of just grayscale. Husk - if you're planning to use it, definitely update to this version: http://williambrent.conflations.com/pages/research.html#pix_motion_sector
There's a space at the beginning of the zip's filename.
It doesn't state how it is computing the distance between two RGB colours : is it using different weights for the channels ? are you using a L1 metric, a L2 metric, anything else ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
i would too but i get a GEM error so it seems with this external, I assume it's related to GEM I am on a friends Mac 10.5.8 w/ Pd extended 041.4 and GEM 0.91.3
pp
/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/p/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup
pix_motion_sector ... couldn't create /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookupat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup
pix_motion_sector ... couldn't create /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup ________________________________________ From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] On Behalf Of Hans-Christoph Steiner [hans@at.or.at] Sent: Friday, May 14, 2010 11:43 AM To: Jack Cc: PD List; IOhannes m zmölnig Subject: Re: [PD] pix_motion_sector
I'd love to see an example implementation of this as a patch, if anyone is up for it. A lot of students ask me for this kind of video tracking. It would be good to add to the video tracking examples.
.hc
On May 14, 2010, at 10:11 AM, Jack wrote:
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard <matju@artengine.ca
wrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you
specify an area to analyze. That way you can use several instances to create multiple regions for triggering different events. I haven't looked at this in two years! I'll take a look at the helpfile and see what's missing/unclear.
what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
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
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Are you getting this problem with the pre-compiled binary from my site? That one was built using GEM 0.92.2. If you haven't tried already, download the source and update the first two lines of the makefile to point to your Pd and GEM sources. It builds fine here on OSX 10.5.8, GEM 0.92-2, Pd-0.42-5. The binary works in Pd-ext 0.41-4 as well.
2010/5/19 Pagano, Patrick pat@digitalworlds.ufl.edu:
i would too but i get a GEM error so it seems with this external, I assume it's related to GEM I am on a friends Mac 10.5.8 w/ Pd extended 041.4 and GEM 0.91.3
pp
/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/p/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup
pix_motion_sector ... couldn't create /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookupat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup
pix_motion_sector ... couldn't create /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup ________________________________________ From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] On Behalf Of Hans-Christoph Steiner [hans@at.or.at] Sent: Friday, May 14, 2010 11:43 AM To: Jack Cc: PD List; IOhannes m zmölnig Subject: Re: [PD] pix_motion_sector
I'd love to see an example implementation of this as a patch, if anyone is up for it. A lot of students ask me for this kind of video tracking. It would be good to add to the video tracking examples.
.hc
On May 14, 2010, at 10:11 AM, Jack wrote:
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard <matju@artengine.ca
wrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you > specify an area to analyze. That way you can use several > instances to > create multiple regions for triggering different events. I > haven't looked > at this in two years! I'll take a look at the helpfile and see > what's > missing/unclear. > what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
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
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
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
This person does not have the Gem sources, they were interested in the tracking and I was trying to show it quickly. Where is GEM 92.2?
pp
-----Original Message----- From: William Brent [mailto:william.brent@gmail.com] Sent: Wednesday, May 19, 2010 4:54 PM To: Pagano, Patrick Cc: Hans-Christoph Steiner; Jack; PD List; IOhannes m zmölnig Subject: Re: [PD] pix_motion_sector
Are you getting this problem with the pre-compiled binary from my site? That one was built using GEM 0.92.2. If you haven't tried already, download the source and update the first two lines of the makefile to point to your Pd and GEM sources. It builds fine here on OSX 10.5.8, GEM 0.92-2, Pd-0.42-5. The binary works in Pd-ext 0.41-4 as well.
2010/5/19 Pagano, Patrick pat@digitalworlds.ufl.edu:
i would too but i get a GEM error so it seems with this external, I assume it's related to GEM I am on a friends Mac 10.5.8 w/ Pd extended 041.4 and GEM 0.91.3
pp
/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/p/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup
pix_motion_sector ... couldn't create /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookupat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup
pix_motion_sector ... couldn't create /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup ________________________________________ From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] On Behalf Of Hans-Christoph Steiner [hans@at.or.at] Sent: Friday, May 14, 2010 11:43 AM To: Jack Cc: PD List; IOhannes m zmölnig Subject: Re: [PD] pix_motion_sector
I'd love to see an example implementation of this as a patch, if anyone is up for it. A lot of students ask me for this kind of video tracking. It would be good to add to the video tracking examples.
.hc
On May 14, 2010, at 10:11 AM, Jack wrote:
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard <matju@artengine.ca
wrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you > specify an area to analyze. That way you can use several > instances to > create multiple regions for triggering different events. I > haven't looked > at this in two years! I'll take a look at the helpfile and see > what's > missing/unclear. > what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
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
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
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
found it and that fixed it, sorry brain freeze
From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] On Behalf Of Pagano, Patrick [pat@digitalworlds.ufl.edu] Sent: Wednesday, May 19, 2010 4:58 PM To: William Brent Cc: PD List; IOhannes m zmölnig Subject: Re: [PD] pix_motion_sector
This person does not have the Gem sources, they were interested in the tracking and I was trying to show it quickly. Where is GEM 92.2?
pp
-----Original Message----- From: William Brent [mailto:william.brent@gmail.com] Sent: Wednesday, May 19, 2010 4:54 PM To: Pagano, Patrick Cc: Hans-Christoph Steiner; Jack; PD List; IOhannes m zmölnig Subject: Re: [PD] pix_motion_sector
Are you getting this problem with the pre-compiled binary from my site? That one was built using GEM 0.92.2. If you haven't tried already, download the source and update the first two lines of the makefile to point to your Pd and GEM sources. It builds fine here on OSX 10.5.8, GEM 0.92-2, Pd-0.42-5. The binary works in Pd-ext 0.41-4 as well.
2010/5/19 Pagano, Patrick pat@digitalworlds.ufl.edu:
i would too but i get a GEM error so it seems with this external, I assume it's related to GEM I am on a friends Mac 10.5.8 w/ Pd extended 041.4 and GEM 0.91.3
pp
/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/p/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup
pix_motion_sector ... couldn't create /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookupat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup
pix_motion_sector ... couldn't create /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup ________________________________________ From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] On Behalf Of Hans-Christoph Steiner [hans@at.or.at] Sent: Friday, May 14, 2010 11:43 AM To: Jack Cc: PD List; IOhannes m zmölnig Subject: Re: [PD] pix_motion_sector
I'd love to see an example implementation of this as a patch, if anyone is up for it. A lot of students ask me for this kind of video tracking. It would be good to add to the video tracking examples.
.hc
On May 14, 2010, at 10:11 AM, Jack wrote:
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard <matju@artengine.ca
wrote:
On Thu, 13 May 2010, William Brent wrote:
Yes - it's exactly that: an adaptation of pix_movement that lets you > specify an area to analyze. That way you can use several > instances to > create multiple regions for triggering different events. I > haven't looked > at this in two years! I'll take a look at the helpfile and see > what's > missing/unclear. > what's the difference between that, and using [pix_crop] and [pix_movement] with [pix_separator] ?
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
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
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
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
-- William Brent www.williambrent.com
"Great minds flock together" Conflations: conversational idiom for the 21st century
www.conflations.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Cool. Otherwise I would suggest the patch that Max posted earlier in this thread using [pix_crop]. The motion detection algorithm is different, but it's built from standard GEM objects.
2010/5/19 Pagano, Patrick pat@digitalworlds.ufl.edu:
found it and that fixed it, sorry brain freeze
From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] On Behalf Of Pagano, Patrick [pat@digitalworlds.ufl.edu] Sent: Wednesday, May 19, 2010 4:58 PM To: William Brent Cc: PD List; IOhannes m zmölnig Subject: Re: [PD] pix_motion_sector
This person does not have the Gem sources, they were interested in the tracking and I was trying to show it quickly. Where is GEM 92.2?
pp
-----Original Message----- From: William Brent [mailto:william.brent@gmail.com] Sent: Wednesday, May 19, 2010 4:54 PM To: Pagano, Patrick Cc: Hans-Christoph Steiner; Jack; PD List; IOhannes m zmölnig Subject: Re: [PD] pix_motion_sector
Are you getting this problem with the pre-compiled binary from my site? That one was built using GEM 0.92.2. If you haven't tried already, download the source and update the first two lines of the makefile to point to your Pd and GEM sources. It builds fine here on OSX 10.5.8, GEM 0.92-2, Pd-0.42-5. The binary works in Pd-ext 0.41-4 as well.
2010/5/19 Pagano, Patrick pat@digitalworlds.ufl.edu:
i would too but i get a GEM error so it seems with this external, I assume it's related to GEM I am on a friends Mac 10.5.8 w/ Pd extended 041.4 and GEM 0.91.3
pp
/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/p/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup
pix_motion_sector ... couldn't create /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookupat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup
pix_motion_sector ... couldn't create /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZNK12GemException6reportEPKc Referenced from: /Users/pat/Library/Pd/pix_motion_sector/pix_motion_sector.pd_darwin Expected in: dynamic lookup ________________________________________ From: pd-list-bounces@iem.at [pd-list-bounces@iem.at] On Behalf Of Hans-Christoph Steiner [hans@at.or.at] Sent: Friday, May 14, 2010 11:43 AM To: Jack Cc: PD List; IOhannes m zmölnig Subject: Re: [PD] pix_motion_sector
I'd love to see an example implementation of this as a patch, if anyone is up for it. A lot of students ask me for this kind of video tracking. It would be good to add to the video tracking examples.
.hc
On May 14, 2010, at 10:11 AM, Jack wrote:
Le vendredi 14 mai 2010 à 06:49 -0700, William Brent a écrit :
I implemented Miller's phase vocoder from the documentation in C and was amazed to see that the CPU load was exactly the same. So much for improving efficiency... But I have seen a big difference for traversing tables and lists. The process of summing the elements in a large table is much faster in an extern than with an [until] loop.
In the case of [pix_motion_sector], what's the easiest way to duplicate the functionality of reporting % of pixels changed in the region? Is there an obvious way to count up the number of pixels that crossed [pix_movement]'s threshold in the cropped region?
[pix_dump] ? Maybe a faster method ? ++
Jack
2010/5/14 IOhannes m zmölnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard <matju@artengine.ca >wrote:
> On Thu, 13 May 2010, William Brent wrote: > > Yes - it's exactly that: an adaptation of pix_movement that lets > you >> specify an area to analyze. That way you can use several >> instances to >> create multiple regions for triggering different events. I >> haven't looked >> at this in two years! I'll take a look at the helpfile and see >> what's >> missing/unclear. >> > what's the difference between that, and using [pix_crop] and > [pix_movement] > with [pix_separator] ? >
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient? particularly if you have many of them?
no not necessarily. the overhead for message communication between objects is usually quite small, compared to the pixel operations.
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
the only speedup you could expect from pix_motion_sector (i haven't looked at the code), is that you wouldn't have to copy the data for cropping at all, but only use the pixels in the ROI.
as for williams argument, that you need less objects, i would suggest looking into abstractions :-) it's definitely less lines of code (at a minimum 10 lines of Pd code) and still only a single object...
mfgasdr IOhannes
best,
J
> _ _ __ ___ _____ ________ _____________ _____________________ ... > | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 > _______________________________________________ > 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvtC0wACgkQkX2Xpv6ydvTVNwCgot+wBAkpacUIHBFR3Fg5OmWV xhAAoITZ7wN077ETVr58rSVE9iunYybB =jYk3 -----END PGP SIGNATURE-----
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
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
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
-- William Brent www.williambrent.com
"Great minds flock together" Conflations: conversational idiom for the 21st century
www.conflations.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2010-05-19 22:53, William Brent wrote:
site? That one was built using GEM 0.92.2. If you haven't tried
is there any reason to use gem-0.92.2? minor releases only fix bugs, so 0.92.3 is (expteced to be) more stable than 0.92.2. to be precise, 0.92.3 fixed a memleak in the tracking code (pix_multiblob though) and a crasher bug.
ghmasdr IOhannes
No, no reason other than that's what I had on my machine when I compiled it :) I should update to 0.92.3 and put up the new version. I'd also like to figure out how to compile this for Linux/Windows. Before Hans bothered to make a makefile, I was just throwing my source into GEM's pixes directory and recompiling GEM as a whole so it would be embedded in the main GEM binary. I'll see if I can change the makefile and get it going on my Linux machine later today. If you don't mind, I may have a couple questions for you off-list if I run into any trouble.
On Thu, May 20, 2010 at 12:02 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2010-05-19 22:53, William Brent wrote:
site? That one was built using GEM 0.92.2. If you haven't tried
is there any reason to use gem-0.92.2? minor releases only fix bugs, so 0.92.3 is (expteced to be) more stable than 0.92.2. to be precise, 0.92.3 fixed a memleak in the tracking code (pix_multiblob though) and a crasher bug.
ghmasdr IOhannes
This for Linux & MS would be nice
pp
-----Original Message----- From: William Brent [mailto:william.brent@gmail.com] Sent: Thursday, May 20, 2010 10:08 AM To: IOhannes m zmoelnig Cc: Pagano, Patrick; Hans-Christoph Steiner; Jack; PD List Subject: Re: [PD] pix_motion_sector
No, no reason other than that's what I had on my machine when I compiled it :) I should update to 0.92.3 and put up the new version. I'd also like to figure out how to compile this for Linux/Windows. Before Hans bothered to make a makefile, I was just throwing my source into GEM's pixes directory and recompiling GEM as a whole so it would be embedded in the main GEM binary. I'll see if I can change the makefile and get it going on my Linux machine later today. If you don't mind, I may have a couple questions for you off-list if I run into any trouble.
On Thu, May 20, 2010 at 12:02 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2010-05-19 22:53, William Brent wrote:
site? That one was built using GEM 0.92.2. If you haven't tried
is there any reason to use gem-0.92.2? minor releases only fix bugs, so 0.92.3 is (expteced to be) more stable than 0.92.2. to be precise, 0.92.3 fixed a memleak in the tracking code (pix_multiblob though) and a crasher bug.
ghmasdr IOhannes
On Fri, 14 May 2010, IOhannes m zmölnig wrote:
you would only need [pix_crop]->[pix_movement] without the [pix_separator] (since the crop will have to allocate a new image anyhow), thus no need for the extra copying of data.
But I'm taking into account the possibility of chaining several [pix_motion_sector], which would generally need access to the same original picture.
I don't know how image allocation works in GEM. Which objects allocate a new picture, and what does that mean in terms of getting access back to the original picture, with or without [pix_separator] ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Thu, 13 May 2010, Jaime Oliver wrote:
Please correct me if I'm wrong, Doesn't having these as externals instead of abstractions, make it significantly faster/efficient?
No, it allows to make it faster, but it doesn't guarantee anything.
particularly if you have many of them?
It's expected that the running time of something is multiplied by N when you do it N times, nothwithstanding any RAM-cache effects and such (if applicable).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Hans-Christoph Steiner -
Husk 00 -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jack -
Jaime Oliver -
Mathieu Bouchard -
Max -
Pagano, Patrick -
William Brent