hi list, a student of mine, Jakob Gomoll, did solve how to track multiple blobs while every blob keeps its ID. Here is where i scratch my head: It works fine until you render the output of the multiblob tracker to a rectangle. I'd like to understand why this is.
Is it a bug or a feature? connect the tracker to the pix_texture (where the red line is) and it will mess up the result:
Le 26/05/2013 20:56, Max a écrit :
hi list, a student of mine, Jakob Gomoll, did solve how to track multiple blobs while every blob keeps its ID. Here is where i scratch my head: It works fine until you render the output of the multiblob tracker to a rectangle. I'd like to understand why this is.
Is it a bug or a feature? connect the tracker to the pix_texture (where the red line is) and it will mess up the result:
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello Max, This could be interesting for you : http://www.mail-archive.com/pd-list@iem.at/msg42343.html ++
Jack
Am 27.05.2013 um 01:00 schrieb Jack jack@rybn.org:
Le 26/05/2013 20:56, Max a écrit :
hi list, a student of mine, Jakob Gomoll, did solve how to track multiple blobs while every blob keeps its ID. Here is where i scratch my head: It works fine until you render the output of the multiblob tracker to a rectangle. I'd like to understand why this is.
Is it a bug or a feature? connect the tracker to the pix_texture (where the red line is) and it will mess up the result:
Hello Max, This could be interesting for you : http://www.mail-archive.com/pd-list@iem.at/msg42343.html
Thanks Jack, I know – I have posted on this thread too. We solved this problem differently. Because our application was microscopy and we had specimen who were stopping their movement for a while before moving on, the continuity approach wasn't working. Since we based the blob detection on frame differences [pix_movement] rather than background subtraction from a reference frame [pix_background] blobs who were resting for a few frames simply disappeared and got a new ID assigned. Our approach is to set a time-out after we declare a blob dead. If it starts moving in the same region (size is settable too) again before the time-out, we pick up the old ID. So rather than using movement vectors as reference we used proximity. All data is stored in tables.
The patch works beautifully without any externals. Have you tried?
So this problem is already solved - my question was rather a Gem thing: why does is stop working when I want to render the image behind it? Do you know this?
Max
Le 27/05/2013 01:26, Max a écrit :
Am 27.05.2013 um 01:00 schrieb Jack jack@rybn.org:
Le 26/05/2013 20:56, Max a écrit :
hi list, a student of mine, Jakob Gomoll, did solve how to track multiple blobs while every blob keeps its ID. Here is where i scratch my head: It works fine until you render the output of the multiblob tracker to a rectangle. I'd like to understand why this is.
Is it a bug or a feature? connect the tracker to the pix_texture (where the red line is) and it will mess up the result:
Hello Max, This could be interesting for you : http://www.mail-archive.com/pd-list@iem.at/msg42343.html
Thanks Jack, I know – I have posted on this thread too. We solved this problem differently. Because our application was microscopy and we had specimen who were stopping their movement for a while before moving on, the continuity approach wasn't working. Since we based the blob detection on frame differences [pix_movement] rather than background subtraction from a reference frame [pix_background] blobs who were resting for a few frames simply disappeared and got a new ID assigned. Our approach is to set a time-out after we declare a blob dead. If it starts moving in the same region (size is settable too) again before the time-out, we pick up the old ID. So rather than using movement vectors as reference we used proximity. All data is stored in tables.
The patch works beautifully without any externals. Have you tried?
So this problem is already solved - my question was rather a Gem thing: why does is stop working when I want to render the image behind it? Do you know this?
Max
Sorry, i didn't see your patch in your previous post. If I try to open it, i get : arraysize blob_ids ... couldn't create
What is [arraysize] ? ++
Jack
Am 27.05.2013 um 02:24 schrieb Jack jack@rybn.org:
Le 27/05/2013 01:26, Max a écrit :
Am 27.05.2013 um 01:00 schrieb Jack jack@rybn.org:
Le 26/05/2013 20:56, Max a écrit :
hi list, a student of mine, Jakob Gomoll, did solve how to track multiple blobs while every blob keeps its ID. Here is where i scratch my head: It works fine until you render the output of the multiblob tracker to a rectangle. I'd like to understand why this is.
Is it a bug or a feature? connect the tracker to the pix_texture (where the red line is) and it will mess up the result:
Hello Max, This could be interesting for you : http://www.mail-archive.com/pd-list@iem.at/msg42343.html
Thanks Jack, I know – I have posted on this thread too. We solved this problem differently. Because our application was microscopy and we had specimen who were stopping their movement for a while before moving on, the continuity approach wasn't working. Since we based the blob detection on frame differences [pix_movement] rather than background subtraction from a reference frame [pix_background] blobs who were resting for a few frames simply disappeared and got a new ID assigned. Our approach is to set a time-out after we declare a blob dead. If it starts moving in the same region (size is settable too) again before the time-out, we pick up the old ID. So rather than using movement vectors as reference we used proximity. All data is stored in tables.
The patch works beautifully without any externals. Have you tried?
So this problem is already solved - my question was rather a Gem thing: why does is stop working when I want to render the image behind it? Do you know this?
Max
Sorry, i didn't see your patch in your previous post. If I try to open it, i get : arraysize blob_ids ... couldn't create
What is [arraysize] ?
oh, darn - seems it isn't completely vanilla then. it is an external by Juha Vehviläinen http://puredata.info/downloads/arraysize
Le 27/05/2013 02:32, Max a écrit :
Am 27.05.2013 um 02:24 schrieb Jack jack@rybn.org:
Le 27/05/2013 01:26, Max a écrit :
Am 27.05.2013 um 01:00 schrieb Jack jack@rybn.org:
Le 26/05/2013 20:56, Max a écrit :
hi list, a student of mine, Jakob Gomoll, did solve how to track multiple blobs while every blob keeps its ID. Here is where i scratch my head: It works fine until you render the output of the multiblob tracker to a rectangle. I'd like to understand why this is.
Is it a bug or a feature? connect the tracker to the pix_texture (where the red line is) and it will mess up the result:
Hello Max, This could be interesting for you : http://www.mail-archive.com/pd-list@iem.at/msg42343.html
Thanks Jack, I know – I have posted on this thread too. We solved this problem differently. Because our application was microscopy and we had specimen who were stopping their movement for a while before moving on, the continuity approach wasn't working. Since we based the blob detection on frame differences [pix_movement] rather than background subtraction from a reference frame [pix_background] blobs who were resting for a few frames simply disappeared and got a new ID assigned. Our approach is to set a time-out after we declare a blob dead. If it starts moving in the same region (size is settable too) again before the time-out, we pick up the old ID. So rather than using movement vectors as reference we used proximity. All data is stored in tables.
The patch works beautifully without any externals. Have you tried?
So this problem is already solved - my question was rather a Gem thing: why does is stop working when I want to render the image behind it? Do you know this?
Max
Sorry, i didn't see your patch in your previous post. If I try to open it, i get : arraysize blob_ids ... couldn't create
What is [arraysize] ?
oh, darn - seems it isn't completely vanilla then. it is an external by Juha Vehviläinen http://puredata.info/downloads/arraysize
Ah ok, maybe with [expr size("table_name")]. About the problem : you need to render the [rectangle] before "draw_blobs". See the patch attached... ++
Jack
Am 27.05.2013 um 02:57 schrieb Jack jack@rybn.org:
Le 27/05/2013 02:32, Max a écrit :
Am 27.05.2013 um 02:24 schrieb Jack jack@rybn.org:
Le 27/05/2013 01:26, Max a écrit :
Am 27.05.2013 um 01:00 schrieb Jack jack@rybn.org:
Le 26/05/2013 20:56, Max a écrit :
hi list, a student of mine, Jakob Gomoll, did solve how to track multiple blobs while every blob keeps its ID. Here is where i scratch my head: It works fine until you render the output of the multiblob tracker to a rectangle. I'd like to understand why this is.
Is it a bug or a feature? connect the tracker to the pix_texture (where the red line is) and it will mess up the result:
Hello Max, This could be interesting for you : http://www.mail-archive.com/pd-list@iem.at/msg42343.html
Thanks Jack, I know – I have posted on this thread too. We solved this problem differently. Because our application was microscopy and we had specimen who were stopping their movement for a while before moving on, the continuity approach wasn't working. Since we based the blob detection on frame differences [pix_movement] rather than background subtraction from a reference frame [pix_background] blobs who were resting for a few frames simply disappeared and got a new ID assigned. Our approach is to set a time-out after we declare a blob dead. If it starts moving in the same region (size is settable too) again before the time-out, we pick up the old ID. So rather than using movement vectors as reference we used proximity. All data is stored in tables.
The patch works beautifully without any externals. Have you tried?
So this problem is already solved - my question was rather a Gem thing: why does is stop working when I want to render the image behind it? Do you know this?
Max
Sorry, i didn't see your patch in your previous post. If I try to open it, i get : arraysize blob_ids ... couldn't create
What is [arraysize] ?
oh, darn - seems it isn't completely vanilla then. it is an external by Juha Vehviläinen http://puredata.info/downloads/arraysize
Ah ok, maybe with [expr size("table_name")]. About the problem : you need to render the [rectangle] before "draw_blobs". See the patch attached…
thank you jack (but still scratching my head why exactly that is, will revisit tomorrow). updated here: https://github.com/mxa/Bewegungsmelder
Le 27/05/2013 04:10, Max a écrit :
Am 27.05.2013 um 02:57 schrieb Jack jack@rybn.org:
Le 27/05/2013 02:32, Max a écrit :
Am 27.05.2013 um 02:24 schrieb Jack jack@rybn.org:
Le 27/05/2013 01:26, Max a écrit :
Am 27.05.2013 um 01:00 schrieb Jack jack@rybn.org:
Le 26/05/2013 20:56, Max a écrit : > hi list, a student of mine, Jakob Gomoll, did solve how to track multiple blobs while every blob keeps its ID. > Here is where i scratch my head: It works fine until you render the output of the multiblob tracker to a rectangle. > I'd like to understand why this is. > > Is it a bug or a feature? > connect the tracker to the pix_texture (where the red line is) and it will mess up the result: > Hello Max, This could be interesting for you : http://www.mail-archive.com/pd-list@iem.at/msg42343.html
Thanks Jack, I know – I have posted on this thread too. We solved this problem differently. Because our application was microscopy and we had specimen who were stopping their movement for a while before moving on, the continuity approach wasn't working. Since we based the blob detection on frame differences [pix_movement] rather than background subtraction from a reference frame [pix_background] blobs who were resting for a few frames simply disappeared and got a new ID assigned. Our approach is to set a time-out after we declare a blob dead. If it starts moving in the same region (size is settable too) again before the time-out, we pick up the old ID. So rather than using movement vectors as reference we used proximity. All data is stored in tables.
The patch works beautifully without any externals. Have you tried?
So this problem is already solved - my question was rather a Gem thing: why does is stop working when I want to render the image behind it? Do you know this?
Max
Sorry, i didn't see your patch in your previous post. If I try to open it, i get : arraysize blob_ids ... couldn't create
What is [arraysize] ?
oh, darn - seems it isn't completely vanilla then. it is an external by Juha Vehviläinen http://puredata.info/downloads/arraysize
Ah ok, maybe with [expr size("table_name")]. About the problem : you need to render the [rectangle] before "draw_blobs". See the patch attached…
thank you jack (but still scratching my head why exactly that is, will revisit tomorrow). updated here: https://github.com/mxa/Bewegungsmelder
Hello Max,
In your patch, you need to put the crosses "on" the rectangle showing movement. These crosses and rectangle are in the same plan. Therefore, you need to render, first, the rectangle and after the crosses. Inside the subpatch "draw_blob", you have a [gemhead 90], which one is banged each time it has a cross to render. But, this [gemhead 90] is rendered many times (or not) during your main [gemhead] (in the main windows). If you open the subpatch "draw_blob", you can see that i add a [loadbang] and a [0 ( to stop the render of [gemhead 90] each frame, because the render is forced (many times or not) by a bang from the main [gemhead] and because you needn't to render this [gemhead 90] during the 'normal' render cycle. You can easily replace [gemhead 90] with [gemhead 10] and get exactly the same result. If you want, it should be possible to replace this [gemhead 90] with a [gemlist]. Hope the explanations are clear. I give here a small example to understand. ++
Jack
hi all,
thanks Max for sharing your (very good) work !
I have a strange behavior here, some cross appear in the middle of nowhere... but the blobs are keeping their ID well
did you tried pix_opencv_blobtrack ? it's a work in progress and I know the parameters are quiet opaque but I didn't find any documentation about the blobtracker modules in OpenCV... nevertheless, it works quite good I attached a pix_opencv_blobtrack based patch it doesn't work exactly the same as yours but it keeps the IDs
the main thing is to make the foreground detection module to not update to quickly to keep static blob ID
i've packed an Ubuntu 64 bit binary with
cheers
antoine
-- do it yourself http://antoine.villeret.free.fr
2013/5/27 Jack jack@rybn.org
Le 27/05/2013 04:10, Max a écrit :
Am 27.05.2013 um 02:57 schrieb Jack jack@rybn.org:
Le 27/05/2013 02:32, Max a écrit :
Am 27.05.2013 um 02:24 schrieb Jack jack@rybn.org:
Le 27/05/2013 01:26, Max a écrit :
Am 27.05.2013 um 01:00 schrieb Jack jack@rybn.org: > Le 26/05/2013 20:56, Max a écrit : >> hi list, a student of mine, Jakob Gomoll, did solve how to track
multiple blobs while every blob keeps its ID.
>> Here is where i scratch my head: It works fine until you render
the output of the multiblob tracker to a rectangle.
>> I'd like to understand why this is. >> >> Is it a bug or a feature? >> connect the tracker to the pix_texture (where the red line is) and
it will mess up the result:
>> > Hello Max, > This could be interesting for you : > http://www.mail-archive.com/pd-list@iem.at/msg42343.html Thanks Jack, I know – I have posted on this thread too. We solved this problem
differently. Because our application was microscopy and we had specimen who were stopping their movement for a while before moving on, the continuity approach wasn't working. Since we based the blob detection on frame differences [pix_movement] rather than background subtraction from a reference frame [pix_background] blobs who were resting for a few frames simply disappeared and got a new ID assigned.
Our approach is to set a time-out after we declare a blob dead. If
it starts moving in the same region (size is settable too) again before the time-out, we pick up the old ID. So rather than using movement vectors as reference we used proximity. All data is stored in tables.
The patch works beautifully without any externals. Have you tried?
So this problem is already solved - my question was rather a Gem
thing: why does is stop working when I want to render the image behind it? Do you know this?
Max
Sorry, i didn't see your patch in your previous post. If I try to open it, i get : arraysize blob_ids ... couldn't create
What is [arraysize] ?
oh, darn - seems it isn't completely vanilla then. it is an external
by Juha Vehviläinen
Ah ok, maybe with [expr size("table_name")]. About the problem : you need to render the [rectangle] before
"draw_blobs".
See the patch attached…
thank you jack (but still scratching my head why exactly that is, will
revisit tomorrow).
updated here: https://github.com/mxa/Bewegungsmelder
Hello Max,
In your patch, you need to put the crosses "on" the rectangle showing movement. These crosses and rectangle are in the same plan. Therefore, you need to render, first, the rectangle and after the crosses. Inside the subpatch "draw_blob", you have a [gemhead 90], which one is banged each time it has a cross to render. But, this [gemhead 90] is rendered many times (or not) during your main [gemhead] (in the main windows). If you open the subpatch "draw_blob", you can see that i add a [loadbang] and a [0 ( to stop the render of [gemhead 90] each frame, because the render is forced (many times or not) by a bang from the main [gemhead] and because you needn't to render this [gemhead 90] during the 'normal' render cycle. You can easily replace [gemhead 90] with [gemhead 10] and get exactly the same result. If you want, it should be possible to replace this [gemhead 90] with a [gemlist]. Hope the explanations are clear. I give here a small example to understand. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Am 27.05.2013 um 20:09 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi all,
thanks Max for sharing your (very good) work !
thanks, but the kudos should go to Jakob for that.
I have a strange behavior here, some cross appear in the middle of nowhere... but the blobs are keeping their ID well
That should not be. Can't test it at the moment because Gem is stuck with the beachball (OS X) when i try to access the webcam now. Very strange I didn't update or anything.. Even reboot didn't help (?!) If that stays like that I'll start another thread about it.
did you tried pix_opencv_blobtrack ?
Not yet. I'd like to extend the "Bewegungsmelder" patches with OpenCV examples, but at the moment i feel it is still not fail proof. I'd like to see pd-opencv as a package in debian/ubuntu/mint and also inside Pd-extended. At the moment those patches aim for being very distributable and only depend on Pd + gem.
it's a work in progress and I know the parameters are quiet opaque but I didn't find any documentation about the blobtracker modules in OpenCV... nevertheless, it works quite good I attached a pix_opencv_blobtrack based patch it doesn't work exactly the same as yours but it keeps the IDs
I'll give it a try some time when i am at a Ubuntu machine. thanks!
the main thing is to make the foreground detection module to not update to quickly to keep static blob ID
Am 27.05.2013 um 20:09 schrieb Antoine Villeret antoine.villeret@gmail.com:
I have a strange behavior here, some cross appear in the middle of nowhere... but the blobs are keeping their ID well
could you try again? I just changed the values of the settings. https://github.com/mxa/Bewegungsmelder
hi,
I'm sorry it still doesn't work and I can't find values that works well on the testbed.mov video...
I don't know why, tell me if you want more info or snapshots
cheers
a
-- do it yourself http://antoine.villeret.free.fr
2013/5/28 Max abonnements@revolwear.com
Am 27.05.2013 um 20:09 schrieb Antoine Villeret < antoine.villeret@gmail.com>:
I have a strange behavior here, some cross appear in the middle of
nowhere...
but the blobs are keeping their ID well
could you try again? I just changed the values of the settings. https://github.com/mxa/Bewegungsmelder
Am 30.05.2013 um 14:06 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
I'm sorry it still doesn't work and I can't find values that works well on the testbed.mov video...
I don't know why, tell me if you want more info or snapshots
Did you download all of the files, especially the abstractions you'll need for 07b-multi-blobtracker-IDs.pd? Were there any messages, errors, warnings in the console? What OS and Pd/Gem version are you using?
m.
hi,
2013/6/2 Max abonnements@revolwear.com
Am 30.05.2013 um 14:06 schrieb Antoine Villeret < antoine.villeret@gmail.com>:
hi,
I'm sorry it still doesn't work and I can't find values that works well on the testbed.mov video...
I don't know why, tell me if you want more info or snapshots
Did you download all of the files, especially the abstractions you'll need for 07b-multi-blobtracker-IDs.pd?
i've cloned the Bewegungsmelder repository
Were there any messages, errors, warnings in the console?
nothing explaining that in the console, nothing in the terminal
with quicktime4linux or gmerlin backend : [pix_film:audio_ffmpeg] Codec not found: FFmpeg Sonic decoder [pix_film]: loaded file: /home/antoine/pd/Bewegungsmelder/testbed.mov with 623 frames (480x320) at 25.000000 fps
What OS and Pd/Gem version are you using?
Ubuntu 12.04 Pd 44.2 Gem 0.93.git f890f4d
here is attached a screenshot of what i get
I was guessing a video decompression artefact but I got the same result with all the backends I have that can open testbed.mov (quicktime4linux and gmerlin) but I got the same result with both...
I also converted the video to mjpeg and to h264 and got the same... very strange...
a
m.
wow, this looks so wrong! (your screenshot) I have no idea why this is.
I just tried it under Linux mint 15 (through ssh- XY from os x)
Pd 0.43.2 GEM: ver: 0.93.3 GEM: compiled: Sep 6 2012
and it works perfectly there.
on my other machine, os x 0.44.0-extended-20130213 GEM: ver: 0.93.3 GEM: compiled: Nov 10 2011
it also runs nicely.
I'm afraid I don't know why it isn't running on your machine. can anyone else try it?
max
Am 04.06.2013 um 13:38 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
2013/6/2 Max abonnements@revolwear.com
Am 30.05.2013 um 14:06 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
I'm sorry it still doesn't work and I can't find values that works well on the testbed.mov video...
I don't know why, tell me if you want more info or snapshots
Did you download all of the files, especially the abstractions you'll need for 07b-multi-blobtracker-IDs.pd? i've cloned the Bewegungsmelder repository Were there any messages, errors, warnings in the console? nothing explaining that in the console, nothing in the terminal
with quicktime4linux or gmerlin backend : [pix_film:audio_ffmpeg] Codec not found: FFmpeg Sonic decoder [pix_film]: loaded file: /home/antoine/pd/Bewegungsmelder/testbed.mov with 623 frames (480x320) at 25.000000 fps
What OS and Pd/Gem version are you using? Ubuntu 12.04 Pd 44.2 Gem 0.93.git f890f4d
here is attached a screenshot of what i get
I was guessing a video decompression artefact but I got the same result with all the backends I have that can open testbed.mov (quicktime4linux and gmerlin) but I got the same result with both...
I also converted the video to mjpeg and to h264 and got the same... very strange...
a
m.
<Capture du 2013-06-04 13:06:45.png>
Le 05/06/2013 22:17, Max a écrit :
wow, this looks so wrong! (your screenshot) I have no idea why this is.
I just tried it under Linux mint 15 (through ssh- XY from os x)
Pd 0.43.2 GEM: ver: 0.93.3 GEM: compiled: Sep 6 2012
and it works perfectly there.
on my other machine, os x 0.44.0-extended-20130213 GEM: ver: 0.93.3 GEM: compiled: Nov 10 2011
it also runs nicely.
I'm afraid I don't know why it isn't running on your machine. can anyone else try it?
max
Am 04.06.2013 um 13:38 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
2013/6/2 Max abonnements@revolwear.com
Am 30.05.2013 um 14:06 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
I'm sorry it still doesn't work and I can't find values that works well on the testbed.mov video...
I don't know why, tell me if you want more info or snapshots
Did you download all of the files, especially the abstractions you'll need for 07b-multi-blobtracker-IDs.pd? i've cloned the Bewegungsmelder repository Were there any messages, errors, warnings in the console? nothing explaining that in the console, nothing in the terminal
with quicktime4linux or gmerlin backend : [pix_film:audio_ffmpeg] Codec not found: FFmpeg Sonic decoder [pix_film]: loaded file: /home/antoine/pd/Bewegungsmelder/testbed.mov with 623 frames (480x320) at 25.000000 fps
What OS and Pd/Gem version are you using? Ubuntu 12.04 Pd 44.2 Gem 0.93.git f890f4d
here is attached a screenshot of what i get
I was guessing a video decompression artefact but I got the same result with all the backends I have that can open testbed.mov (quicktime4linux and gmerlin) but I got the same result with both...
I also converted the video to mjpeg and to h264 and got the same... very strange...
a
m.
<Capture du 2013-06-04 13:06:45.png>
Hello Max,
I have the same results than Antoine. A screenshot is attached. Configuration : Ubuntu 13.04, Pd 0.44.3, Gem ver: 0.93.git 374f713. ++
Jack
On Thu, 2013-06-06 at 18:18 +0200, Jack wrote:
Le 05/06/2013 22:17, Max a écrit :
wow, this looks so wrong! (your screenshot) I have no idea why this is.
I just tried it under Linux mint 15 (through ssh- XY from os x)
Pd 0.43.2 GEM: ver: 0.93.3 GEM: compiled: Sep 6 2012
and it works perfectly there.
on my other machine, os x 0.44.0-extended-20130213 GEM: ver: 0.93.3 GEM: compiled: Nov 10 2011
it also runs nicely.
I'm afraid I don't know why it isn't running on your machine. can anyone else try it?
max
Am 04.06.2013 um 13:38 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
2013/6/2 Max abonnements@revolwear.com
Am 30.05.2013 um 14:06 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
I'm sorry it still doesn't work and I can't find values that works well on the testbed.mov video...
I don't know why, tell me if you want more info or snapshots
Did you download all of the files, especially the abstractions you'll need for 07b-multi-blobtracker-IDs.pd? i've cloned the Bewegungsmelder repository Were there any messages, errors, warnings in the console? nothing explaining that in the console, nothing in the terminal
with quicktime4linux or gmerlin backend : [pix_film:audio_ffmpeg] Codec not found: FFmpeg Sonic decoder [pix_film]: loaded file: /home/antoine/pd/Bewegungsmelder/testbed.mov with 623 frames (480x320) at 25.000000 fps
What OS and Pd/Gem version are you using? Ubuntu 12.04 Pd 44.2 Gem 0.93.git f890f4d
here is attached a screenshot of what i get
I was guessing a video decompression artefact but I got the same result with all the backends I have that can open testbed.mov (quicktime4linux and gmerlin) but I got the same result with both...
I also converted the video to mjpeg and to h264 and got the same... very strange...
a
m.
<Capture du 2013-06-04 13:06:45.png>
Hello Max,
I have the same results than Antoine. A screenshot is attached. Configuration : Ubuntu 13.04, Pd 0.44.3, Gem ver: 0.93.git 374f713.
Just an uneducated guess: Could it be that this is caused by objects being positioned on the same Z-plane (or quite close to each other) so that some overlapping occurs on some gfx cards, but not on some others?
Roman
Am 06.06.2013 um 18:33 schrieb Roman Haefeli reduzent@gmail.com:
I have the same results than Antoine. A screenshot is attached. Configuration : Ubuntu 13.04, Pd 0.44.3, Gem ver: 0.93.git 374f713.
Just an uneducated guess: Could it be that this is caused by objects being positioned on the same Z-plane (or quite close to each other) so that some overlapping occurs on some gfx cards, but not on some others?
no, the crosshairs should not be where they are on those screenshots. not a z-plane issue. i'll try the git version of gem, maybe something changed in gem? that's my only guess. m.
Am 06.06.2013 um 18:18 schrieb Jack jack@rybn.org:
Hello Max,
I have the same results than Antoine. A screenshot is attached. Configuration : Ubuntu 13.04, Pd 0.44.3, Gem ver: 0.93.git 374f713.
I just tested it with another machine Windows Pd-ext 0.43 / Gem 0.92 Windows Pd-ext 0.44 / Gem 0.93.3 both work as expected.
I'm wondering if it really could be your unreleased Gem version. Could you try a precompiled stock version instead?
m.
hi,
it works on my machine (Ubuntu 64bit) with pd 0.44-extended-20130528 (Gem 93.3) and I can also confirm it works with latest pd vanilla and Gem 0.93.3 and it doesn't with the latest Gem from Git but I don't know why yet...
a
-- do it yourself http://antoine.villeret.free.fr
2013/6/6 Max abonnements@revolwear.com
Am 06.06.2013 um 18:18 schrieb Jack jack@rybn.org:
Hello Max,
I have the same results than Antoine. A screenshot is attached. Configuration : Ubuntu 13.04, Pd 0.44.3, Gem ver: 0.93.git 374f713.
I just tested it with another machine Windows Pd-ext 0.43 / Gem 0.92 Windows Pd-ext 0.44 / Gem 0.93.3 both work as expected.
I'm wondering if it really could be your unreleased Gem version. Could you try a precompiled stock version instead?
m. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Bonjour Antoine et merci beacuoup. Thanks a lot for testing this. A change in behavior between Gem release and git is probably not intended, so that's where I hope IOhannes can have a look into.
max
Am 10.06.2013 um 17:34 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
it works on my machine (Ubuntu 64bit) with pd 0.44-extended-20130528 (Gem 93.3) and I can also confirm it works with latest pd vanilla and Gem 0.93.3 and it doesn't with the latest Gem from Git but I don't know why yet...
a
-- do it yourself
http://antoine.villeret.free.fr2013/6/6 Max abonnements@revolwear.com
Am 06.06.2013 um 18:18 schrieb Jack jack@rybn.org:
Hello Max,
I have the same results than Antoine. A screenshot is attached. Configuration : Ubuntu 13.04, Pd 0.44.3, Gem ver: 0.93.git 374f713.
I just tested it with another machine Windows Pd-ext 0.43 / Gem 0.92 Windows Pd-ext 0.44 / Gem 0.93.3 both work as expected.
I'm wondering if it really could be your unreleased Gem version. Could you try a precompiled stock version instead?
m. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
IOhannes just confirmed that the pix_multiblob code has changed and thus broke the patch. Since i don't have the git version compiled I can't test here. So that is a confirmed Gem problem. I don't see the point to work with that object any more, now that I know that the new version breaks backward compatibility. I want to be able to make a patch that works with whatever gem version : (
Am 10.06.2013 um 18:58 schrieb Max abonnements@revolwear.com:
Bonjour Antoine et merci beacuoup. Thanks a lot for testing this. A change in behavior between Gem release and git is probably not intended, so that's where I hope IOhannes can have a look into.
max
Am 10.06.2013 um 17:34 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
it works on my machine (Ubuntu 64bit) with pd 0.44-extended-20130528 (Gem 93.3) and I can also confirm it works with latest pd vanilla and Gem 0.93.3 and it doesn't with the latest Gem from Git but I don't know why yet...
a
-- do it yourself
http://antoine.villeret.free.fr2013/6/6 Max abonnements@revolwear.com
Am 06.06.2013 um 18:18 schrieb Jack jack@rybn.org:
Hello Max,
I have the same results than Antoine. A screenshot is attached. Configuration : Ubuntu 13.04, Pd 0.44.3, Gem ver: 0.93.git 374f713.
I just tested it with another machine Windows Pd-ext 0.43 / Gem 0.92 Windows Pd-ext 0.44 / Gem 0.93.3 both work as expected.
I'm wondering if it really could be your unreleased Gem version. Could you try a precompiled stock version instead?
On 06/15/13 16:03, Max wrote:
So that is a confirmed Gem problem. I don't see the point to work with that object any more, now that I know that the new version breaks backward compatibility. I want to be able to make a patch that works with whatever gem version : (
i think that' a bitter conclusion to draw. obviously the object should be backwards compatible, and it being not is a bug.
rather than ranting about "not seeing the point any mor" it would be good to help fix the bug.
fgdstn IOhannes
hi,
pix_multiblob algorithm changes just after the 0.93.3 release in november 2011 Ricardo Fabbri made those changes so maybe he is the best person to help us figuring out where the "bug" is, if this is really a bug
since the algorithm changed I'm not so surprised that the same patch with the same parameters doesn't work in both case
if pix_multiblob should be backward compatible, could it be possible to rename the Ricardo's version to pix_multiblob2 or something else and to restore the 0.93.3's version in the Gem's main trunk ? or is it better to put the two algorithms in the same pix_multiblob object and select it with a [mode( message or something else ?
cheers
a
-- do it yourself http://antoine.villeret.free.fr
2013/6/15 IOhannes m zmölnig zmoelnig@iem.at
On 06/15/13 16:03, Max wrote:
So that is a confirmed Gem problem. I don't see the point to work with
that object any more, now that I know that the new version breaks backward compatibility. I want to be able to make a patch that works with whatever gem version : (
i think that' a bitter conclusion to draw. obviously the object should be backwards compatible, and it being not is a bug.
rather than ranting about "not seeing the point any mor" it would be good to help fix the bug.
fgdstn IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK, my apologies to IOhannes for the rant, I was in the understanding that this is how the object works now.
Now that it's clarified that this is a bug, not a feature. It should be evaluated why it behaves differently and if it is worth it to keep the changes or we can go back to the original. Maybe ricoardo can tell us more about the changes? If the changes are worth to keep but can't be compatible to the original i see two options:
- make ricardos version pix_multiblob2
- send a message (and second argument) to pix_multiblob to set it to the alternative (ricardos) mode.
What can i do, to help fixing it? I didn't quite understand what you meant at the IRC.
m.
Am 16.06.2013 um 12:19 schrieb Antoine Villeret antoine.villeret@gmail.com:
hi,
pix_multiblob algorithm changes just after the 0.93.3 release in november 2011 Ricardo Fabbri made those changes so maybe he is the best person to help us figuring out where the "bug" is, if this is really a bug
since the algorithm changed I'm not so surprised that the same patch with the same parameters doesn't work in both case
if pix_multiblob should be backward compatible, could it be possible to rename the Ricardo's version to pix_multiblob2 or something else and to restore the 0.93.3's version in the Gem's main trunk ? or is it better to put the two algorithms in the same pix_multiblob object and select it with a [mode( message or something else ?
cheers
a
-- do it yourself
http://antoine.villeret.free.fr2013/6/15 IOhannes m zmölnig zmoelnig@iem.at On 06/15/13 16:03, Max wrote:
So that is a confirmed Gem problem. I don't see the point to work with that object any more, now that I know that the new version breaks backward compatibility. I want to be able to make a patch that works with whatever gem version : (
i think that' a bitter conclusion to draw. obviously the object should be backwards compatible, and it being not is a bug.
rather than ranting about "not seeing the point any mor" it would be good to help fix the bug.
fgdstn IOhannes
-
Antoine Villeret -
IOhannes m zmölnig -
Jack -
Max -
Roman Haefeli