I've been attempting to build on the stop-motion animation patch that guido built some time ago (attached). I want to output each new frame to an image but there's one problem: [pix_write] reads what is currently in the frame buffer, which could be one of the old pictures. Is there any way to make it read from a specific point in the frame buffer?
Antonio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-20 12:21, Antonio Roberts wrote:
I've been attempting to build on the stop-motion animation patch that guido built some time ago (attached). I want to output each new frame to an image but there's one problem: [pix_write] reads what is currently in the frame buffer, which could be one of the old pictures. Is there any way to make it read from a specific point in the frame buffer?
a "framebuffer" in openGL- and Gem-land usually means a "canvas" where you draw to. [gemwindow] is a typical framebuffer, [gemframebuffer] (what's that name..?) as well.
[pix_write] will indeed read from this framebuffer. you can specify where in the framebuffer it reads via the "offset" & "dimension" parameters.
[pix_buffer], while being a "buffer" that holds "frames", is NOT a framebuffer in this parlance.
you can use the [save foo.jpg 42( message to save a pix from the [pix_buffer] to the disk. the last argument ("42" in this case) denotes the slot to read the image from.
fgasdr IOhannes
Thanks for the help on this. I've attached the updated patch. After choosing a directory to save the files all of the shots will be saved as jpgs.
I noticed some weird behaviour when pressing the Record (big red) button. The save message is trying to save from a buffer slot that isn't yet filled. I thought it was a race condition, so added a [t b b] but that didn't solve it. I don't know what the exact problem is, but the workdaround that I used seems to work
Antonio
On 20 March 2012 12:06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-20 12:21, Antonio Roberts wrote:
I've been attempting to build on the stop-motion animation patch that guido built some time ago (attached). I want to output each new frame to an image but there's one problem: [pix_write] reads what is currently in the frame buffer, which could be one of the old pictures. Is there any way to make it read from a specific point in the frame buffer?
a "framebuffer" in openGL- and Gem-land usually means a "canvas" where you draw to. [gemwindow] is a typical framebuffer, [gemframebuffer] (what's that name..?) as well.
[pix_write] will indeed read from this framebuffer. you can specify where in the framebuffer it reads via the "offset" & "dimension" parameters.
[pix_buffer], while being a "buffer" that holds "frames", is NOT a framebuffer in this parlance.
you can use the [save foo.jpg 42( message to save a pix from the [pix_buffer] to the disk. the last argument ("42" in this case) denotes the slot to read the image from.
fgasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9oct4ACgkQkX2Xpv6ydvSdSQCgpS3lASLj8qZ5Y2vI2xX2FFJU tYIAoKEx3CZRE++bKPOUakALFUxZIyb7 =G992 -----END PGP SIGNATURE-----
Hi,
I try to do the similar thing, capturing from pix_video, saving a specific frame of [pix_buffer] to jpg files. However, the color space and the resolution of saved jpg file is changed. Even saving tiff is the same result. I know one of the ways is converting Gemlist from YUV to RGBA using [pix_rgba] before inputing [pix_buffer_write], but it is told "CPU-consumptive". So, is there any solutions to save YUV data in pix_buffer directly to jpg file with keeping colorspace and resolution. I am using Mac OS 10.7.4 and pd-extended 0.42.5. Thanks in progress.
Sei
__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ Seiichiro Matsumura
sei@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
2012/3/22 Antonio Roberts antonio@hellocatfood.com:
Thanks for the help on this. I've attached the updated patch. After choosing a directory to save the files all of the shots will be saved as jpgs.
I noticed some weird behaviour when pressing the Record (big red) button. The save message is trying to save from a buffer slot that isn't yet filled. I thought it was a race condition, so added a [t b b] but that didn't solve it. I don't know what the exact problem is, but the workdaround that I used seems to work
Antonio
On 20 March 2012 12:06, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-20 12:21, Antonio Roberts wrote:
I've been attempting to build on the stop-motion animation patch that guido built some time ago (attached). I want to output each new frame to an image but there's one problem: [pix_write] reads what is currently in the frame buffer, which could be one of the old pictures. Is there any way to make it read from a specific point in the frame buffer?
a "framebuffer" in openGL- and Gem-land usually means a "canvas" where you draw to. [gemwindow] is a typical framebuffer, [gemframebuffer] (what's that name..?) as well.
[pix_write] will indeed read from this framebuffer. you can specify where in the framebuffer it reads via the "offset" & "dimension" parameters.
[pix_buffer], while being a "buffer" that holds "frames", is NOT a framebuffer in this parlance.
you can use the [save foo.jpg 42( message to save a pix from the [pix_buffer] to the disk. the last argument ("42" in this case) denotes the slot to read the image from.
fgasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9oct4ACgkQkX2Xpv6ydvSdSQCgpS3lASLj8qZ5Y2vI2xX2FFJU tYIAoKEx3CZRE++bKPOUakALFUxZIyb7 =G992 -----END PGP SIGNATURE-----
--
antonio@hellocatfood.com http://www.hellocatfood.com ============================
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-10 05:53, Seiichiro MATSUMURA wrote:
Hi,
I try to do the similar thing, capturing from pix_video, saving a specific frame of [pix_buffer] to jpg files. However, the color space and the resolution of saved jpg file is changed. Even saving tiff is the same result.
i'm pretty suzre, that the resolution of the image does not change, even on OSX. with chnaged "color space", do you mean that the colors are stored in the wrong order? or do you mean that your YUV pix ends up as an ARGB image? the latter is not a bug, the former is.
I know one of the ways is converting Gemlist from YUV to RGBA using [pix_rgba] before inputing [pix_buffer_write], but it is told "CPU-consumptive".
are you only told that it is CPU-consumptive, or do you experience any actual problems?
if the conversion is indeed too CPU intensive and you only take snapshots every now and then (not every frame), you could put the [pix_rgba] in a branch that is only executed when needed.
e.g.
gemlist | [r spigot] | | [spigot ] | [t a b] | | | [; spigiot 0( | [pix_rgba] | [r writer] | | [pix_buffer_write foo] | [save /tmp/foo.jpg 0( | [pix__buffer foo[
and click this to capture an image: [; spigot 1; writer 0(
So, is there any solutions to save YUV data in pix_buffer directly to jpg file with keeping colorspace and resolution. I am using Mac OS 10.7.4 and pd-extended 0.42.5.
sorry, i cannot keep track of all the various distributions of Gem.
so, which version of Gem are you using? which image-writing backends are installed (Gem should printout something like "Image saving support: QuickTime")
mfgds IOhannes
Hi IOhannes,
Thanks for your quick reply.
i'm pretty suzre, that the resolution of the image does not change, even on OSX. with chnaged "color space", do you mean that the colors are stored in the wrong order? or do you mean that your YUV pix ends up as an ARGB image?
The attached picture named "test.jpg" is what I saved using the attached patch. The original pict in a buffer is like right hand side of another attached picture "screenshot_gemwin.jpg". Somehow colors are changed, the width become half and a picture itself is doubled. This is what I meant changing "color space" and "resolution". Is this not happening on your OSX? With my machine, this phenomena happens not only on OSX lion but also 10.6.8 Snow Leopard.
are you only told that it is CPU-consumptive, or do you experience any actual problems?
In my case this time, I don't face the CPU-consumptive problem yet, because I need to play back and save only 16 frimes from buffers of pix_buffer. Your suggestion patch is one of solutions if I only save few specific frames. However in my another future project, I would like to record longer movie from pix_video and save all frames, it would be more than 1000 to 2000 frames. I am just wondering it would work fine with [pix_rgba] conversion beside regarding the help file description and the past articles on ML as; http://lists.puredata.info/pipermail/gem-dev/2009-03/003895.html
so, which version of Gem are you using?
I am using GEM: ver: 0.92.3.
which image-writing backends are installed (Gem should printout something like "Image saving support: QuickTime")
The printout should be come out on Pd window? There is no printout when saving a frame of pix_buffer. How can I get it?
Cheers,
Sei
-- __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ Seiichiro Matsumura
sei@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
2012/7/10 IOhannes m zmoelnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-10 05:53, Seiichiro MATSUMURA wrote:
Hi,
I try to do the similar thing, capturing from pix_video, saving a specific frame of [pix_buffer] to jpg files. However, the color space and the resolution of saved jpg file is changed. Even saving tiff is the same result.
i'm pretty suzre, that the resolution of the image does not change, even on OSX. with chnaged "color space", do you mean that the colors are stored in the wrong order? or do you mean that your YUV pix ends up as an ARGB image? the latter is not a bug, the former is.
I know one of the ways is converting Gemlist from YUV to RGBA using [pix_rgba] before inputing [pix_buffer_write], but it is told "CPU-consumptive".
are you only told that it is CPU-consumptive, or do you experience any actual problems?
if the conversion is indeed too CPU intensive and you only take snapshots every now and then (not every frame), you could put the [pix_rgba] in a branch that is only executed when needed.
e.g.
gemlist | [r spigot] | | [spigot ] | [t a b] | | | [; spigiot 0( | [pix_rgba] | [r writer] | | [pix_buffer_write foo] | [save /tmp/foo.jpg 0( | [pix__buffer foo[
and click this to capture an image: [; spigot 1; writer 0(
So, is there any solutions to save YUV data in pix_buffer directly to jpg file with keeping colorspace and resolution. I am using Mac OS 10.7.4 and pd-extended 0.42.5.
sorry, i cannot keep track of all the various distributions of Gem.
so, which version of Gem are you using? which image-writing backends are installed (Gem should printout something like "Image saving support: QuickTime")
mfgds IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/702AACgkQkX2Xpv6ydvQT/QCg1pqNQkZ6XRuhR+PYOWAnt6Lu QHkAoKgfftr7nCytv7dkrZfDC2uRaAUb =W6zJ -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Seiichiro MATSUMURA wrote:
Somehow colors are changed, the width become half and a picture itself is doubled.
iirc, in YUV you have a luminance layer (Y) and then the colors encoded in a strange way, like 1 value for 2 pixels for the width in the U and V layers. Well, something like that. Maybe it's a bug in the colorspace conversion because you don't make it explicit ?
Thanks Charles.
As you mentioned, YUV consists Y for Luma, U and V for the color difference of from Luma to Blue and Red(chrominance), basically describes colors based on brightness. I could realize with Wikipedia. http://en.wikipedia.org/wiki/YUV It also seems "1 value for 2 pixels" makes sense for weird saved jpeg file.
For converting YUV to RGB, the formula is necessary. http://www.fourcc.org/fccyvrgb.php
So, I would like to know whether YUV data in buffer are automatically recognized and converted to RGB data with this formula for saving a jpeg file when "save" command to [pix_buffer] works. Otherwise, do we have to use [pix_rgba] before putting data in [pix_buffer]?
Best,
Sei
2012/7/10 Charles Goyard cg@fsck.fr:
Seiichiro MATSUMURA wrote:
Somehow colors are changed, the width become half and a picture itself is doubled.
iirc, in YUV you have a luminance layer (Y) and then the colors encoded in a strange way, like 1 value for 2 pixels for the width in the U and V layers. Well, something like that. Maybe it's a bug in the colorspace conversion because you don't make it explicit ?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 07/10/2012 02:03 PM, Seiichiro MATSUMURA wrote:
The attached picture named "test.jpg" is what I saved using the attached patch. The original pict in a buffer is like right hand side of another attached picture "screenshot_gemwin.jpg". Somehow colors
for starters, the "test.jpg", is really a TIFF image. so it seems that the Gem is even choosing the wrong image type.
are changed, the width become half and a picture itself is doubled. This is what I meant changing "color space" and "resolution".
looks like a bug.
Is this not happening on your OSX?
my OSX is called linux.
I am using GEM: ver: 0.92.3.
which image-writing backends are installed (Gem should printout something like "Image saving support: QuickTime")
The printout should be come out on Pd window? There is no printout when saving a frame of pix_buffer. How can I get it?
installing a recent version of Gem. the last stable version of Gem is 0.93.3, and since Gem has a slow release cycle, this means that 0.92.3 is really old.
fgmadr IOhannes
Hi IOhanness,
Thanks for the advice.
the last stable version of Gem is 0.93.3, and since Gem has a slow release cycle, this means that 0.92.3 is really old.
I updated and installed to GEM 0.93.3 for OSX. Then tried to save YUV data in [pix_buffer] with the same patch, the result was same. This time I could get the message of saving jpeg file.
using YUV Image saving support: QT
I also got a message of [pix_video] starting.
[pix_video]: backend #0='Darwin' : darwin dv iidc analog
Does it help?
for starters, the "test.jpg", is really a TIFF image. so it seems that the Gem is even choosing the wrong image type.
...
looks like a bug.
I see. Hope it would to be fixed.
Best,
Sei
-- __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ Seiichiro Matsumura
sei@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
2012/7/14 IOhannes m zmölnig zmoelnig@iem.at:
On 07/10/2012 02:03 PM, Seiichiro MATSUMURA wrote:
The attached picture named "test.jpg" is what I saved using the attached patch. The original pict in a buffer is like right hand side of another attached picture "screenshot_gemwin.jpg". Somehow colors
for starters, the "test.jpg", is really a TIFF image. so it seems that the Gem is even choosing the wrong image type.
are changed, the width become half and a picture itself is doubled. This is what I meant changing "color space" and "resolution".
looks like a bug.
Is this not happening on your OSX?
my OSX is called linux.
I am using GEM: ver: 0.92.3.
which image-writing backends are installed (Gem should printout something like "Image saving support: QuickTime")
The printout should be come out on Pd window? There is no printout when saving a frame of pix_buffer. How can I get it?
installing a recent version of Gem. the last stable version of Gem is 0.93.3, and since Gem has a slow release cycle, this means that 0.92.3 is really old.
fgmadr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
-
Antonio Roberts -
Charles Goyard -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Seiichiro MATSUMURA