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 <zmoel...@iem.at>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jaime Oliver wrote:
On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard <ma...@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
