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