[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