Hey all,
I've tested this with a few different versions of Gem on my debian machines. All are etch with nvidia drivers from the repos.
I've attached the patch I'm using to test, remember to change the file path!
Anyone else running a debian etch machine and pix_write does work?
What's happening is files are created, at the right size, but always 100% black. Another oddness is that the first file created is named ".tif" even though "file" says it is a jpg. Subsequent files are .jpg as expected.
So any ideas?
Thanks, B.
#N canvas 702 383 534 418 10; #X obj 52 363 pix_write; #X msg 43 38 dimen 640 480 , create , 1; #X msg 56 62 0 , destroy; #X obj 283 107 square 2; #X msg 49 129 color 1 0 0; #X obj 68 332 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 39 163 dimen 1280 960 , offset 0 0 , border 0 , create , 1; #X obj 43 89 gemwin 30; #X msg 57 284 file /home/bbogart/Projects/iat-svn/bbogart/soos/trunk/test-captures/mountains/cap 0; #X obj 25 225 gemhead 20; #X obj 283 43 gemhead 10; #X obj 148 212 netreceive 8000; #X obj 59 263 loadbang; #X obj 151 242 route bang; #X connect 1 0 7 0; #X connect 2 0 7 0; #X connect 4 0 7 0; #X connect 5 0 0 0; #X connect 6 0 7 0; #X connect 8 0 0 0; #X connect 9 0 0 0; #X connect 10 0 3 0; #X connect 11 0 13 0; #X connect 12 0 8 0; #X connect 12 0 1 0; #X connect 13 0 0 0;
hi
B. Bogart wrote:
Hey all,
I've tested this with a few different versions of Gem on my debian machines. All are etch with nvidia drivers from the repos.
I've attached the patch I'm using to test, remember to change the file path!
a good standard path is "/tmp" :-)
Anyone else running a debian etch machine and pix_write does work?
What's happening is files are created, at the right size, but always 100% black.
true, you discovered a bug. the workaround is to explicitely send the [pix_write] object the dimensions of the to-be-captured screen.
[loadbang] | [640 480( | | | [pix_write] |
Another oddness is that the first file created is named ".tif" even though "file" says it is a jpg. Subsequent files are .jpg as expected.
i cannot reproduce this. in your patch you set the type to "0" which is tiff - and tif it produces. when i set the type to "1" i get jpegs throughout.
mfga,sdr IOhannes
Wow, its even more strange than I thought.
Ok, so a good reason why *not* to change the path, is that the PATH is the source of the BUG!!!! (yes really!)
With the path included in the file I always get the same behaviour, black images of the right size. Even if I send "640 480" to the correct inlet the behaviour is the same.
So I tried changing the path/filename, and BOOM everything works again.
/home/bbogart/Projects/iat-svn/bbogart/soos/trunk/test-captures/mountains/cap
will not work (I did not try making a fake directory named like this for testing, but I suggest you give it a try to see if you get the same behaviour.)
BUT this path/filename DOES work:
/home/bbogart/Projects/iat-svn/bbogart/soos/trunk/test-captures/cap
Interesting eh?
Also this is the source of the extension bug, If I use this message:
file /home/bbogart/Projects/iat-svn/bbogart/soos/trunk/test-captures/mountains/cap 0
I get a bunch of black JPEGs! where 0 is named .tif.
If I use this (the same directory called from a relative path:
file test-captures/mountains/cap 0
I get a bunch of properly labelled TIFs not JPEGs.
I've pasted this email in the tracker for reference.
I guess the message/symbol is too long and causing problems?? I suggest trying to write to a file in a directory with 10 slashes, that should cover the bases!
Thanks Johannes,
B. Bogart
IOhannes m zmoelnig wrote:
hi
B. Bogart wrote:
Hey all,
I've tested this with a few different versions of Gem on my debian machines. All are etch with nvidia drivers from the repos.
I've attached the patch I'm using to test, remember to change the file path!
a good standard path is "/tmp" :-)
Anyone else running a debian etch machine and pix_write does work?
What's happening is files are created, at the right size, but always 100% black.
true, you discovered a bug. the workaround is to explicitely send the [pix_write] object the dimensions of the to-be-captured screen.
[loadbang]
| [640 480( | | | [pix_write] |
Another oddness is that the first file created is named ".tif" even though "file" says it is a jpg. Subsequent files are .jpg as expected.
i cannot reproduce this. in your patch you set the type to "0" which is tiff - and tif it produces. when i set the type to "1" i get jpegs throughout.
mfga,sdr IOhannes
B. Bogart wrote:
I guess the message/symbol is too long and causing problems?? I suggest trying to write to a file in a directory with 10 slashes, that should cover the bases!
just try to create a filename with >80 characters....
should be fixed in CVS now (though the maxlength is still hardcoded; this time to MAXPDSTRING, where probably other things will start falling apart too...)
fg.asdrm, IOhannes
Thanks Johannes,
B. Bogart
B. Bogart a écrit :
Hey all,
I've tested this with a few different versions of Gem on my debian machines. All are etch with nvidia drivers from the repos.
I've attached the patch I'm using to test, remember to change the file path!
Anyone else running a debian etch machine and pix_write does work?
What's happening is files are created, at the right size, but always 100% black. Another oddness is that the first file created is named ".tif" even though "file" says it is a jpg. Subsequent files are .jpg as expected.
i also noticed once something like this some time ago, but i was not able to reproduce it. what i remember is that this problem appear with very long file name, but i may be wrong.
cyrille
So any ideas?
Thanks, B.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev