Hi,
I have to modify some patches made by another person.
In one of them, [pix_write] is used to save screenshots of the image being shown in the gemwin.
However, the user would like to be able to save a higher quality image, namely 2000x2000 (so it can be printed). To my knowledge (and to the knowledge of the person who made the patch), the only way to do this is to increase the resolution of the gemwin. But since the resolution of the screen cannot be increased so much, the complete image cannot be seen. The user wants to be able to still see the whole image (at its usual resolution of 480x480) while saving screenshots at a higher resolution.
So the question is: is it possible to save an image which is not the one being rendered into the gemwin? So that I can for example generate a big image, save it, reduce its size, and render the reduced image instead of the big one?
A slow-down due to great cpu consumption at the moment of "capturing" the image would be acceptable (though not desired, obviously) provided that it is limited to the moments when the image is captured.
Any idea?
P.S.: The image is being generared by "tiling" the image from a camera, i.e. repeating it: that's why it make sense to save the resulting image in a higher resolution: if the camera has for example a res of 640x480 and it is being repeated in a 5x5 grid, up to 3200x2400 resolution "makes sense" for the saved image.
Thank you very much m.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
Any idea?
ues [gemframebuffer]
fmasdr IOhannes
Thank you!
May you (or anybody) please make a simple example patch? I'm not sure how to combine gamframebuffer and pix_write so that the image saved is not the one displayed
Thanks again m.
2009/11/16 IOhannes m zmölnig zmoelnig@iem.at:
ues [gemframebuffer]
fmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksBBIYACgkQkX2Xpv6ydvQdqQCgrID7mA+hgME7GMFlYpi7W3gx glwAn2U1KeE1jyIPetsT/yWXS48J7Xno =sEiU -----END PGP SIGNATURE-----
A patch from Jack...
2009/11/16 matteo sisti sette matteosistisette@gmail.com
Thank you!
May you (or anybody) please make a simple example patch? I'm not sure how to combine gamframebuffer and pix_write so that the image saved is not the one displayed
Thanks again m.
2009/11/16 IOhannes m zmölnig zmoelnig@iem.at:
ues [gemframebuffer]
fmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksBBIYACgkQkX2Xpv6ydvQdqQCgrID7mA+hgME7GMFlYpi7W3gx glwAn2U1KeE1jyIPetsT/yWXS48J7Xno =sEiU -----END PGP SIGNATURE-----
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I have done this patch. It works with a [gemwin] with [dimen 800 600( and capture a picture with dimen = 1600x1200. Hoping it helps. ++
Jack
Le lundi 16 novembre 2009 à 01:41 +0100, Matteo Sisti Sette a écrit :
Hi,
I have to modify some patches made by another person.
In one of them, [pix_write] is used to save screenshots of the image being shown in the gemwin.
However, the user would like to be able to save a higher quality image, namely 2000x2000 (so it can be printed). To my knowledge (and to the knowledge of the person who made the patch), the only way to do this is to increase the resolution of the gemwin. But since the resolution of the screen cannot be increased so much, the complete image cannot be seen. The user wants to be able to still see the whole image (at its usual resolution of 480x480) while saving screenshots at a higher resolution.
So the question is: is it possible to save an image which is not the one being rendered into the gemwin? So that I can for example generate a big image, save it, reduce its size, and render the reduced image instead of the big one?
A slow-down due to great cpu consumption at the moment of "capturing" the image would be acceptable (though not desired, obviously) provided that it is limited to the moments when the image is captured.
Any idea?
P.S.: The image is being generared by "tiling" the image from a camera, i.e. repeating it: that's why it make sense to save the resulting image in a higher resolution: if the camera has for example a res of 640x480 and it is being repeated in a 5x5 grid, up to 3200x2400 resolution "makes sense" for the saved image.
Thank you very much m.
Thank you so much Jack and Stéfan
:)
ciao m.
Jack escribió:
I have done this patch. It works with a [gemwin] with [dimen 800 600( and capture a picture with dimen = 1600x1200. Hoping it helps. ++
Jack
Le lundi 16 novembre 2009 à 01:41 +0100, Matteo Sisti Sette a écrit :
Hi,
I have to modify some patches made by another person.
In one of them, [pix_write] is used to save screenshots of the image being shown in the gemwin.
However, the user would like to be able to save a higher quality image, namely 2000x2000 (so it can be printed). To my knowledge (and to the knowledge of the person who made the patch), the only way to do this is to increase the resolution of the gemwin. But since the resolution of the screen cannot be increased so much, the complete image cannot be seen. The user wants to be able to still see the whole image (at its usual resolution of 480x480) while saving screenshots at a higher resolution.
So the question is: is it possible to save an image which is not the one being rendered into the gemwin? So that I can for example generate a big image, save it, reduce its size, and render the reduced image instead of the big one?
A slow-down due to great cpu consumption at the moment of "capturing" the image would be acceptable (though not desired, obviously) provided that it is limited to the moments when the image is captured.
Any idea?
P.S.: The image is being generared by "tiling" the image from a camera, i.e. repeating it: that's why it make sense to save the resulting image in a higher resolution: if the camera has for example a res of 640x480 and it is being repeated in a 5x5 grid, up to 3200x2400 resolution "makes sense" for the saved image.
Thank you very much m.
This is a multi-part message in MIME format. --------------080002020704010006050600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jack wrote:
I have done this patch. It works with a [gemwin] with [dimen 800 600( and capture a picture wit=
h
dimen =3D 1600x1200. Hoping it helps. ++
and another alternative, based on jacks example. no real need to segment the image.
i also suggest starting to use [pix_writer] instead of [pix_write] (what names!), which does not have the grabbing code built in. eventually [pix_write] will vanish. (it can easily be built with [pix_snap] and [pix_writer].)
mfasdr IOhannes
--------------080002020704010006050600 Content-Type: text/x-puredata; name="captureFB.pd" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="captureFB.pd"
#N canvas 180 0 590 585 10; #X obj -189 148 gemhead; #X obj -189 185 gemframebuffer; #X obj 129 -10 s gemchain; #X obj -189 211 translateXYZ 0 0 -4; #X msg -176 5 destroy; #X obj -107 121 loadbang; #X obj -190 287 r gemchain; #X obj -190 307 separator; #X obj -190 367 cube 0.1; #X obj -190 347 rotateXYZ 0 45 0; #X obj -190 327 translateXYZ -3 -1 0; #X obj -50 287 r gemchain; #X obj -50 307 separator; #X obj -50 327 translateXYZ 2 2 0; #X obj -50 347 scaleXYZ 2 1 1; #X obj -50 367 sphere 0.1 20; #X msg -107 148 dimen 1600 1200; #X obj 279 404 gemhead 51; #X obj 80 287 r gemchain; #X obj 80 307 separator; #X obj 80 347 pix_video; #X obj 80 367 pix_texture; #X obj 80 387 rectangle 4 3; #X obj 80 327 translateXYZ 0 0 -1; #X obj 279 427 pix_texture; #X obj -189 38 gemwin; #X msg -189 -25 dimen 800 600 , create , 1; #X obj -50 407 r gemchain; #X obj -50 427 separator; #X obj -138 399 loadbang; #X msg -138 423 draw line; #X text -11 -27 <- 1; #X obj -50 447 sphere 5 20; #X obj 86 -11 t a a; #X obj 86 135 pix_snap 0 0 1600 1200; #X obj 86 45 spigot 0; #X obj 131 23 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 86 69 t a b; #X obj 86 91 t b a; #X obj 86 113 t a; #X obj 86 207 pix_writer; #X obj 86 159 t b a; #X obj 86 181 t a; #X obj 279 449 rectangle 4 3; #X text 242 475 just for display; #X text 168 201 the grabber code; #X text -132 264 the scene...; #X text 149 23 <- 2; #X connect 0 0 1 0; #X connect 1 0 3 0; #X connect 1 1 24 1; #X connect 3 0 33 0; #X connect 4 0 25 0; #X connect 5 0 16 0; #X connect 6 0 7 0; #X connect 7 0 10 0; #X connect 9 0 8 0; #X connect 10 0 9 0; #X connect 11 0 12 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 14 0 15 0; #X connect 16 0 1 0; #X connect 17 0 24 0; #X connect 18 0 19 0; #X connect 19 0 23 0; #X connect 20 0 21 0; #X connect 21 0 22 0; #X connect 23 0 20 0; #X connect 24 0 43 0; #X connect 26 0 25 0; #X connect 27 0 28 0; #X connect 28 0 32 0; #X connect 29 0 30 0; #X connect 30 0 32 0; #X connect 33 0 35 0; #X connect 33 1 2 0; #X connect 34 0 41 0; #X connect 35 0 37 0; #X connect 36 0 35 1; #X connect 37 0 38 0; #X connect 37 1 36 0; #X connect 38 0 39 0; #X connect 38 1 39 0; #X connect 39 0 34 0; #X connect 41 0 42 0; #X connect 41 1 42 0; #X connect 42 0 40 0;
--------------080002020704010006050600--
Yep, this is better and more simple. I wanted to use the texture in my exemple ;) ++
Jack
Le mardi 17 novembre 2009 à 08:50 +0100, IOhannes m zmölnig a écrit :
This is a multi-part message in MIME format. --------------080002020704010006050600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jack wrote:
I have done this patch. It works with a [gemwin] with [dimen 800 600( and capture a picture wit=
h
dimen =3D 1600x1200. Hoping it helps. ++
and another alternative, based on jacks example. no real need to segment the image.
i also suggest starting to use [pix_writer] instead of [pix_write] (what names!), which does not have the grabbing code built in. eventually [pix_write] will vanish. (it can easily be built with [pix_snap] and [pix_writer].)
mfasdr IOhannes
--------------080002020704010006050600 Content-Type: text/x-puredata; name="captureFB.pd" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="captureFB.pd"
#N canvas 180 0 590 585 10; #X obj -189 148 gemhead; #X obj -189 185 gemframebuffer; #X obj 129 -10 s gemchain; #X obj -189 211 translateXYZ 0 0 -4; #X msg -176 5 destroy; #X obj -107 121 loadbang; #X obj -190 287 r gemchain; #X obj -190 307 separator; #X obj -190 367 cube 0.1; #X obj -190 347 rotateXYZ 0 45 0; #X obj -190 327 translateXYZ -3 -1 0; #X obj -50 287 r gemchain; #X obj -50 307 separator; #X obj -50 327 translateXYZ 2 2 0; #X obj -50 347 scaleXYZ 2 1 1; #X obj -50 367 sphere 0.1 20; #X msg -107 148 dimen 1600 1200; #X obj 279 404 gemhead 51; #X obj 80 287 r gemchain; #X obj 80 307 separator; #X obj 80 347 pix_video; #X obj 80 367 pix_texture; #X obj 80 387 rectangle 4 3; #X obj 80 327 translateXYZ 0 0 -1; #X obj 279 427 pix_texture; #X obj -189 38 gemwin; #X msg -189 -25 dimen 800 600 , create , 1; #X obj -50 407 r gemchain; #X obj -50 427 separator; #X obj -138 399 loadbang; #X msg -138 423 draw line; #X text -11 -27 <- 1; #X obj -50 447 sphere 5 20; #X obj 86 -11 t a a; #X obj 86 135 pix_snap 0 0 1600 1200; #X obj 86 45 spigot 0; #X obj 131 23 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 86 69 t a b; #X obj 86 91 t b a; #X obj 86 113 t a; #X obj 86 207 pix_writer; #X obj 86 159 t b a; #X obj 86 181 t a; #X obj 279 449 rectangle 4 3; #X text 242 475 just for display; #X text 168 201 the grabber code; #X text -132 264 the scene...; #X text 149 23 <- 2; #X connect 0 0 1 0; #X connect 1 0 3 0; #X connect 1 1 24 1; #X connect 3 0 33 0; #X connect 4 0 25 0; #X connect 5 0 16 0; #X connect 6 0 7 0; #X connect 7 0 10 0; #X connect 9 0 8 0; #X connect 10 0 9 0; #X connect 11 0 12 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 14 0 15 0; #X connect 16 0 1 0; #X connect 17 0 24 0; #X connect 18 0 19 0; #X connect 19 0 23 0; #X connect 20 0 21 0; #X connect 21 0 22 0; #X connect 23 0 20 0; #X connect 24 0 43 0; #X connect 26 0 25 0; #X connect 27 0 28 0; #X connect 28 0 32 0; #X connect 29 0 30 0; #X connect 30 0 32 0; #X connect 33 0 35 0; #X connect 33 1 2 0; #X connect 34 0 41 0; #X connect 35 0 37 0; #X connect 36 0 35 1; #X connect 37 0 38 0; #X connect 37 1 36 0; #X connect 38 0 39 0; #X connect 38 1 39 0; #X connect 39 0 34 0; #X connect 41 0 42 0; #X connect 41 1 42 0; #X connect 42 0 40 0;
--------------080002020704010006050600-- _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Jack
Sorry for the delay, I very much appreciate the patch you sent me in response to my question, but only now I've been able to look at it.
Unfortunately, it does not do what I was looking for:
- first of all, nothing is rendered on screen until the moment when you
capture a snapshot, and after capturing it, nothing is displayed again. I need to be able to always render the sceen, and save a snapshot only when a "rec" toggle is activated
- second, even if the gemwin has a size of 800x600, the scene is
rendered at 1600x1200, so I only see a small portion of the scene, that is exactly what I wanted to avoid
What I need is to have the very same image (which is an arbitrary scene composed of rectangles with live stream from the camera, however that does not matter very much) BOTH displayed at a low resolution, AND saved into images at a higher resolution, but the whole image must be displayed, not a portion of it.
The question is: is this possible at all?
Btw, the patch from Stéphan does not work either, it displays a black screen and saves invalid tiff files that photoshop cannot even read; by changing the image type to jpeg, I get black images saved.
Even looking at the patches, I don't understand well how [gemframebuffer] and [pix_write] work and how to combine them together (and with [separator] perhaps?) to get what I want......
Any further help will be greatly appreciated thanks m.
I have done this patch. It works with a [gemwin] with [dimen 800 600( and capture a picture with dimen = 1600x1200. Hoping it helps. ++
Jack
Le lundi 16 novembre 2009 à 01:41 +0100, Matteo Sisti Sette a écrit :
Hi,
I have to modify some patches made by another person.
In one of them, [pix_write] is used to save screenshots of the image being shown in the gemwin.
However, the user would like to be able to save a higher quality image, namely 2000x2000 (so it can be printed). To my knowledge (and to the knowledge of the person who made the patch), the only way to do this is to increase the resolution of the gemwin. But since the resolution of the screen cannot be increased so much, the complete image cannot be seen. The user wants to be able to still see the whole image (at its usual resolution of 480x480) while saving screenshots at a higher resolution.
So the question is: is it possible to save an image which is not the one being rendered into the gemwin? So that I can for example generate a big image, save it, reduce its size, and render the reduced image instead of the big one?
A slow-down due to great cpu consumption at the moment of "capturing" the image would be acceptable (though not desired, obviously) provided that it is limited to the moments when the image is captured.
Any idea?
P.S.: The image is being generared by "tiling" the image from a camera, i.e. repeating it: that's why it make sense to save the resulting image in a higher resolution: if the camera has for example a res of 640x480 and it is being repeated in a 5x5 grid, up to 3200x2400 resolution "makes sense" for the saved image.
Thank you very much m.
Ok, IOhannes' patch seems to be what I was looking for, however I have the following problems:
- The patch out-of-the-box saves unreadable tiffs just like Jack's
version: I guess this is a bug in [pix_writer] (and [pix_write])??
- By sending it a [file something 95( to pix_writer in order to have
jpegs saved instead of tiffs, which DOES work with [pix_write], pd crashes!!!!!
- There's no help file for [pix_writer] where I would check whether the
message syntax for setting the file tipe is different.....
Seems like I'm pretty near to the solution, can you help me with the last step?
Thanks a lot m.
Matteo Sisti Sette escribió:
Hi Jack
Sorry for the delay, I very much appreciate the patch you sent me in response to my question, but only now I've been able to look at it.
Unfortunately, it does not do what I was looking for:
- first of all, nothing is rendered on screen until the moment when you
capture a snapshot, and after capturing it, nothing is displayed again. I need to be able to always render the sceen, and save a snapshot only when a "rec" toggle is activated
- second, even if the gemwin has a size of 800x600, the scene is
rendered at 1600x1200, so I only see a small portion of the scene, that is exactly what I wanted to avoid
What I need is to have the very same image (which is an arbitrary scene composed of rectangles with live stream from the camera, however that does not matter very much) BOTH displayed at a low resolution, AND saved into images at a higher resolution, but the whole image must be displayed, not a portion of it.
The question is: is this possible at all?
Btw, the patch from Stéphan does not work either, it displays a black screen and saves invalid tiff files that photoshop cannot even read; by changing the image type to jpeg, I get black images saved.
Even looking at the patches, I don't understand well how [gemframebuffer] and [pix_write] work and how to combine them together (and with [separator] perhaps?) to get what I want......
Any further help will be greatly appreciated thanks m.
I have done this patch. It works with a [gemwin] with [dimen 800 600( and capture a picture with dimen = 1600x1200. Hoping it helps. ++
Jack
Le lundi 16 novembre 2009 à 01:41 +0100, Matteo Sisti Sette a écrit :
Hi,
I have to modify some patches made by another person.
In one of them, [pix_write] is used to save screenshots of the image being shown in the gemwin.
However, the user would like to be able to save a higher quality image, namely 2000x2000 (so it can be printed). To my knowledge (and to the knowledge of the person who made the patch), the only way to do this is to increase the resolution of the gemwin. But since the resolution of the screen cannot be increased so much, the complete image cannot be seen. The user wants to be able to still see the whole image (at its usual resolution of 480x480) while saving screenshots at a higher resolution.
So the question is: is it possible to save an image which is not the one being rendered into the gemwin? So that I can for example generate a big image, save it, reduce its size, and render the reduced image instead of the big one?
A slow-down due to great cpu consumption at the moment of "capturing" the image would be acceptable (though not desired, obviously) provided that it is limited to the moments when the image is captured.
Any idea?
P.S.: The image is being generared by "tiling" the image from a camera, i.e. repeating it: that's why it make sense to save the resulting image in a higher resolution: if the camera has for example a res of 640x480 and it is being repeated in a 5x5 grid, up to 3200x2400 resolution "makes sense" for the saved image.
Thank you very much m.
Matteo Sisti Sette wrote:
Ok, IOhannes' patch seems to be what I was looking for, however I have the following problems:
- The patch out-of-the-box saves unreadable tiffs just like Jack's
which OS?
version: I guess this is a bug in [pix_writer] (and [pix_write])??
might be a bug in the backend that both [pix_writer] and [pix_write] use.
- By sending it a [file something 95( to pix_writer in order to have
jpegs saved instead of tiffs, which DOES work with [pix_write], pd crashes!!!!!
- There's no help file for [pix_writer] where I would check whether the
message syntax for setting the file tipe is different.....
it's really the same object as [pix_write], just without the snap-code.
Seems like I'm pretty near to the solution, can you help me with the last step?
fmt IOhannes
IOhannes m zmoelnig escribió:
Matteo Sisti Sette wrote:
Ok, IOhannes' patch seems to be what I was looking for, however I have the following problems:
- The patch out-of-the-box saves unreadable tiffs just like Jack's
which OS?
Windows Vista :(
- By sending it a [file something 95( to pix_writer in order to have
jpegs saved instead of tiffs, which DOES work with [pix_write], pd crashes!!!!!
it's really the same object as [pix_write], just without the snap-code.
Then the strange thing is that Jack's patch with pix_write does not crash when saving jpegs (it saves black images but i guess it might be some trivial error in the patch) while your patch with pix_writer does.... How may I avoid the crash??? It does not crash when I send the [file ...( message but when I try to save the first snapshot after it.
Where can I find some documentation more detailed than the help patches in order to understand the mechanisms? I get quite lost when trying to understand how your patch (for example) works. I more or less understand the notion of gem chain, gem list, and, for example, separators, but I still get lost when [gemframebuffer] enters the scene, I don't even fully understand why it is needed at all in your patch, for example......
Thanks again and again
I modified IOhannes' patch to use pix_write instead of pix_snap+pix_write and it also crashes, so it is not a difference between pix_write and pix_writer: both crash.
I'll have a look at what's different between IOhannes' and Jack's patches that may explain why one crashes and the other does not....
Matteo Sisti Sette escribió:
IOhannes m zmoelnig escribió:
Matteo Sisti Sette wrote:
Ok, IOhannes' patch seems to be what I was looking for, however I have the following problems:
- The patch out-of-the-box saves unreadable tiffs just like Jack's
which OS?
Windows Vista :(
- By sending it a [file something 95( to pix_writer in order to have
jpegs saved instead of tiffs, which DOES work with [pix_write], pd crashes!!!!!
it's really the same object as [pix_write], just without the snap-code.
Then the strange thing is that Jack's patch with pix_write does not crash when saving jpegs (it saves black images but i guess it might be some trivial error in the patch) while your patch with pix_writer does.... How may I avoid the crash??? It does not crash when I send the [file ...( message but when I try to save the first snapshot after it.
Where can I find some documentation more detailed than the help patches in order to understand the mechanisms? I get quite lost when trying to understand how your patch (for example) works. I more or less understand the notion of gem chain, gem list, and, for example, separators, but I still get lost when [gemframebuffer] enters the scene, I don't even fully understand why it is needed at all in your patch, for example......
Thanks again and again
Can you try this patch (this is the IOhannes patch) with very small modifications. ++
Jack
Le vendredi 27 novembre 2009 à 15:46 +0100, Matteo Sisti Sette a écrit :
I modified IOhannes' patch to use pix_write instead of pix_snap+pix_write and it also crashes, so it is not a difference between pix_write and pix_writer: both crash.
I'll have a look at what's different between IOhannes' and Jack's patches that may explain why one crashes and the other does not....
Matteo Sisti Sette escribió:
IOhannes m zmoelnig escribió:
Matteo Sisti Sette wrote:
Ok, IOhannes' patch seems to be what I was looking for, however I have the following problems:
- The patch out-of-the-box saves unreadable tiffs just like Jack's
which OS?
Windows Vista :(
- By sending it a [file something 95( to pix_writer in order to have
jpegs saved instead of tiffs, which DOES work with [pix_write], pd crashes!!!!!
it's really the same object as [pix_write], just without the snap-code.
Then the strange thing is that Jack's patch with pix_write does not crash when saving jpegs (it saves black images but i guess it might be some trivial error in the patch) while your patch with pix_writer does.... How may I avoid the crash??? It does not crash when I send the [file ...( message but when I try to save the first snapshot after it.
Where can I find some documentation more detailed than the help patches in order to understand the mechanisms? I get quite lost when trying to understand how your patch (for example) works. I more or less understand the notion of gem chain, gem list, and, for example, separators, but I still get lost when [gemframebuffer] enters the scene, I don't even fully understand why it is needed at all in your patch, for example......
Thanks again and again
Jack escribió:
Can you try this patch (this is the IOhannes patch) with very small modifications.
It works fine now, even with jpeg (sending [file somefilename 95( ) As usual, tiffs are unreadable but i don't care since I want jpegs.
However I don't quite understand it: it uses pix_snap AND pix_write (without 'r'): isn't pix_write supposed to work without the need for a pix_snap?
And if I replace pix_write with pix_writer (in this last patch without any other change) it again does crash saving jpegs.....
I see you have changed the trigger order of pix_snap sending it first the bang and then the list, haven't you, but not on the pix_write...... is there a reason?
I think this solves my problem however I don't understand the whole picture
BY THE WAY one thing that I was missing in all my tests is that you have to explicitly set pix_snap 'window' (pos and size) to the size of the gemframebuffer (or gemwin); i would expect (am I the only one?) the default value to be the size of the framebuffer, but it isnt: it seems it is some fixed vaule. That should be documented. A lot of things should be documented...
++
Jack
Le vendredi 27 novembre 2009 à 15:46 +0100, Matteo Sisti Sette a écrit :
I modified IOhannes' patch to use pix_write instead of pix_snap+pix_write and it also crashes, so it is not a difference between pix_write and pix_writer: both crash.
I'll have a look at what's different between IOhannes' and Jack's patches that may explain why one crashes and the other does not....
Matteo Sisti Sette escribió:
IOhannes m zmoelnig escribió:
Matteo Sisti Sette wrote:
Ok, IOhannes' patch seems to be what I was looking for, however I have the following problems:
- The patch out-of-the-box saves unreadable tiffs just like Jack's
which OS?
Windows Vista :(
- By sending it a [file something 95( to pix_writer in order to have
jpegs saved instead of tiffs, which DOES work with [pix_write], pd crashes!!!!!
it's really the same object as [pix_write], just without the snap-code.
Then the strange thing is that Jack's patch with pix_write does not crash when saving jpegs (it saves black images but i guess it might be some trivial error in the patch) while your patch with pix_writer does.... How may I avoid the crash??? It does not crash when I send the [file ...( message but when I try to save the first snapshot after it.
Where can I find some documentation more detailed than the help patches in order to understand the mechanisms? I get quite lost when trying to understand how your patch (for example) works. I more or less understand the notion of gem chain, gem list, and, for example, separators, but I still get lost when [gemframebuffer] enters the scene, I don't even fully understand why it is needed at all in your patch, for example......
Thanks again and again
So first of all it seems that pix_write doesn't crash when saving if I set the creation arguments with the size of the pix (same as the pix_snap that precedes it). Note that pix_writer crashes anyway.
However, after minimizing the window and maximizing it again, the "wish84 application" crashed.
I attach the crashing patch, just in case anyone can find the cause of the crash.
I had been working with gem for years with a very old unofficial version (2006) which seemed the only stable one, and it never crashed, but I hadn't ever used pix_snap nor gemframebuffer nor pix_write. Now with the last version it seems you can't trust it, everything makes it crash.... I'm considering doing the whole thing in Flash, and that would be a shame....
Do you know of some relatively recent stable version? Or is it one of these three objects that is unstable?
Now I haven't changed A THING in the patch, and even after restarting GEM, it crashes just opening the patch. Can't even edit it.
It's really frustrating
Matteo Sisti Sette escribió:
So first of all it seems that pix_write doesn't crash when saving if I set the creation arguments with the size of the pix (same as the pix_snap that precedes it). Note that pix_writer crashes anyway.
However, after minimizing the window and maximizing it again, the "wish84 application" crashed.
I attach the crashing patch, just in case anyone can find the cause of the crash.
I had been working with gem for years with a very old unofficial version (2006) which seemed the only stable one, and it never crashed, but I hadn't ever used pix_snap nor gemframebuffer nor pix_write. Now with the last version it seems you can't trust it, everything makes it crash.... I'm considering doing the whole thing in Flash, and that would be a shame....
Do you know of some relatively recent stable version? Or is it one of these three objects that is unstable?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
Now I haven't changed A THING in the patch, and even after restarting GEM, it crashes just opening the patch. Can't even edit it.
you are using vista: try rebooting :-)
seriously: run Pd from the commandline (pd.com) with "-verbose -stderr" and see whether it says something meaningful. try "-noloadbang"
It's really frustrating
it's not crashing here (yet?)
fgmasdr IOhannes
IOhannes m zmölnig escribió:
you are using vista: try rebooting :-)
Indeed after rebooting it stopped crashing....
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
IOhannes m zmölnig escribió:
you are using vista: try rebooting :-)
Indeed after rebooting it stopped crashing....
it's sad when stupid jokes come true.
fgmasdr IOhannes
On Sat, 28 Nov 2009, IOhannes m zmölnig wrote:
Matteo Sisti Sette wrote:
IOhannes m zmölnig escribió:
you are using vista: try rebooting :-)
Indeed after rebooting it stopped crashing....
it's sad when stupid jokes come true.
What stupid joke? It's not stupid and it's not a joke.
I've had similar problems with Linux sometimes. They almost always were because of buggy apps that failed to free their shared memory allocations (and failed to set them on auto-free) when sending images through XSHM. I don't recall whether I had to restart X11 or restart the whole system though. Perhaps there was also a limit of SHM usage that I could have increased somewhere, but I didn't know, so I just rebooted.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mathieu Bouchard wrote:
On Sat, 28 Nov 2009, IOhannes m zmölnig wrote:
Matteo Sisti Sette wrote:
IOhannes m zmölnig escribió:
you are using vista: try rebooting :-)
Indeed after rebooting it stopped crashing....
it's sad when stupid jokes come true.
What stupid joke? It's not stupid and it's not a joke.
it was a joke and i considered it stupid.
apart from that, i expected you to reply to this email and am happy that you did.
fgmasdr IOhannes
On Sat, 28 Nov 2009, IOhannes m zmölnig wrote:
Mathieu Bouchard wrote:
What stupid joke? It's not stupid and it's not a joke.
it was a joke and i considered it stupid.
Well, we all wish we didn't have to reboot for such a thing, no matter the OS... but we shouldn't wish too hard.
apart from that, i expected you to reply to this email and am happy that you did.
why?... (i don't want to speculate about it.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Sat, 28 Nov 2009, IOhannes m zmölnig wrote:
apart from that, i expected you to reply to this email and am happy that you did.
why?... (i don't want to speculate about it.)
oh, really nothing to speculate about. when typing my comment, i just thought that matju will most likely want to comment on "joke". and probably "stupid" as well.
but this is how i remember it now and it is already becoming blurred by reality. so it might be all mixed up.
oh no
fgmds IOhannes
Now I haven't changed A THING in the patch, and even after restarting GEM, it crashes just opening the patch. Can't even edit it.
It's really frustrating
Matteo Sisti Sette escribió:
So first of all it seems that pix_write doesn't crash when saving if I set the creation arguments with the size of the pix (same as the pix_snap that precedes it). Note that pix_writer crashes anyway.
However, after minimizing the window and maximizing it again, the "wish84 application" crashed.
I attach the crashing patch, just in case anyone can find the cause of the crash.
I had been working with gem for years with a very old unofficial version (2006) which seemed the only stable one, and it never crashed, but I hadn't ever used pix_snap nor gemframebuffer nor pix_write. Now with the last version it seems you can't trust it, everything makes it crash.... I'm considering doing the whole thing in Flash, and that would be a shame....
Do you know of some relatively recent stable version? Or is it one of these three objects that is unstable?
Hi,
Leaving apart pix_write(r) bugs, leaving even apart pix_write(r) itself, given that your patch does show an image (with the camera stream), I can't understand why the attached patch does not work. I can't find one difference between this and yours.
Note that it is actually drawing a black rectangle. If I disconnect and bypass the framebuffer object and turn off the gemhead on the right, I can see the camera image, so when I connect the framebuffer I expect that image to be "captured" by the grmframebuffer; but then I don't understand why a black image, instead of the rendered image, is sent to the texture.
I have even tried to put a [separator] between the gemframebuffer and the pix_video, even if I don't think it should be necessary nor make any difference, just to make the patch more identical to yours, but it makes no difference.
I don't really see the difference between this patch and yours (a part obviously here there's no snapshot nor pix_write, but) the part that renders the camera input into a gembuffers and then shows it into a rectangle should be identical!!!!!!!!
Can you help me find the error? I'm stuck
(I tried with small negative translations in the Z axis as in your patch, which shouldn't be relevant, and no differnce)
thanks m.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
Can you help me find the error? I'm stuck
(I tried with small negative translations in the Z axis as in your patch, which shouldn't be relevant, and no differnce)
[gemwin] usually places the "camera" at "0 0 4" pointing to the origin.
this is not the case for [gemframebuffer], which will put the camera at "0 0 0" and the objects (if not translated by [translate] at "0 0 0" as well. thus you don't see anything (because the image you want to see is right at where you are). try moving the rectangle to "0 0 -4" and be happy.
fg,adr IOhannes
Yep, as mention IOhannes, put a [translateXYZ 0 0 -4] between [gemframebuffer] and [pix_video] (or after) to translate your [rectangle] because both are in the same plan (and all should work fine now) :) With [gemframebuffer], you have to forget the view of the camera (and then the view in the gemwin), they are different. I think the help patch about [gemframebuffer] is a good exemple. ++
Jack
Le jeudi 26 novembre 2009 à 20:21 +0100, IOhannes m zmölnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
Can you help me find the error? I'm stuck
(I tried with small negative translations in the Z axis as in your patch, which shouldn't be relevant, and no differnce)
[gemwin] usually places the "camera" at "0 0 4" pointing to the origin.
this is not the case for [gemframebuffer], which will put the camera at "0 0 0" and the objects (if not translated by [translate] at "0 0 0" as well. thus you don't see anything (because the image you want to see is right at where you are). try moving the rectangle to "0 0 -4" and be happy.
fg,adr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksO1UMACgkQkX2Xpv6ydvQy2wCgjehmfXuu+MGUV+qa/4tQXwOO X1IAoLBhPRhA/rIw0oZjvXrmGoNwK9v+ =sGNe -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ok thank you, I had missed the part where the view of the gemframebuffer is independent (and its default different) from that of the camera. Now everything's fine except one thing.
Now the problem that remains is that pix_writer crashes when trying to save jpegs... I guess I will have to use pix_write.
bye m.
Jack escribió:
Yep, as mention IOhannes, put a [translateXYZ 0 0 -4] between [gemframebuffer] and [pix_video] (or after) to translate your [rectangle] because both are in the same plan (and all should work fine now) :) With [gemframebuffer], you have to forget the view of the camera (and then the view in the gemwin), they are different. I think the help patch about [gemframebuffer] is a good exemple. ++
Jack
Le jeudi 26 novembre 2009 à 20:21 +0100, IOhannes m zmölnig a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
Can you help me find the error? I'm stuck
(I tried with small negative translations in the Z axis as in your patch, which shouldn't be relevant, and no differnce)
[gemwin] usually places the "camera" at "0 0 4" pointing to the origin.
this is not the case for [gemframebuffer], which will put the camera at "0 0 0" and the objects (if not translated by [translate] at "0 0 0" as well. thus you don't see anything (because the image you want to see is right at where you are). try moving the rectangle to "0 0 -4" and be happy.
fg,adr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksO1UMACgkQkX2Xpv6ydvQy2wCgjehmfXuu+MGUV+qa/4tQXwOO X1IAoLBhPRhA/rIw0oZjvXrmGoNwK9v+ =sGNe -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
No problem ;) The patch from IOhannes should work fine. ++
Jack
Le jeudi 26 novembre 2009 à 17:28 +0100, Matteo Sisti Sette a écrit :
Hi Jack
Sorry for the delay, I very much appreciate the patch you sent me in response to my question, but only now I've been able to look at it.
Unfortunately, it does not do what I was looking for:
- first of all, nothing is rendered on screen until the moment when you
capture a snapshot, and after capturing it, nothing is displayed again. I need to be able to always render the sceen, and save a snapshot only when a "rec" toggle is activated
- second, even if the gemwin has a size of 800x600, the scene is
rendered at 1600x1200, so I only see a small portion of the scene, that is exactly what I wanted to avoid
What I need is to have the very same image (which is an arbitrary scene composed of rectangles with live stream from the camera, however that does not matter very much) BOTH displayed at a low resolution, AND saved into images at a higher resolution, but the whole image must be displayed, not a portion of it.
The question is: is this possible at all?
Btw, the patch from Stéphan does not work either, it displays a black screen and saves invalid tiff files that photoshop cannot even read; by changing the image type to jpeg, I get black images saved.
Even looking at the patches, I don't understand well how [gemframebuffer] and [pix_write] work and how to combine them together (and with [separator] perhaps?) to get what I want......
Any further help will be greatly appreciated thanks m.
I have done this patch. It works with a [gemwin] with [dimen 800 600( and capture a picture with dimen = 1600x1200. Hoping it helps. ++
Jack
Le lundi 16 novembre 2009 à 01:41 +0100, Matteo Sisti Sette a écrit :
Hi,
I have to modify some patches made by another person.
In one of them, [pix_write] is used to save screenshots of the image being shown in the gemwin.
However, the user would like to be able to save a higher quality image, namely 2000x2000 (so it can be printed). To my knowledge (and to the knowledge of the person who made the patch), the only way to do this is to increase the resolution of the gemwin. But since the resolution of the screen cannot be increased so much, the complete image cannot be seen. The user wants to be able to still see the whole image (at its usual resolution of 480x480) while saving screenshots at a higher resolution.
So the question is: is it possible to save an image which is not the one being rendered into the gemwin? So that I can for example generate a big image, save it, reduce its size, and render the reduced image instead of the big one?
A slow-down due to great cpu consumption at the moment of "capturing" the image would be acceptable (though not desired, obviously) provided that it is limited to the moments when the image is captured.
Any idea?
P.S.: The image is being generared by "tiling" the image from a camera, i.e. repeating it: that's why it make sense to save the resulting image in a higher resolution: if the camera has for example a res of 640x480 and it is being repeated in a 5x5 grid, up to 3200x2400 resolution "makes sense" for the saved image.
Thank you very much m.
Hi,
I have the impression that GEM documentation is very poor. Please prove I'm wrong, that would make me very happy.
I don't understand how to use pix_snap (and I'm quite surprised to see that the help patch doesn't provide any example like most help patches do).
In my ignorance, I would expect the attached patch to "capture" a "photo" of the red sphere and this photo to appear as a texture on the rectangle in the background, as soon as you click on the "snap" message box. On the contrary, I only see a black rectangle.
What am I doing wrong?
Thanks m.
Hello,
Here the patch with a little description inside. Before to capture what you you need, you have to wait they are rendered. Add a float after [gemhead 50] as argument to force to draw the sphere and the cube first and then send a bang to [pix_snap] to capture them (with the help of [gemhead 51]). ++
Jack
Le vendredi 27 novembre 2009 à 15:24 +0100, Matteo Sisti Sette a écrit :
Hi,
I have the impression that GEM documentation is very poor. Please prove I'm wrong, that would make me very happy.
I don't understand how to use pix_snap (and I'm quite surprised to see that the help patch doesn't provide any example like most help patches do).
In my ignorance, I would expect the attached patch to "capture" a "photo" of the red sphere and this photo to appear as a texture on the rectangle in the background, as soon as you click on the "snap" message box. On the contrary, I only see a black rectangle.
What am I doing wrong?
Thanks m.
pièce jointe document texte brut (prove.pd) #N canvas 623 111 725 579 12; #X obj 508 125 pix_snap; #X obj 22 147 gemhead; #X obj 506 174 pix_texture; #X obj 314 362 rectangle 5.3333 4; #X obj 36 338 rotateXYZ 0 0 0; #X floatatom 54 304 5 0 0 0 - - -; #X floatatom 101 302 5 0 0 0 - - -; #X obj 37 453 color 1 0 0; #X obj 34 494 sphere; #X obj 429 492 gemwin; #X msg 385 434 create , 1; #X msg 484 457 destroy; #X msg 509 83 snap; #X obj 29 397 translateXYZ 0 0 -6; #X obj 302 315 translateXYZ 0 0 -8; #X obj 441 36 gemhead; #X obj 303 118 gemhead; #X obj 306 256 pix_texture; #X connect 0 0 2 0; #X connect 1 0 4 0; #X connect 2 1 17 1; #X connect 4 0 13 0; #X connect 5 0 4 1; #X connect 6 0 4 2; #X connect 7 0 8 0; #X connect 10 0 9 0; #X connect 11 0 9 0; #X connect 12 0 0 0; #X connect 13 0 7 0; #X connect 14 0 3 0; #X connect 15 0 0 0; #X connect 16 0 17 0; #X connect 17 0 14 0; _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
Tnanks, that works.
One interesting thing is that here you're sending the bang to pix_snap immediately BEFORE it receives the gemlist, while in all the previous examples by yoy, IOhannes et al. (some of which crash) the bang is sent just AFTER the gemlist. Is that relevant?
Jack escribió:
Hello,
Here the patch with a little description inside. Before to capture what you you need, you have to wait they are rendered. Add a float after [gemhead 50] as argument to force to draw the sphere and the cube first and then send a bang to [pix_snap] to capture them (with the help of [gemhead 51]). ++
Jack
Le vendredi 27 novembre 2009 à 15:24 +0100, Matteo Sisti Sette a écrit :
Hi,
I have the impression that GEM documentation is very poor. Please prove I'm wrong, that would make me very happy.
I don't understand how to use pix_snap (and I'm quite surprised to see that the help patch doesn't provide any example like most help patches do).
In my ignorance, I would expect the attached patch to "capture" a "photo" of the red sphere and this photo to appear as a texture on the rectangle in the background, as soon as you click on the "snap" message box. On the contrary, I only see a black rectangle.
What am I doing wrong?
Thanks m.
pièce jointe document texte brut (prove.pd) #N canvas 623 111 725 579 12; #X obj 508 125 pix_snap; #X obj 22 147 gemhead; #X obj 506 174 pix_texture; #X obj 314 362 rectangle 5.3333 4; #X obj 36 338 rotateXYZ 0 0 0; #X floatatom 54 304 5 0 0 0 - - -; #X floatatom 101 302 5 0 0 0 - - -; #X obj 37 453 color 1 0 0; #X obj 34 494 sphere; #X obj 429 492 gemwin; #X msg 385 434 create , 1; #X msg 484 457 destroy; #X msg 509 83 snap; #X obj 29 397 translateXYZ 0 0 -6; #X obj 302 315 translateXYZ 0 0 -8; #X obj 441 36 gemhead; #X obj 303 118 gemhead; #X obj 306 256 pix_texture; #X connect 0 0 2 0; #X connect 1 0 4 0; #X connect 2 1 17 1; #X connect 4 0 13 0; #X connect 5 0 4 1; #X connect 6 0 4 2; #X connect 7 0 8 0; #X connect 10 0 9 0; #X connect 11 0 9 0; #X connect 12 0 0 0; #X connect 13 0 7 0; #X connect 14 0 3 0; #X connect 15 0 0 0; #X connect 16 0 17 0; #X connect 17 0 14 0; _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
Hi,
I have the impression that GEM documentation is very poor. Please prove I'm wrong, that would make me very happy.
i would be more happy if you could provide better documentation.
fgamsr IOhannes
IOhannes m zmölnig escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
Hi,
I have the impression that GEM documentation is very poor. Please prove I'm wrong, that would make me very happy.
i would be more happy if you could provide better documentation.
Well I'd love to, but first I would have to learn how things work, which will take a long time. I think the normal approach is that documentation be written by those somehow involved in the development...
On Fri, 27 Nov 2009, Matteo Sisti Sette wrote:
IOhannes m zmölnig escribió:
Matteo Sisti Sette wrote:
I have the impression that GEM documentation is very poor. Please prove I'm wrong, that would make me very happy.
i would be more happy if you could provide better documentation.
Well I'd love to, but first I would have to learn how things work, which will take a long time. I think the normal approach is that documentation be written by those somehow involved in the development...
Therefore you may get involved in the development... Pd has quite a shortage of those people.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard escribió:
On Fri, 27 Nov 2009, Matteo Sisti Sette wrote:
IOhannes m zmölnig escribió:
Matteo Sisti Sette wrote:
I have the impression that GEM documentation is very poor. Please prove I'm wrong, that would make me very happy.
i would be more happy if you could provide better documentation.
Well I'd love to, but first I would have to learn how things work, which will take a long time. I think the normal approach is that documentation be written by those somehow involved in the development...
Therefore you may get involved in the development... Pd has quite a shortage of those people.
Oh, I'd really love to, but I am almost analphabet in C++
- Therefore you may learn C++
Yeah, I definitely should.
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jack -
Mathieu Bouchard -
Matteo Sisti Sette -
matteo sisti sette
-
stéfan piat