Re: [PD] Reading a specific image from [pix_buffer] and saving it using [pix_write]
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 s...@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ 2012/7/14 IOhannes m zmölnig : > 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 -- <>___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Reading a specific image from [pix_buffer] and saving it using [pix_write]
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
Re: [PD] Reading a specific image from [pix_buffer] and saving it using [pix_write]
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 : > 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 -- -- __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ Seiichiro Matsumura s...@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Reading a specific image from [pix_buffer] and saving it using [pix_write]
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
Re: [PD] Reading a specific image from [pix_buffer] and saving it using [pix_write]
-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- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Reading a specific image from [pix_buffer] and saving it using [pix_write]
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
s...@low-tech-ism.com
http://low-tech-ism.com/
__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
2012/3/22 Antonio Roberts :
> 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 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-
>>
>
>
>
> --
>
> anto...@hellocatfood.com
> http://www.hellocatfood.com
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
--
--
__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
Seiichiro Matsumura
s...@low-tech-ism.com
http://low-tech-ism.com/
__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
pixbuffer_savetest.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Reading a specific image from [pix_buffer] and saving it using [pix_write]
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 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-
>
--
anto...@hellocatfood.com
http://www.hellocatfood.com
#N canvas 409 255 578 472 10;
#X declare -lib gridflow;
#X obj 32 316 pix_buffer_write store;
#X obj 462 302 pix_buffer_read store;
#X obj 32 185 pix_video;
#X obj 138 -84 gemwin;
#X obj 32 159 gemhead;
#X obj 462 137 gemhead;
#X obj 36 -16 bng 40 250 50 0 empty empty empty 17 7 0 10 -258113 -1
-1;
#X obj 36 55 f;
#X obj 67 55 + 1;
#X obj 585 207 f;
#X obj 615 207 + 1;
#X obj 462 162 t a b;
#X obj 137 -17 bng 15 250 50 0 empty empty empty 17 7 0 10 -1 -262144
-1;
#X text 158 -18 Reset;
#X obj 36 75 s frameCount;
#X obj 161 296 r frameCount;
#X obj 600 232 r frameCount;
#X obj 585 282 % 0;
#N canvas 67 95 450 300 reset 0;
#X obj 38 94 s frameCount;
#X msg 38 43 0;
#X obj 38 66 t f f;
#X obj 38 14 inlet;
#X obj 91 66 outlet;
#X obj 90 13 loadbang;
#X connect 1 0 2 0;
#X connect 2 0 0 0;
#X connect 2 1 4 0;
#X connect 3 0 1 0;
#X connect 5 0 1 0;
#X restore 137 3 pd reset;
#X text 83 -18 Record;
#X obj 633 131 hsl 80 20 10 0 0 0 empty empty empty -2 -8 0 10 -257985
-1 -1 0 1;
#X text 626 109 Playback speed;
#N canvas 391 410 450 300 speed 0;
#X obj 107 86 inlet;
#X obj 106 120 f;
#X obj 136 120 + 1;
#X obj 106 165 % 4;
#X obj 107 228 outlet;
#X obj 106 189 sel 0;
#X obj 194 117 inlet;
#X obj 194 149 int;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 1 0 3 0;
#X connect 2 0 1 1;
#X connect 3 0 5 0;
#X connect 5 0 4 0;
#X connect 6 0 7 0;
#X connect 7 0 3 1;
#X restore 585 179 pd speed;
#X obj 138 -144 loadbang;
#X msg 92 165 device /dev/video1;
#X obj 462 332 pix_texture;
#X obj 138 -64 import gridflow;
#X obj 32 386 #from_pix \, colorspace rgb;
#X obj 32 427 #out window \, title preview;
#X obj 32 407 #downscale_by 2;
#X msg 138 -124 create \, 1;
#X msg 138 -104 0 \, destroy;
#X obj 462 352 rectangle 4 3;
#X text 37 361 gridflow used for preview;
#X obj 293 176 bng 15 250 50 0 empty empty empty 17 7 0 10 -258113
-1 -1;
#X text 315 174 save images;
#X obj 248 316 pix_buffer store 96;
#X obj 293 196 tof/folderpanel;
#X obj 248 276 pack f s;
#X msg 248 296 save \$2/stop_motion_%02d\$1.jpg \$1;
#X obj 248 216 r frameCount;
#X obj 248 256 i;
#X obj 248 236 - 0.4;
#X floatatom 128 53 5 0 0 0 - - -;
#X obj 600 257 + 1;
#X obj 32 295 pix_flip;
#X msg 91 207 horizontal;
#X msg 91 227 vertical;
#X msg 91 247 none;
#X msg 91 267 both;
#X text 312 250 <- workaround;
#X connect 0 0 27 0;
#X connect 1 0 25 0;
#X connect 2 0 45 0;
#X connect 4 0 2 0;
#X connect 5 0 11 0;
#X connect 6 0 7 0;
#X connect 7 0 8 0;
#X connect 7 0 14 0;
#X connect 7 0 43 0;
#X connect 8 0 7 1;
#X connect 9 0 10 0;
#X connect 9 0 17 0;
#X connect 10 0 9 1;
#X connect 11 0 1 0;
#X connect 11 1 22 0;
#X connect 12 0 18 0;
#X connect 15 0 0 1;
#X connect 16 0 44 0;
#X connect 17 0 1 1;
#X connect 18 0 7 0;
#X connect 20 0 22 1;
#X connect 22 0 9 0;
#X connect 23 0 30 0;
#X connect 24 0 2 0;
#X connect 25 0 32 0;
#X connect 27 0 29 0;
#X connect 29 0 28 0;
#X connect 30 0 3 0;
#X connect 31 0 3 0;
#X connect 34 0 37 0;
#X connect 37 0 38 1;
#X connect 38 0 39
Re: [PD] Reading a specific image from [pix_buffer] and saving it using [pix_write]
-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-
smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
[PD] Reading a specific image from [pix_buffer] and saving it using [pix_write]
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 -- anto...@hellocatfood.com http://www.hellocatfood.com #N canvas 396 106 578 472 10; #X declare -lib gridflow; #X obj 32 236 pix_buffer_write store; #X obj 452 302 pix_buffer_read store; #X obj 32 185 pix_video; #X obj 258 56 gemwin; #X obj 32 159 gemhead; #X obj 452 137 gemhead; #X obj 36 14 bng 40 250 50 0 empty empty empty 17 7 0 10 -257985 -1 -1; #X obj 36 85 f; #X obj 67 85 + 1; #X obj 575 207 f; #X obj 600 207 + 1; #X obj 452 162 t a b; #X obj 590 257 + 1; #X obj 137 13 bng 15 250 50 0 empty empty empty 17 7 0 10 -1 -262144 -1; #X text 158 12 Reset; #X obj 36 112 s frameCount; #X obj 161 211 r frameCount; #X obj 590 232 r frameCount; #X obj 575 282 % 0; #N canvas 67 83 450 300 reset 0; #X obj 38 94 s frameCount; #X msg 38 43 0; #X obj 38 66 t f f; #X obj 38 14 inlet; #X obj 91 66 outlet; #X obj 90 13 loadbang; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 2 1 4 0; #X connect 3 0 1 0; #X connect 5 0 1 0; #X restore 137 37 pd reset; #X text 83 12 Record; #X obj 623 131 hsl 80 15 10 0 0 0 empty empty empty -2 -8 0 10 -257985 -1 -1 0 1; #X text 616 109 Playback speed; #N canvas 391 410 450 300 speed 0; #X obj 107 86 inlet; #X obj 106 120 f; #X obj 136 120 + 1; #X obj 106 165 % 4; #X obj 107 228 outlet; #X obj 106 189 sel 0; #X obj 194 117 inlet; #X obj 194 149 int; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 0 3 0; #X connect 2 0 1 1; #X connect 3 0 5 0; #X connect 5 0 4 0; #X connect 6 0 7 0; #X connect 7 0 3 1; #X restore 575 179 pd speed; #X obj 258 -4 loadbang; #X msg 92 165 device /dev/video1; #X obj 258 96 pix_buffer store 96; #X obj 452 322 pix_texture; #X obj 258 76 import gridflow; #X obj 32 306 #from_pix \, colorspace rgb; #X obj 32 347 #out window \, title preview; #X obj 32 327 #downscale_by 2; #X msg 258 16 create \, 1; #X msg 258 36 0 \, destroy; #X obj 452 342 rectangle 4 3; #X obj 262 317 pix_write; #X obj 311 245 tof/folderpanel; #X obj 262 202 gemhead 96; #X msg 311 265 file \$1/stop_motion_%09d 15; #X obj 311 225 bng 15 250 50 0 empty empty empty 17 7 0 10 -258113 -1 -1; #X obj 262 297 bang; #X text 37 281 gridflow used for preview; #X text 333 203 directory to; #X text 333 223 save images; #X connect 0 0 29 0; #X connect 1 0 27 0; #X connect 2 0 0 0; #X connect 4 0 2 0; #X connect 5 0 11 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 7 0 15 0; #X connect 7 0 40 0; #X connect 8 0 7 1; #X connect 9 0 10 0; #X connect 9 0 18 0; #X connect 10 0 9 1; #X connect 11 0 1 0; #X connect 11 1 23 0; #X connect 12 0 18 1; #X connect 13 0 19 0; #X connect 16 0 0 1; #X connect 17 0 12 0; #X connect 18 0 1 1; #X connect 19 0 7 0; #X connect 21 0 23 1; #X connect 23 0 9 0; #X connect 24 0 32 0; #X connect 25 0 2 0; #X connect 27 0 34 0; #X connect 29 0 31 0; #X connect 31 0 30 0; #X connect 32 0 3 0; #X connect 33 0 3 0; #X connect 36 0 38 0; #X connect 37 0 35 0; #X connect 38 0 35 0; #X connect 39 0 36 0; #X connect 40 0 35 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
