[PD] [announce][Gem] well, here it is....

[IOhannes m zmoelnig]

Dave Phillips wrote:
> IOhannes m zmoelnig wrote:
> 
> 
>>you mean, using the "pix_rgba" object (which might be (pre-alpha)
>>crashy)) it slows down ?
> Yes, the frame rate is cut by what appears to be about half, quite an
> obvious slow-down.

if you are referring to the example-patch "film.pd", the frame-rate 
drops not because of the pix_rgba object, but because of the pix_convolve.
if pix_rgba is turned off, pix_convolve will get RGB-data but knows not 
what to do with it. therefore there is now (time-consuming) convolution 
(and you see masses of errors on the shell)
when switching pix_rgba on, the pix_convolve will now start to convolve 
the (converted) RGBA-images.
Since the default convolution-kernel is something like
0 0 0
0 1 0
0 0 0
, the image still looks "normal" (even though the (redundant) 
convolution is done !!)

i didn't notice any slowdown, due to the pix_rgba itself

>>most of the decoders only return RGB instead of RGBA, but all of them
>>are able to decode to RGB. however, this depends on the used codec, so
>>it might be up to you to use a codec that supports RGBA or use pix_rgba
>>to make a "manual" conversion.
>
> Do you mean it's possible to convert the format via Pd ? That would be
> sweet, but I suspect you mean something else (?).
it is done via the pix_rgba object


>  
> 
>>try loading the file after turning on the rendering
>>
> 
> It doesn't seem to make a difference. I can load the MOV and MPG videos
> just fine, but I get no video display. The rendering seems to be working
> correctly (it bangs at the end of the numbered frames), there's just no
> video display. I've attached a simplified patch, perhaps you can see
> where I'm doing something wrong. I'll gladly send the example movies too
> if you want to try them.

as i hinted in a previous mail, this might be due to the image-size.
if your image-dimensions are not powers of 2, you will have to 
pix_texture2 instead of pix_texture



>>...pix_film and pix_movie use the very same
>>procedure-calls (eg: for opening files).
>>the only difference between these two is, that pix_movie immediately
>>loads the frame as a texture onto the gfx-card, whereas pix_film does not.
>>however, the "brownish look" of your window comes from using the wrong
>>colour-space (i guess: RGB instead of RGBA...)
>>i'll check this.
>>
> 
> Cool, just let me know when you need some testing done. 

here we go: 
ftp://iem.kug.ac.at/pd/Externals/GEM/LINUX/gem-linux-0.87_test2.tgz

fixed: pix_film
fixed: pix_fx (parent class for fx, like pix_rgba)
fixed: model/glm thanks to guenter
not really fixed, but more likely to work: configure
not fixed: pix_movie colour-space problems (i do not encounter this 
problem here)


mfg.c.asdr
IOhannes