[PD] pix_motion_sector

William Brent william.brent at gmail.com
Wed May 19 23:08:05 CEST 2010 

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 at digitalworlds.ufl.edu>:
> found it and that fixed it,
> sorry brain freeze
>
> ________________________________________
> From: pd-list-bounces at iem.at [pd-list-bounces at iem.at] On Behalf Of Pagano, Patrick [pat at 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 at 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 at 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 at iem.at [pd-list-bounces at iem.at] On Behalf Of Hans-Christoph Steiner [hans at 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 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
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
> --
> William Brent
> www.williambrent.com
>
> "Great minds flock together"
> Conflations: conversational idiom for the 21st century
>
> www.conflations.com
>
> _______________________________________________
> Pd-list at 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

More information about the Pd-list mailing list