Hi all, I'm enjoying gem 0.90 but I'm having some problems with pix_video under Linux. 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 ? 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). 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.
Thanks for any advice and great work !!
Mirko Petrovich Santiago de Chile
Mirko Petrovich wrote:
Hi all, I'm enjoying gem 0.90 but I'm having some problems with pix_video under Linux. 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) ? do you - by chance - have the render order mixed up somehow ?
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.
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
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. and you can use [pix_crop] to get a sub-image. and (if you want to zoom in a videoIN-image) you could do some tricks with offset/dimen-messages to the [pix_video]-object
mfg.a.rd IOhannes
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
I discovered that if I transform [pix_video] with [pix_grey] , alpha-blending works. [pix_rgba] doesn't.
Mirko Petrovich wrote:
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.
Thanks again
Mirko Petrovich wrote:
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.
probably your [color]/[colorRGB] is set to black ? (or the alpha-channel is 0 ??) thinking of this, it might be, that the video4linux-driver is able to produce RGBA-images but unfortunately sets the alpha-channel of each pixel to 0. in this case, you will have to raise it manually.
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.
probably yes
I don't understand this solution, do you mean rewriting in cpp or just the patches ?
unfortunately C++
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.
but again you will get images of different dimensions.
if the whole thing is just about fading several streams, use openGL-alpha blending instead of [pix_mix], so you don't have to care about dimensions at all (so the only remaining issue would be, setting the alpha-value of the [pix_video] to a decent value)
mfg.ads.ca IOhannes
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.
probably your [color]/[colorRGB] is set to black ? (or the alpha-channel is 0 ??) thinking of this, it might be, that the video4linux-driver is able to produce RGBA-images but unfortunately sets the alpha-channel of each pixel to 0. in this case, you will have to raise it manually.
I checked this, and it's not the problem , the strange thing is that alpha works in pix_gray and even in pix_yuv (I get a distorted image, I guess this is right).
if the whole thing is just about fading several streams, use openGL-alpha blending instead of [pix_mix], so you don't have to care about dimensions at all (so the only remaining issue would be, setting the alpha-value of the [pix_video] to a decent value)
I was calling pix-mixers (I forgot there was a pix_mix object) as a generic name, actually I'm using compose,add,subtract,diff,compare, chroma_key,mask, etc... and my idea was to fade the resulting image textured in a lot of geos (with openGL-alpha blending).
Thanks again
Mirko Petrovich wrote:
probably your [color]/[colorRGB] is set to black ? (or the alpha-channel is 0 ??) thinking of this, it might be, that the video4linux-driver is able to produce RGBA-images but unfortunately sets the alpha-channel of each pixel to 0. in this case, you will have to raise it manually.
I checked this, and it's not the problem , the strange thing is that alpha works in pix_gray and even in pix_yuv (I get a distorted image, I guess this is right).
this isn't strange as [pix_grey] and [pix_yuv] use colour-spaces that do not have an alpha-channels (so it is automatically set to 1) i still believe that the problem is, that [pix_video] returns RGBA-images with alpha=0 (you could watch this with [pix_histo] furthermore, you can send a [colorspace YUV( or [colorspace GREY( message to [pix_video], which might be faster (depending on the video-capture-device)
I was calling pix-mixers (I forgot there was a pix_mix object) as a generic name, actually I'm using compose,add,subtract,diff,compare, chroma_key,mask, etc... and my idea was to fade the resulting image textured in a lot of geos (with openGL-alpha blending).
i was just asking; could have been possible that you were only interested in simple mixing...
mfg.a.sdr IOhannes
IOhannes m zmoelnig wrote:
Mirko Petrovich wrote:
probably your [color]/[colorRGB] is set to black ? (or the alpha-channel is 0 ??) thinking of this, it might be, that the video4linux-driver is able to produce RGBA-images but unfortunately sets the alpha-channel of each pixel to 0. in this case, you will have to raise it manually.
I checked this, and it's not the problem , the strange thing is that alpha works in pix_gray and even in pix_yuv (I get a distorted image, I guess this is right).
this isn't strange as [pix_grey] and [pix_yuv] use colour-spaces that do not have an alpha-channels (so it is automatically set to 1) i still believe that the problem is, that [pix_video] returns RGBA-images with alpha=0 (you could watch this with [pix_histo] furthermore, you can send a [colorspace YUV( or [colorspace GREY( message to [pix_video], which might be faster (depending on the video-capture-device)
Yeah !! now it's working, sending |colorspace 2( to [pix_video] did the trick. Just for the record, I'm using a saa7134 capture card.
Thank you very much, I was really puzzled.
-
IOhannes m zmoelnig -
Mirko Petrovich