Hi,
Bug 3191771 renders the combination pix_video+pix_movement useless in Mac OS unless you can lower gem's framerate to ensure it is lower than the camera's framerate (which is not always an option), or unless one finds some other workaround.
The problem is that whenever a new frame from the camera is not available, pix_movement computes the new input frame as a black frame, and hence the resulting difference is almost all-white.
Note that the problem is NOT that pix_movement computes the difference between two identical frames yelding a black frame as a result. It's worse: when the new frame is not available, it seems it considers it as an all-black frame, so the output is the difference between a real frame and a black frame. That causes white flickering, not black flickering.
Does anybody use pix_movement and pix_video on Mac OS? How do you work around this issue?
Ideally I would like to find a simple and easy-to-understand solution, because I am teaching a Pd course and I'd like to give the students (most of whom use Mac) a workaround they can understand.
Thank you in advance m.
hello,
i don't work on osX, so things are working for me.
but did you try pix_delay / pix_diff ?
anyway, i usually do every pix_* things in shader, as it is usually faster and more flexible. (it's faster, even if you have to use pix_snap)
c
Le 05/04/2011 13:53, Matteo Sisti Sette a écrit :
Hi,
Bug 3191771 renders the combination pix_video+pix_movement useless in Mac OS unless you can lower gem's framerate to ensure it is lower than the camera's framerate (which is not always an option), or unless one finds some other workaround.
The problem is that whenever a new frame from the camera is not available, pix_movement computes the new input frame as a black frame, and hence the resulting difference is almost all-white.
Note that the problem is NOT that pix_movement computes the difference between two identical frames yelding a black frame as a result. It's worse: when the new frame is not available, it seems it considers it as an all-black frame, so the output is the difference between a real frame and a black frame. That causes white flickering, not black flickering.
Does anybody use pix_movement and pix_video on Mac OS? How do you work around this issue?
Ideally I would like to find a simple and easy-to-understand solution, because I am teaching a Pd course and I'd like to give the students (most of whom use Mac) a workaround they can understand.
Thank you in advance m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello,
I don't work neither on Mac, but what about [pix_movement2], same pb ?
++Benjamin
cyrille henry a écrit :
hello,
i don't work on osX, so things are working for me.
but did you try pix_delay / pix_diff ?
anyway, i usually do every pix_* things in shader, as it is usually faster and more flexible. (it's faster, even if you have to use pix_snap)
c
Le 05/04/2011 13:53, Matteo Sisti Sette a écrit :
Hi,
Bug 3191771 renders the combination pix_video+pix_movement useless in Mac OS unless you can lower gem's framerate to ensure it is lower than the camera's framerate (which is not always an option), or unless one finds some other workaround.
The problem is that whenever a new frame from the camera is not available, pix_movement computes the new input frame as a black frame, and hence the resulting difference is almost all-white.
Note that the problem is NOT that pix_movement computes the difference between two identical frames yelding a black frame as a result. It's worse: when the new frame is not available, it seems it considers it as an all-black frame, so the output is the difference between a real frame and a black frame. That causes white flickering, not black flickering.
Does anybody use pix_movement and pix_video on Mac OS? How do you work around this issue?
Ideally I would like to find a simple and easy-to-understand solution, because I am teaching a Pd course and I'd like to give the students (most of whom use Mac) a workaround they can understand.
Thank you in advance m.
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
I used pix_movement and blob for basic motion detection for years. I gated the video signal so it would only output every half second or second because it is usually counter-productive to have 25 or 30 updates a second for this task.
As to your problem, it might come from how your device/driver reports (or doesn't report) new frames. Try setting the GEM framerate to the advertised frame rate of your device and see if that helps. Note, that lots of webcams claim 30fps, but only deliver 15fps or less.
On Tue, Apr 5, 2011 at 7:53 AM, Matteo Sisti Sette < matteosistisette@gmail.com> wrote:
Hi,
Bug 3191771 renders the combination pix_video+pix_movement useless in Mac OS unless you can lower gem's framerate to ensure it is lower than the camera's framerate (which is not always an option), or unless one finds some other workaround.
The problem is that whenever a new frame from the camera is not available, pix_movement computes the new input frame as a black frame, and hence the resulting difference is almost all-white.
Note that the problem is NOT that pix_movement computes the difference between two identical frames yelding a black frame as a result. It's worse: when the new frame is not available, it seems it considers it as an all-black frame, so the output is the difference between a real frame and a black frame. That causes white flickering, not black flickering.
Does anybody use pix_movement and pix_video on Mac OS? How do you work around this issue?
Ideally I would like to find a simple and easy-to-understand solution, because I am teaching a Pd course and I'd like to give the students (most of whom use Mac) a workaround they can understand.
Thank you in advance m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 04/05/2011 04:33 PM, chris clepper wrote:
I used pix_movement and blob for basic motion detection for years. I gated the video signal so it would only output every half second or second
How do you gate the video signal? That may be exactly the workaround I need
Try setting the GEM framerate to the advertised frame rate of your device and see if that helps.
Yes it does help, it fixes the problem completely. But that is not an option if i need to produce graphical output at a higher framerate. It's ok to detect the movement at a rate equal to or lower than the camera frame rate, but i can't lower the whole gem framerate because that will affect video output.
Ah. You are running at 60 fps? You can do a simple toggle to only render the video every other frame using a simple [spigot] and counter. Just setting a simple motion or not state is best done at a much lower rate otherwise you have to filter the results anyway.
On Tue, Apr 5, 2011 at 10:47 AM, Matteo Sisti Sette < matteosistisette@gmail.com> wrote:
On 04/05/2011 04:33 PM, chris clepper wrote:
I used pix_movement and blob for basic motion detection for years. I gated the video signal so it would only output every half second or second
How do you gate the video signal? That may be exactly the workaround I need
Try setting the GEM framerate to the
advertised frame rate of your device and see if that helps.
Yes it does help, it fixes the problem completely. But that is not an option if i need to produce graphical output at a higher framerate. It's ok to detect the movement at a rate equal to or lower than the camera frame rate, but i can't lower the whole gem framerate because that will affect video output.
depending on the aplication, it can help to separate the tracking and the rendering on 2 diferents process (2 diferent pd). (most computer have multiple processor now)
to slow a gemhead, you can stop it (sending it 0) and then send it bangs with a metronome. if you don't use it for rendering it should work...
c
Le 05/04/2011 16:47, Matteo Sisti Sette a écrit :
On 04/05/2011 04:33 PM, chris clepper wrote:
I used pix_movement and blob for basic motion detection for years. I gated the video signal so it would only output every half second or second
How do you gate the video signal? That may be exactly the workaround I need
Try setting the GEM framerate to the advertised frame rate of your device and see if that helps.
Yes it does help, it fixes the problem completely. But that is not an option if i need to produce graphical output at a higher framerate. It's ok to detect the movement at a rate equal to or lower than the camera frame rate, but i can't lower the whole gem framerate because that will affect video output.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thank you a lot guys!
Thanks to your suggestions, this seems to be the solution (see attached patch). I have to try it on Mac though, to see if it really fixes the issue (hard to predict since the issue itself is pretty strange), but I expect it to.
I didn't expect the spigoting-the-gemhead-trick to work: I thought that having pix_movement receive the gemlist only some of the times a frame was rendered would cause strange interactions.
The pix_texture-right-inlet-trick even allows me to monitor the movement signal which is great.
On 04/05/2011 05:03 PM, cyrille henry wrote:
depending on the aplication, it can help to separate the tracking and the rendering on 2 diferents process (2 diferent pd). (most computer have multiple processor now)
to slow a gemhead, you can stop it (sending it 0) and then send it bangs with a metronome. if you don't use it for rendering it should work...
c
Le 05/04/2011 16:47, Matteo Sisti Sette a écrit :
On 04/05/2011 04:33 PM, chris clepper wrote:
I used pix_movement and blob for basic motion detection for years. I gated the video signal so it would only output every half second or second
How do you gate the video signal? That may be exactly the workaround I need
Try setting the GEM framerate to the advertised frame rate of your device and see if that helps.
Yes it does help, it fixes the problem completely. But that is not an option if i need to produce graphical output at a higher framerate. It's ok to detect the movement at a rate equal to or lower than the camera frame rate, but i can't lower the whole gem framerate because that will affect video output.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 5 Apr 2011, Matteo Sisti Sette wrote:
Thanks to your suggestions, this seems to be the solution (see attached patch). I have to try it on Mac though, to see if it really fixes the issue (hard to predict since the issue itself is pretty strange), but I expect it to.
Ah, btw, you can do the whole counter spigot thing using :
[shunt 3, mode 1]
which cycles through three outputs going forward automatically at every message.
http://gridflow.ca/help/shunt-help.html
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Thank you, I appreciate your suggestions involving the use of gridflow, but for the moment, since gridflow is not included in Pd Extended (btw, why isn't it?), I am a bit reluctant to have my students download and install it just to use it marginally... to which you may object, then have them use it extensively, but then the hours of the course are limited and I have to prioritize things :) not to mention I'm not familiar with gridflow myself in the first place.
By the way I'm sesing GridFlow is available for Windows... it wasn't until recently, was it? Are the differences among platform (e.g. things that are only supported on a given platform, or things that work in a different way) reasonably small?
thanks m.
On 04/05/2011 06:16 PM, Mathieu Bouchard wrote:
On Tue, 5 Apr 2011, Matteo Sisti Sette wrote:
Thanks to your suggestions, this seems to be the solution (see attached patch). I have to try it on Mac though, to see if it really fixes the issue (hard to predict since the issue itself is pretty strange), but I expect it to.
Ah, btw, you can do the whole counter spigot thing using :
[shunt 3, mode 1]
which cycles through three outputs going forward automatically at every message.
http://gridflow.ca/help/shunt-help.html
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, 5 Apr 2011, Matteo Sisti Sette wrote:
I am a bit reluctant to have my students download and install it just to use it marginally...
How about using it a lot ? Have you seen this ?
http://gridflow.ca/gallery/sequenceur.pd.png http://gridflow.ca/gallery/sequenceur.pd.mp3
By the way I'm sesing GridFlow is available for Windows... it wasn't until recently, was it?
It has been available, then not available, then available again.
Are the differences among platform (e.g. things that are only supported on a given platform, or things that work in a different way) reasonably small?
It depends on which features you use. No-one really uses everything. I have taken a lot of steps to make things cross-platform, but a bunch of things are still missing, and in the case of Windows, it's especially GEM support and camera support. But if you do music only, you don't need those.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, 5 Apr 2011, Matteo Sisti Sette wrote:
Bug 3191771 renders the combination pix_video+pix_movement useless in Mac OS unless you can lower gem's framerate to ensure it is lower than the camera's framerate (which is not always an option), or unless one finds some other workaround.
You can use [gemdead] (from GridFlow) together with Gem objects, to do pix-stuff that is controlled completely by a [metro] of your choice (and thus is not related to the [gemwin]). Then you can integrate it into [gemwin]-related chains by sending it to the right inlet of a pix-object.
But I've never tried.
http://gridflow.ca/help/gemdead-help.html
(I've only used this with [#from_pix], but it's not limited to that.)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC