[PD] pix_motion_sector

William Brent william.brent at gmail.com
Sat May 15 02:50:13 CEST 2010


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 at 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 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
>



-- 
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