At 11:46 AM +0100 1/19/04, Julean Simon wrote:
cgc, already tried it with pix_write, but it didnt do anything, attaching a [file <test.jpg> <0>] to the [pix_write]. [auto 1] should actually grab every pict or do i have to use a metro 25 bang?. is there an example-patch somewhere, i guess i dont understand how it works.
try the example in 02.advanced/09.SnapshotSave.pd - hit the big bang to have it write a file to the pd/bin directory (not /tmp/gemshot). that patch can be simplified by just banging the pix_write object for each frame after initialization. you can use the render_trigger object to have the capture occur every time the render chain is run or you can do async capture using a metro.
i wanted to use 768 *576 (=pal) format and acceptable quality because i intendet to re-read the sequence into the same patch later and mix it with video.
NTSC SD (720x480 @ 30fps) is just barely possible on my 1ghz Tibook if the render patch is very lightweight. This is under 10.2 though and I have heard that glReadPixels is much improved on 10.3 - the Apple engineers quoted a 3ms time to return the buffer on similar hardware.
inputting video would have been my second question: i only managed to read in a qt-mov, how would i get the video-signal from a cam connected via firewire?
use pix_video. give the object arguments for the dimensions of your capture like: [pix_video 720 576] and it will grab a full PAL frame from the DV cam. one thing to note is that for some reason QT has this 'high quality' flag for video capture that does contradictory things depending on what type of device you plug in. if you use a FW webcam then send a 'quality 1' message followed by a 'reset' message to the object. if you use a DV cam then do the same thing only with 'quality 0'. the difference is that the 1 level will be fast but interlaced and the latter will be a little slower but de-interlaced. 1 is supposedly 'high quality' although I think interlaced DV looks very low quality. oh well.
thanx for taking the time. julean
you're welcome.
cgc