[PD] Gem image analysis
chris clepper
cgc at humboldtblvd.com
Tue May 31 15:22:44 CEST 2005
On May 31, 2005, at 2:07 AM, IOhannes m zmoelnig wrote:
>> The last outlet is for the Z axis and, as near as I can tell, the code
> whatever "Z" means.
> it definitely knows nothing about the z-axis in a 3dimensional space.
The variable is labeled m_zOut throughout the source code. It sure
looks like an attempt to map magnitude of the image brightness to the Z
axis to me, but then again I didn't write the thing.
>> measures how bright the image is by dividing the sum of all of the
>> selected channels by the maximum possible sum for the image. So if
>> the
>> image was entirely white (R,G,B all = 255) it would give a 1.0 and a
>> black image would be 0.0.
>
>
> so the last outlet is a measure of the size of the blob.
> if you use [pix_movement] to convert motion (== change of data in a
> series of images) into an image (the difference between the sequence of
> images), then the blob-size is a measure of the amount of movement
> (between to subsequent images).
>
> so the blobsize is somewhat like the overall "brightness" of the blob.
I wasn't trying to contradict anything, but rather explain how the
object came up with that value. It's sometimes helpful to know that
sort of thing.
> using [pix_background] instead of [pix_movement] _could_ produce better
> results, but i think this really depends on your set up.
> if you are not sure, experiment with both and see what gives better
> results
pix_background would come before pix_movement and strip away data which
could potentially cause false triggers.
> well, if he does "NOT want to TRACK anything" but just detect if there
> is any movement in the image, your suggestion seems to be a bit
> overpowered (nonetheless it should work fine)
pix_movement + pix_blob give me enough false values that I recommend
using additional analysis to give more consistent results. That's all.
Sorry if that wasn't made clear from the start.
cgc
More information about the Pd-list
mailing list