[PD] pix_motion_sector

[Jack]

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 at iem.at>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Jaime Oliver wrote:
> >> On Thu, May 13, 2010 at 7:40 PM, Mathieu Bouchard <matju at 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 at iem.at mailing list
> >>> UNSUBSCRIBE and account-management ->
> >>> http://lists.puredata.info/listinfo/pd-list
> >>>
> >>>
> >>
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Pd-list at 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 at iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >
> 
> 
>