[PD] pix_motion_sector

William Brent william.brent at gmail.com
Fri May 14 18:27:44 CEST 2010


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 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 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
>>>>
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Pd-list at 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




More information about the Pd-list mailing list