[GEM-dev] 0.90 and pix_video under Linux

[Mirko Petrovich]

Hi IOhannes,

Thanks for your reply, but I'm not having any luck.

IOhannes m zmoelnig wrote:

>
> > Alpha blending doesn't work with pix_video using [alpha] and
> > [colorRGB]in the renderchain (it worked in 0.888-cvs).Should I use
> > [pix_alpha] instead ?
>
> hmm. i just tried and it certainly works for me.
> does it produce any result (e.g.: image dimming but no transparency) ? 

Nothing but black.

>
> do you - by chance - have the render order mixed up somehow ? 

there's only one gemhead without arguments.
I've tried sending messages like function or auto, but only sending a 
zero to the first inlet of alpha i get the image.

>
>
> using [pix_alpha] is basically a not so good idea (even though you 
> might get the same results) because the transparency is done on the 
> CPU instead of the GPU.
>
> > Mixing pix_video with pix_buffer_read flips the resulting image. 
> Setting
> > m_image.image.upsidedown=false in videoV4L.cpp and using [pix_video]
> > with [pix_flip] solves this problem (ugly workaround).
> indeed ugly.
> we have done some performances with [pix_buffer]+[pix_video] (but the 
> only image-source has been the [pix_video], so all the images had a 
> consistent upside-down-orientation) and it worked perfectly.
> i would suggest using [pix_*] objects as little as possible, because 
> all the calcs are done on the CPU instead of the GPU (which is 
> optimized) - [note: chris says something else in his last emails about 
> SIMD: he is right, but a lot of pix_objects are not SIMD-optimized yet 
> (to be honest: on win/lin almost no code is MMX/SSE2-enabled)
> so using [rotate 0 1 0 180] is basically a better idea than using 
> [pix_flip].
> but this will not work, when mixing 2 images with different orientation.
> i guess you are using another source for feeding the [pix_buffer].
> if you can fill the buffer off-line (on start-up) try using the 
> [pix_flip] in there, so that heavy calcs (ok: the calcs are not that 
> heavy) are not done during performance. 

My idea was filling buffers on the fly, and selecting from differents 
sources (pix_video, pix_film, pix-mixers), so I guess I will have to 
send a flag to activate pix_flip depending on the source.

>
>
> the upsidedown-flag is there for good reasons:
> the problem is, that certain libraries (eg: vide4linux) return the 
> image in a non-openGL-orientation (the problem is on the openGL-side 
> rather than on the libs-side);
> i can think of 2 ways to fix this BUG:
> a) convert all incoming images to the internal orientation (like a 
> built-in [pix_flip]) -> bad, because a lot of unneeded operations have 
> to be done
> b) rewrite the pix-mixers so they handle de-orientated images correctly 

I don't understand this solution, do you mean rewriting in cpp or just 
the patches ?

>
>
> > Also I'm looking for a way too zoom a pix but pix_zoom never worked 
> for me.
> > I'm using RH8 2.4.21 and TNT2 with nvidia drivers.
> indeed [pix_zoom] is not really working, and i think it needs a 
> complete rewrite.
> you can use [pix_coordinates] to stretch a certain texture. 

It doesn't work because I need to zoom one source before mixing.

>
> and you can use [pix_crop] to get a sub-image. 

If I crop only one source of the mix, pix_mixers complains about 
differents dimensions, and pix_resize it's too heavy and only resizes in 
power of two.

>
> and (if you want to zoom in a videoIN-image) you could do some tricks 
> with offset/dimen-messages to the [pix_video]-object 


I will try this, at least for video-IN.

Thanks

-- 
Mirko Petrovich
Santiago de Chile