hello everyone,
can anybody tell me how to use the "pix_write" - object proper or where I can find documentation about it ?
thanks a lot
bernard
Bernhard Zösmayr wrote:
hello everyone,
can anybody tell me how to use the "pix_write" - object proper or where I can find documentation about it ?
aye !
although i have coded it, i had a lot of problems myself, getting it to work ;-) in theory, it should write down a frameshot to disk, either by "bang"ing it, or automatically each render-cycle.
anyhow, pix_write is very pre-alpha (and therefore not documented)) hopefully i will find some time to add jpeg-support and make the controlling somehow sensible (or at least, understandable). it shouldn't be that hard. since the control-behaviour is VERY likey to change, i wouldn't use it very much...
creation: 4 arguments are allowed, 2 are (still) recommended: "pix_write 0 0 100 100" will snap a image of size 100x100pixels, starting in the lower-left corner. if your gem-win is 256x256 pixels large, you will capture about 1/4 (and not the whole frame, scaled down to 100x100) "pix_write 256 256" will capture a 256x256-pixel-sized frame, starting at 0+0
you can change both position and size by sending pairs of floats to the second (third) inlet.
usage: "auto 0" will *start* writing TIFFs each rendering-cycle "auto" will *stop* writing TIFFs "auto <n>" should start writing compressed (level <n>) JPEGs, but is not yet implemented
"auto mypath 0", should *start* writing TIFFS named mypath<i>, with i counting from 0 upwards.
i do not know, whether it really works this way.... i do hope, that i will find some time soon to fix the behaviour (stop "auto" stopping to automatically write and "auto 0" start it,...)
mfg.csa.df IOhannes
thanks a lot
bernard
hy bernard, list
pix_write has to be the last object of the gem-list (for example you have to connect the OUTLET of a cube object to the inlet of pix_write) pix_write's 2nd inlet understands a list of 2 integers which corresponds to the lower left corner of your snapshot (xy position). the 3rd inlet also accepts a list of 2 integers which is the snapshot's size (xy size). for example if your gemwin has 640x480 px and you want to grab the whole win you have send "0 0" to the 2nd and "640 480" to the 3rd inlet. if you just want to grab a 100x100px area from the center of the gemwin send "270 190" to the 3nd and "100 100" to the 3rd inlet ... (the messages "vert_pos x y" and "vert_size x y" both to the 1st inlet do the same as "x y" (position) to the second and "x y" (size) to the 3rd inlet). was this clear?!?
the snapshots will be saved in the pd/bin directory with successive numbers as tif files (gemmgem100000.tif). i didn't find out yet how to tell pix_write a costum place to save the tiffs and how to change the default name and the starting number. ...johannes?
with a "metro 40" banging pix_write i grabbed a few seconds with 720x576px at 25fps. it was a patch with 9 cubes spinning around and i noticed that pd/gem waited with the action until a snapshot was written to disk. the 5 seconds i "recorded" took about 30 seconds to be saved. i then got a 125 frame tiff-sequence with a smooth movement just like in the gemwin. that's cool! can anyone explain this behavior?
cheers, ulrich
On Tue, 27 Nov 2001, Bernhard [iso-8859-1] Z�smayr wrote:
hello everyone,
can anybody tell me how to use the "pix_write" - object proper or where I can find documentation about it ?
thanks a lot
bernard
Ulrich Kehrer wrote:
hy bernard, list
since ulrich is the only one i know, who has used pix_write (without hacking the source, i guess ??), maybe holds more truth than mine. i used pix_write a week ago, and i hacked it to make it run...
pix_write has to be the last object of the gem-list (for example you have to connect the OUTLET of a cube object to the inlet of pix_write)
this should not be true; you can use pix_write in it's own gemlist, but you should make sure, that this list is rendered *after* all the other lists, you want to be on the frameshot.
the snapshots will be saved in the pd/bin directory with successive numbers as tif files (gemmgem100000.tif). i didn't find out yet how to tell pix_write a costum place to save the tiffs and how to change the default name and the starting number. ...johannes?
in theory, you can just call it with "write <my_custom_path_and_nameprefix>" or, alternatively (and i do not know right now whether they work together) "auto <my_custom_path_and_nameprefix>". calling with "auto" should reset the counter.
with a "metro 40" banging pix_write i grabbed a few seconds with 720x576px at 25fps. it was a patch with 9 cubes spinning around and i noticed that pd/gem waited with the action until a snapshot was written to disk. the 5 seconds i "recorded" took about 30 seconds to be saved. i then got a 125 frame tiff-sequence with a smooth movement just like in the gemwin. that's cool! can anyone explain this behavior?
not that cool, i would say.... "bang" does not immediatly save the current frame to disk; instead the next time, things are rendered, the snapshot is taken and saved.
by the way, what videocard are you using ? do you have a slow harddisk ? when i was recording 20secs of full PAL-resolution in "auto"-mode, i had no speed-problems at all.
mfg.-cd.asdr IOhannes
On Tue, 27 Nov 2001, IOhannes m zmoelnig wrote:
in theory, you can just call it with "write <my_custom_path_and_nameprefix>"
that didn't work.
by the way, what videocard are you using ? do you have a slow harddisk ? when i was recording 20secs of full PAL-resolution in "auto"-mode, i had no speed-problems at all.
the harddisk is not the fastest...my computer is already a few years old. the only thing i've upgraded lately was the graphic-card to a geforce2.
i think i'll try "auto" now instead of a metro banging pix_write.
regards, ulrich
...no, i didn't hack the source, i just took a look at it ;)
-
Bernhard Zösmayr -
IOhannes m zmoelnig -
Ulrich Kehrer