Hi list,
how to analyze a specific area (XY) from a video to it's color values? pix_data just takes still images.
any hints appreciated.
max
I think pix_crop will copy the desired rect and pass that along to the next object. What type of analysis do you want to do after that?
cgc
On May 26, 2005, at 10:34 AM, Max Neupert wrote:
Hi list,
how to analyze a specific area (XY) from a video to it's color values? pix_data just takes still images.
any hints appreciated.
max
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi chris,
thank you. i've found a way to do it with the buffer objects:
to test it i used a pix_movie instead of pix_video first which did not work. a pix_film did though. how comes this? what's the difference between pix_movie and pix_film? i guess there is no celluloid involved anyway.
max
Am 27.05.2005 um 08:20 schrieb chris clepper:
I think pix_crop will copy the desired rect and pass that along to the next object. What type of analysis do you want to do after that?
cgc
On May 26, 2005, at 10:34 AM, Max Neupert wrote:
Hi list,
how to analyze a specific area (XY) from a video to it's color values? pix_data just takes still images.
any hints appreciated.
max
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Max Neupert wrote:
hi chris,
thank you. i've found a way to do it with the buffer objects:
it works perfectly with [pix_data] (there is no such thing like "still image" vs "video stream" in Gem (which has also a lot of drawbacks)
to test it i used a pix_movie instead of pix_video first which did not work. a pix_film did though. how comes this? what's the difference between pix_movie and pix_film? i guess there is no celluloid involved anyway.
true.
[pix_movie] directly applies the video as a texture (and does not put add it to the pixel-buffer-render-chain). [pix_movie] is far older than [pix_film] (which was named differently to stay compatible)
i think the help-files mention that though.
mfg.adr IOhannes
Am 27.05.2005 um 16:46 schrieb IOhannes m zmoelnig:
Max Neupert wrote:
hi chris,
thank you. i've found a way to do it with the buffer objects:
it works perfectly with [pix_data] (there is no such thing like "still image" vs "video stream" in Gem (which has also a lot of drawbacks)
indeed. my conclusion that it would be because of the moving image comparing the behavior of pix_data in combination with pix_image and pix_movie was wrong.
thanks.
to test it i used a pix_movie instead of pix_video first which did not work. a pix_film did though. how comes this? what's the difference between pix_movie and pix_film? i guess there is no celluloid involved anyway.
true.
[pix_movie] directly applies the video as a texture (and does not put add it to the pixel-buffer-render-chain). [pix_movie] is far older than [pix_film] (which was named differently to stay compatible)
i think the help-files mention that though.
it is mentioned that pix_movie does not need to be textured which sounds like an advantage first.
grüße,
max
On May 27, 2005, at 9:55 AM, Max Neupert wrote:
it is mentioned that pix_movie does not need to be textured which sounds like an advantage first.
It doesn't need the separate texturing object pix_texture like pix_film/video because all of the movie playing and texturing code is contained in one object. On OSX this is an advantage since certain fast path texturing functions require tight control over execution order that can't be assured when using pix_film+texture. On DV/SD material the difference is only a few percent per source, but on HD (1080 in particular) the gain can be 25% or more per source. I have plans to work on a pixel format auto-detection for pix_movie that will help make sure the optimum path is used no matter what.
cgc
-
chris clepper -
IOhannes m zmoelnig -
Max Neupert