hello everyone
i just realized, that [pix_write], unlike [pix_record], takes its images from the framebuffer. when working exclusively in the pix-domain, using [pix_write] creates a huge cpu-overhead, that wouldn't be necessary, afaik. otoh, [pix_record] does crash to often to be used in everyday life. is there a way to capture single images from a pix-stream? if not, are there plans for a [pix_image_write] (or however this should be called)?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
hello everyone
i just realized, that [pix_write], unlike [pix_record], takes its images from the framebuffer. when working exclusively in the pix-domain, using [pix_write] creates a huge cpu-overhead, that wouldn't be necessary,
you are totally right.
afaik. otoh, [pix_record] does crash to often to be used in everyday life.
it would be good to fix this ;-)
is there a way to capture single images from a pix-stream? if not, are there plans for a [pix_image_write] (or however this should be called)?
i guess the main problem is that [pix_write] is already taken. so come up with a proper name ([pix_image_write] is almost as clumsy as [pix_buffer_read]) and it shall be done!
fmgadr IOhannes
My guess is that pix_write came before pix_snap which is why they have duplicate functionality.
I suppose pix_write could have two modes: one for capturing the GL backbuffer and one for working with pix_ frames. That is about as good/bad as pix_image_write for a solution.
On 6/4/07, Roman Haefeli reduzierer@yahoo.de wrote:
hello everyone
i just realized, that [pix_write], unlike [pix_record], takes its images from the framebuffer. when working exclusively in the pix-domain, using [pix_write] creates a huge cpu-overhead, that wouldn't be necessary, afaik. otoh, [pix_record] does crash to often to be used in everyday life. is there a way to capture single images from a pix-stream? if not, are there plans for a [pix_image_write] (or however this should be called)?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Tue, 2007-06-05 at 10:05 -0500, chris clepper wrote:
My guess is that pix_write came before pix_snap which is why they have duplicate functionality.
I suppose pix_write could have two modes: one for capturing the GL backbuffer and one for working with pix_ frames. That is about as good/bad as pix_image_write for a solution.
sorry to stick with this, but will there be such a thing in future versions of gem?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On 6/5/07, Roman Haefeli reduzierer@yahoo.de wrote:
On Tue, 2007-06-05 at 10:05 -0500, chris clepper wrote:
I suppose pix_write could have two modes: one for capturing the GL backbuffer and one for working with pix_ frames. That is about as good/bad as pix_image_write for a solution.
sorry to stick with this, but will there be such a thing in future versions of gem?
The certainly could be. I guess we just have to decide on which way to do it. pix_image_write is fine with me.
This is actually not a bad starter project for someone looking to figure out how GEM pix_ processing works. It doesn't require any per pixel loops and you have to dig around in some base classes to get the image exporter function.
I think this would be best implimented into the pix_buffer stuff, so that you would choose some frames from a pix chain (not the framebuffer) write them to a pix_buffer, and then save them from there. pix_write is really for writing files from the framebuffer, not from chains...
I wonder if anyone has made a patch that saves the framebuffer with pix_write and also loads that image somehow, not a very easy task...
I vote for "open" and "save" for pix_buffer. I think pix_buffer may already support "open?"
..b..
chris clepper wrote:
On 6/5/07, Roman Haefeli reduzierer@yahoo.de wrote:
On Tue, 2007-06-05 at 10:05 -0500, chris clepper wrote:
I suppose pix_write could have two modes: one for capturing the GL backbuffer and one for working with pix_ frames. That is about as good/bad as pix_image_write for a solution.
sorry to stick with this, but will there be such a thing in future versions of gem?
The certainly could be. I guess we just have to decide on which way to do it. pix_image_write is fine with me.
This is actually not a bad starter project for someone looking to figure out how GEM pix_ processing works. It doesn't require any per pixel loops and you have to dig around in some base classes to get the image exporter function.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 6/8/07, B. Bogart ben@ekran.org wrote:
I think this would be best implimented into the pix_buffer stuff, so that you would choose some frames from a pix chain (not the framebuffer) write them to a pix_buffer, and then save them from there. pix_write is really for writing files from the framebuffer, not from chains...
I wonder if anyone has made a patch that saves the framebuffer with pix_write and also loads that image somehow, not a very easy task...
I vote for "open" and "save" for pix_buffer. I think pix_buffer may already support "open?"
It supports both. This method would work but you have to manage the filenames yourself. There is also the possibility of duplicate or missed frames depending on if the source is driven by Pd messages or the internal GemState.
-
B. Bogart -
chris clepper -
IOhannes m zmoelnig -
Roman Haefeli