[GEM-dev] pix_write broken?
B. Bogart
ben at ekran.org
Tue Jan 22 19:06:22 CET 2008
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
>
More information about the GEM-dev
mailing list