Hi,
The attached patch works as expected in Linux, but in Mac OS the rectangle with the texture generated by pix_movement is not transparent. It is a black-and-white opaque image.
[pix_movement] SEEMS to be working as expected and generating the correct alpha channel (judging from the values I got with a [pix_blob] in mode "4"), so I think it is [alpha] that is not actually enabling alpha.
I have Linux and don't have a Mac, and when I observed the issue I couldn't take the time to do the obvious tests (such as trying with a solid color with alpha and no texture at all, and trying pix_image with a png image with alpha channel).
Can anybody confirm this?
I also tried sending [alpha] a "1" on the left inlet (not necessary in linux), just in case alpha was disabled by default in MacOS but that didn't help.
Is there some extra thing I have to do in order to have alpha work in Mac OS?
I am using GEM 0.92.3 in Linux and I think the same in Mac (the one bundled in the latest Pd Extended).
Thanks in advance m.
Ohhh,
I think I've realised what my problem is, not with [alpha] at all.
I think the colorspace being used by default happens to be RGBA on my linux PC and YUV on Mac OS.
So a [pix_rgba] should solve my problem and elminate all differences.
Just out of curiosity, who is responsible for determining the color space used by default?
thanks m.
On 02/25/2011 12:17 AM, Matteo Sisti Sette wrote:
Hi,
The attached patch works as expected in Linux, but in Mac OS the rectangle with the texture generated by pix_movement is not transparent. It is a black-and-white opaque image.
[pix_movement] SEEMS to be working as expected and generating the correct alpha channel (judging from the values I got with a [pix_blob] in mode "4"), so I think it is [alpha] that is not actually enabling alpha.
I have Linux and don't have a Mac, and when I observed the issue I couldn't take the time to do the obvious tests (such as trying with a solid color with alpha and no texture at all, and trying pix_image with a png image with alpha channel).
Can anybody confirm this?
I also tried sending [alpha] a "1" on the left inlet (not necessary in linux), just in case alpha was disabled by default in MacOS but that didn't help.
Is there some extra thing I have to do in order to have alpha work in Mac OS?
I am using GEM 0.92.3 in Linux and I think the same in Mac (the one bundled in the latest Pd Extended).
Thanks in advance m.
On Thu, Feb 24, 2011 at 7:05 PM, Matteo Sisti Sette < matteosistisette@gmail.com> wrote:
Just out of curiosity, who is responsible for determining the color space used by default?
Myself and Jamie Tittle. The speed difference between YUV and RGBA is massive since all video is the former natively.
On 02/25/2011 02:41 AM, chris clepper wrote:
Just out of curiosity, who is responsible for determining the color space used by default?Myself and Jamie Tittle. The speed difference between YUV and RGBA is massive since all video is the former natively.
:D Hahahha
I meant which object. I mean, if it is pix_video who "decides" which color space to use (as opposed to the OS or somebody else outside GEM) then I guess the same color space could be used by default in all platforms.
Or is there a particular reason to prefer rgba by default on linux?
I think all unnecessary differences among platform should be avoided even in default values (otherwise one is obliged to set everything explicitely)...
On 02/25/2011 03:15 AM, Matteo Sisti Sette wrote:
On 02/25/2011 02:41 AM, chris clepper wrote:
Just out of curiosity, who is responsible for determining the color space used by default?Myself and Jamie Tittle. The speed difference between YUV and RGBA is massive since all video is the former natively.
:D Hahahha
I meant which object. I mean, if it is pix_video who "decides" which color space to use (as opposed to the OS or somebody else outside GEM) then I guess the same color space could be used by default in all platforms.
the source is responsible for choosing the default colorspace, in your case [pix_video]
Or is there a particular reason to prefer rgba by default on linux?
there are several:
- legacy
- unlike on OSX, there is no direct support for YUV-textures in openGL
on linux & w32; which means that the conversion has to be done on the CPU at some stage anyhow
- pix-fx plugins (FreeFrame, frei0r) usually expect 32bit pixels, which
makes the YUV-speedup void if you want to use these.
I think all unnecessary differences among platform should be avoided even in default values (otherwise one is obliged to set everything explicitely)...
in many cases (e.g. when not using alpha) you won't (or rather: should not) notice a difference.
using [pix_rgba] with pixes that are already in RGBA space, should have virtually no (well, only a very small) overhead.
i suggest making things explicit whenever you need them
gfmasdr IOhannes
On Fri, 25 Feb 2011, Matteo Sisti Sette wrote:
On 02/25/2011 02:41 AM, chris clepper wrote:
I meant which object. I mean, if it is pix_video who "decides" which color space to use (as opposed to the OS or somebody else outside GEM) then I guess the same color space could be used by default in all platforms. Or is there a particular reason to prefer rgba by default on linux?
Maybe it's a matter of making OSX look more efficient than Linux ;)
In fact, the YUV-422 format used by GEM has only half the content that RGBA has. This is both because YUV-422 doesn't have an alpha, and because YUV-422 uses half-resolution in two of its channels : 1+½+½=2, whereas 1+1+1+1=4. Naturally, when there's only half the amount of data, there's a lot less work to do.
But really, when I use GEM on Linux, I often have to use [pix_rgba], because GEM produces YUV pixels. I think it was in [pix_video]. It depends on the camera.
I think all unnecessary differences among platform should be avoided even in default values (otherwise one is obliged to set everything explicitely)...
This is a topic that comes back often for GridFlow...
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
chris clepper -
IOhannes zmölnig -
Mathieu Bouchard -
Matteo Sisti Sette