hi list,
how do i turn a camera in a motion sensor? i can extract the movement with pix_movement, that's clear. but how to get a numeric value out of the whole picture corresponding to the pictures grayscale value? (not from a single pixel like pix_data supplies)
am i completely overseeing something?
max
Max Neupert wrote:
hi list,
how do i turn a camera in a motion sensor? i can extract the movement with pix_movement, that's clear. but how to get a numeric value out of the whole picture corresponding to the pictures grayscale value? (not from a single pixel like pix_data supplies)
am i completely overseeing something?
yes: [pix_blob] does blob-detection (only 1 single blob though) there should be an example-patch on how to do movement-detection with this: 04.video/03.movement_detection.pd
if using the CVS is an option for you, there is [pix_multiblob] which is far better (detects multiple blobs, gives more information on them)
there is even an abstraction (with example-patch) for blob-tracking.
mfg.ad.sr IOhannes
max
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi IOhannes, thomas, list
sorry for beeing unclear, pix_blob seems already too intelligent for what i need. i do NOT want to TRACK anything. i just want to know if there is ANY motion in the image and not where. so again: it's not about tracking it is about movement. my approch was to use pix_movement because it provides the first step in the analysis: removing everything what stays. but how to “measure” the white areas after without tracking them? i am not interested in the coordinates of blobs.
max
Am 30.05.2005 um 17:09 schrieb IOhannes m zmoelnig:
Max Neupert wrote:
hi list, how do i turn a camera in a motion sensor? i can extract the movement with pix_movement, that's clear. but how to get a numeric value out of the whole picture corresponding to the pictures grayscale value? (not from a single pixel like pix_data supplies) am i completely overseeing something?
yes: [pix_blob] does blob-detection (only 1 single blob though) there should be an example-patch on how to do movement-detection with this: 04.video/03.movement_detection.pd
if using the CVS is an option for you, there is [pix_multiblob] which is far better (detects multiple blobs, gives more information on them)
there is even an abstraction (with example-patch) for blob-tracking.
mfg.ad.sr IOhannes
max _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Max
How about measuring the change in the pix_blob output? If if changes more than a certain threshold amount that would normally be a sign of some new action in the frame. You could also detect the edges of the frame for objects entering view. A table with the past few frames might help smooth things out and improve accuracy as well.
cgc
On May 30, 2005, at 6:22 PM, Max Neupert wrote:
hi IOhannes, thomas, list
sorry for beeing unclear, pix_blob seems already too intelligent for what i need. i do NOT want to TRACK anything. i just want to know if there is ANY motion in the image and not where. so again: it's not about tracking it is about movement. my approch was to use pix_movement because it provides the first step in the analysis: removing everything what stays. but how to “measure” the white areas after without tracking them? i am not interested in the coordinates of blobs.
max
Am 30.05.2005 um 17:09 schrieb IOhannes m zmoelnig:
Max Neupert wrote:
hi list, how do i turn a camera in a motion sensor? i can extract the movement with pix_movement, that's clear. but how to get a numeric value out of the whole picture corresponding to the pictures grayscale value? (not from a single pixel like pix_data supplies) am i completely overseeing something?
yes: [pix_blob] does blob-detection (only 1 single blob though) there should be an example-patch on how to do movement-detection with this: 04.video/03.movement_detection.pd
if using the CVS is an option for you, there is [pix_multiblob] which is far better (detects multiple blobs, gives more information on them)
there is even an abstraction (with example-patch) for blob-tracking.
mfg.ad.sr IOhannes
max _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Again:
Use pix_movement. Analyse with [pix_blob 4] (alpha channel) The last outlet of pix_blob gives you the amount of movement in the image.
Tm
On 5/30/05, chris clepper cgc@humboldtblvd.com wrote:
Max
How about measuring the change in the pix_blob output? If if changes more than a certain threshold amount that would normally be a sign of some new action in the frame. You could also detect the edges of the frame for objects entering view. A table with the past few frames might help smooth things out and improve accuracy as well.
cgc
On May 30, 2005, at 6:22 PM, Max Neupert wrote:
hi IOhannes, thomas, list
sorry for beeing unclear, pix_blob seems already too intelligent for what i need. i do NOT want to TRACK anything. i just want to know if there is ANY motion in the image and not where. so again: it's not about tracking it is about movement. my approch was to use pix_movement because it provides the first step in the analysis: removing everything what stays. but how to "measure" the white areas after without tracking them? i am not interested in the coordinates of blobs.
max
Am 30.05.2005 um 17:09 schrieb IOhannes m zmoelnig:
Max Neupert wrote:
hi list, how do i turn a camera in a motion sensor? i can extract the movement with pix_movement, that's clear. but how to get a numeric value out of the whole picture corresponding to the pictures grayscale value? (not from a single pixel like pix_data supplies) am i completely overseeing something?
yes: [pix_blob] does blob-detection (only 1 single blob though) there should be an example-patch on how to do movement-detection with this: 04.video/03.movement_detection.pd
if using the CVS is an option for you, there is [pix_multiblob] which is far better (detects multiple blobs, gives more information on them)
there is even an abstraction (with example-patch) for blob-tracking.
mfg.ad.sr IOhannes
max _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On May 30, 2005, at 9:34 PM, Thomas Ouellet Fredericks wrote:
Again:
Use pix_movement. Analyse with [pix_blob 4] (alpha channel) The last outlet of pix_blob gives you the amount of movement in the image.
The last outlet is for the Z axis and, as near as I can tell, the code 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.
My method to measure change over time or from a reference image would act as a trigger, which is I believe what Max wants to do.
cgc
Actually, I should make it clear that method does work, but
pix_movement doesn't really have a lot of control over the trigger.
Some sort of frame averaging and possibly pix_background would help cut
down on false triggers.
cgc
On May 31, 2005, at 1:00 AM, chris clepper wrote:
On May 30, 2005, at 9:34 PM, Thomas Ouellet Fredericks wrote:
Again:
Use pix_movement. Analyse with [pix_blob 4] (alpha channel) The last outlet of pix_blob gives you the amount of movement in the image.
chris clepper wrote:
On May 30, 2005, at 9:34 PM, Thomas Ouellet Fredericks wrote:
Again:
Use pix_movement. Analyse with [pix_blob 4] (alpha channel) The last outlet of pix_blob gives you the amount of movement in the image.
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.
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.
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.
My method to measure change over time or from a reference image would act as a trigger, which is I believe what Max wants to do.
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)
mfg.cas.dr IOhannes
cgc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
thanks IOhannes, now i've got it.
Am 31.05.2005 um 09:07 schrieb IOhannes m zmoelnig:
chris clepper wrote:
On May 30, 2005, at 9:34 PM, Thomas Ouellet Fredericks wrote:
Again:
Use pix_movement. Analyse with [pix_blob 4] (alpha channel) The last outlet of pix_blob gives you the amount of movement in the image.
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.
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.
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.
My method to measure change over time or from a reference image would act as a trigger, which is I believe what Max wants to do.
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)
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
chris clepper wrote:
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.
but i did ;-) don't know why i named it m_zOut though (i guess, because there was m_x and m_z and "z" seemed to be the natural 3rd variable)
I wasn't trying to contradict anything, but rather explain how the
i didn't feel you where contradicting anything. sorry if i appeared to react that way.
object came up with that value. It's sometimes helpful to know that sort of thing.
right and i am very thankful for the explanation. i just thought that i should give my 2% too.
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.
which sounds totally reasonable to me.
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.
right. now it's me who didn't want to contradict anything.
all the best IOhannes
Hiya,
I get you now.
If you ignore the "position" of the centroid, then the "size" of the blob will tell you how much motion is in the whole image. "size" is the right-most outlet of pix_blob
B.
Max Neupert wrote:
hi IOhannes, thomas, list
sorry for beeing unclear, pix_blob seems already too intelligent for what i need. i do NOT want to TRACK anything. i just want to know if there is ANY motion in the image and not where. so again: it's not about tracking it is about movement. my approch was to use pix_movement because it provides the first step in the analysis: removing everything what stays. but how to “measure” the white areas after without tracking them? i am not interested in the coordinates of blobs.
max
Am 30.05.2005 um 17:09 schrieb IOhannes m zmoelnig:
Max Neupert wrote:
hi list, how do i turn a camera in a motion sensor? i can extract the movement with pix_movement, that's clear. but how to get a numeric value out of the whole picture corresponding to the pictures grayscale value? (not from a single pixel like pix_data supplies) am i completely overseeing something?
yes: [pix_blob] does blob-detection (only 1 single blob though) there should be an example-patch on how to do movement-detection with this: 04.video/03.movement_detection.pd
if using the CVS is an option for you, there is [pix_multiblob] which is far better (detects multiple blobs, gives more information on them)
there is even an abstraction (with example-patch) for blob-tracking.
mfg.ad.sr IOhannes
max _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
B. Bogart -
chris clepper -
IOhannes m zmoelnig -
Max Neupert -
Thomas Ouellet Fredericks