as hinted in my last email, Gem seems to have different hardcoded ideas about what RGBA means (esp. on OSX)
the main confusion is about which "type" to use: GL_UNSIGNED_INT_8_8_8_8_REV vs GL_UNSIGNED_INT_8_8_8_8 the solution seems to be simple (_REV on ppc, normal on i686) but it seems to be done inconsistently in the source code, thus resulting in all the alpha problems marius has reported.
i have created a wiki-page that tries to explain the technical implementation of Gem's standard colorspaces, which can be found at http://gem.iem.at/documentation/GemWiki/ColorSpace
i have filled this page to my best knowledge, but i would be glad if somebody who knows what they are doing could have a look at it and confirm (or correct) everything (esp. those lines marked with "?")
fgmasdr IOhannes
The problem with the pix_ objects is the MMX code on is fixed to a different order than what OSX Intel uses. For some objects this makes no difference, but others require the components in a specific order. So to fix some bug complaints I swapped the byte order to match the MMX code, but this broke other things so it was switched back. Perhaps defining some MMX/SSE macros for the order would sort this out?
I don't think there are any GL alpha problems at all.
On Wed, May 28, 2008 at 11:25 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
as hinted in my last email, Gem seems to have different hardcoded ideas about what RGBA means (esp. on OSX)
the main confusion is about which "type" to use: GL_UNSIGNED_INT_8_8_8_8_REV vs GL_UNSIGNED_INT_8_8_8_8 the solution seems to be simple (_REV on ppc, normal on i686) but it seems to be done inconsistently in the source code, thus resulting in all the alpha problems marius has reported.
i have created a wiki-page that tries to explain the technical implementation of Gem's standard colorspaces, which can be found at http://gem.iem.at/documentation/GemWiki/ColorSpace
i have filled this page to my best knowledge, but i would be glad if somebody who knows what they are doing could have a look at it and confirm (or correct) everything (esp. those lines marked with "?")
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
chris clepper wrote:
The problem with the pix_ objects is the MMX code on is fixed to a different order than what OSX Intel uses. For some objects this makes no difference, but others require the components in a specific order. So to fix some bug complaints I swapped the byte order to match the MMX code, but this broke other things so it was switched back. Perhaps defining some MMX/SSE macros for the order would sort this out?
I don't think there are any GL alpha problems at all.
the problem is most likely not with openGL. however, the problem is not only with SIMD code, even after your changes.
a test of [pix_mask] revealed a lot of weirdnesses (but unfortunately i don't have access to my test-patch right now, so i try to reconstruct it by heart) the tests have been done on an i686 (OSX-10.4.?) i got different results when using [pix_image], [pix_film] and [pix_video] as pix-source; i also get different results when using [colorspace RGBA( vs [pix_rgba] the results differ in both swapping color-channels _and_ having different "types". iirc, images in RGBA space with type GL_UNSIGNED_INT_8_8_8_8_REV where almost certain to yield blueish results with alpha mask not working. finally, [pix_mask] does _not_ involve any MMX/SSE2 code.
i am pretty sure that on macIntel images of type GL_BGRA_EXT are _not_ of type GL_UNSIGNED_INT_8_8_8_8_REV, is this correct?
anyhow, i thought before i start thinking about changing things and making them worse, i would rather now what the target layout of the colors is, that's why i started the wiki.
and yes, i also think that having some macros for the SSE/MMX code will help us (but i am not that far yet...)
fgmadsr IOhannes
On Wed, May 28, 2008 at 11:54 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
i am pretty sure that on macIntel images of type GL_BGRA_EXT are _not_ of type GL_UNSIGNED_INT_8_8_8_8_REV, is this correct?
Correct.
anyhow, i thought before i start thinking about changing things and making them worse, i would rather now what the target layout of the colors is, that's why i started the wiki.
Having the pix_image/film/video be consistent even if wrong is a good place to start.
and yes, i also think that having some macros for the SSE/MMX code will help us (but i am not that far yet...)
fgmadsr IOhannes
Just for example, here is what i get when i open a simple image with Gem (without alpha) with a recent Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX.4.11. All works fine with Pd-extended (20080315) and GEM: ver: 0.91-cvs. So i only use this Pd and Gem now on my PowerPC. I also send an email about a problem with [pix_mask] too. ++
Jack
Le 28 mai 08 à 18:54, IOhannes m zmoelnig a écrit :
chris clepper wrote:
The problem with the pix_ objects is the MMX code on is fixed to a different order than what OSX Intel uses. For some objects this makes no difference, but others require the components in a specific order. So to fix some bug complaints I swapped the byte order to match the MMX code, but this broke other things so it was switched back. Perhaps defining some MMX/SSE macros for the order would sort this out?
I don't think there are any GL alpha problems at all.
the problem is most likely not with openGL. however, the problem is not only with SIMD code, even after your changes.
a test of [pix_mask] revealed a lot of weirdnesses (but unfortunately i don't have access to my test-patch right now, so i try to reconstruct it by heart) the tests have been done on an i686 (OSX-10.4.?) i got different results when using [pix_image], [pix_film] and [pix_video] as pix-source; i also get different results when using [colorspace RGBA( vs [pix_rgba] the results differ in both swapping color-channels _and_ having different "types". iirc, images in RGBA space with type GL_UNSIGNED_INT_8_8_8_8_REV where almost certain to yield blueish results with alpha mask not working. finally, [pix_mask] does _not_ involve any MMX/SSE2 code.
i am pretty sure that on macIntel images of type GL_BGRA_EXT are _not_ of type GL_UNSIGNED_INT_8_8_8_8_REV, is this correct?
anyhow, i thought before i start thinking about changing things and making them worse, i would rather now what the target layout of the colors is, that's why i started the wiki.
and yes, i also think that having some macros for the SSE/MMX code will help us (but i am not that far yet...)
fgmadsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
For info, [pix_film], [pix_movie], [pix_video] seem to work fine here with Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX.4.11 (using 5.reference/Gem). ++
Jack
Le 28 mai 08 à 19:09, Jack a écrit :
Just for example, here is what i get when i open a simple image with Gem (without alpha) with a recent Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX. 4.11. All works fine with Pd-extended (20080315) and GEM: ver: 0.91- cvs. So i only use this Pd and Gem now on my PowerPC. I also send an email about a problem with [pix_mask] too. ++
Jack<Archive.zip>
Le 28 mai 08 à 18:54, IOhannes m zmoelnig a écrit :
chris clepper wrote:
The problem with the pix_ objects is the MMX code on is fixed to a different order than what OSX Intel uses. For some objects this makes no difference, but others require the components in a specific order. So to fix some bug complaints I swapped the byte order to match the MMX code, but this broke other things so it was switched back. Perhaps defining some MMX/SSE macros for the order would sort this out?
I don't think there are any GL alpha problems at all.
the problem is most likely not with openGL. however, the problem is not only with SIMD code, even after your changes.
a test of [pix_mask] revealed a lot of weirdnesses (but unfortunately i don't have access to my test-patch right now, so i try to reconstruct it by heart) the tests have been done on an i686 (OSX-10.4.?) i got different results when using [pix_image], [pix_film] and [pix_video] as pix-source; i also get different results when using [colorspace RGBA( vs [pix_rgba] the results differ in both swapping color-channels _and_ having different "types". iirc, images in RGBA space with type GL_UNSIGNED_INT_8_8_8_8_REV where almost certain to yield blueish results with alpha mask not working. finally, [pix_mask] does _not_ involve any MMX/SSE2 code.
i am pretty sure that on macIntel images of type GL_BGRA_EXT are _not_ of type GL_UNSIGNED_INT_8_8_8_8_REV, is this correct?
anyhow, i thought before i start thinking about changing things and making them worse, i would rather now what the target layout of the colors is, that's why i started the wiki.
and yes, i also think that having some macros for the SSE/MMX code will help us (but i am not that far yet...)
fgmadsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Quoting Jack jack@rybn.org:
For info, [pix_film], [pix_movie], [pix_video] seem to work fine here with Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX.4.11 (using 5.reference/Gem).
so it is only [pix_image] that makes problems?
does the alpha work too?
fgamsr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Le 28 mai 08 à 21:24, zmoelnig@iem.at a écrit :
Quoting Jack jack@rybn.org:
For info, [pix_film], [pix_movie], [pix_video] seem to work fine here with Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX.4.11 (using 5.reference/Gem).
so it is only [pix_image] that makes problems?
Yep, it seems. Here a capture with [pix_image] and [pix_texture].
does the alpha work too?
Yep, it work. With [pix_image], i get blue pixel (in my case, [pix_image] doesn't work). But with [pix_film], all is ok (normal too, because [pix_film] works fine for me). ++
Jack
fgamsr IOhannes
This message was sent using IMP, the Internet Messaging Program.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Jack wrote:
Le 28 mai 08 à 21:24, zmoelnig@iem.at a écrit :
Quoting Jack jack@rybn.org:
For info, [pix_film], [pix_movie], [pix_video] seem to work fine here with Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX.4.11 (using 5.reference/Gem).
so it is only [pix_image] that makes problems?
Yep, it seems. Here a capture with [pix_image] and [pix_texture].
does the alpha work too?
Yep, it work. With [pix_image], i get blue pixel (in my case, [pix_image] doesn't work). But with [pix_film], all is ok (normal too, because [pix_film] works fine for me). ++
i think i might have fixed it in the v0-91 branch now. at least i get consistent (and correct looking) behaviour on both G5 and i386)
either try out the new universal binary to be found at http://gem.iem.at/releases/0.91.0/ or wait for the next pd-extended build (tomorrow)
fgmasdr IOhannes
OK nice. Thanx Iohannes, I will test it tomorrow with autobuild of Pd- ext. ++
Jack
Le 29 mai 08 à 13:49, IOhannes m zmoelnig a écrit :
Jack wrote:
Le 28 mai 08 à 21:24, zmoelnig@iem.at a écrit :
Quoting Jack jack@rybn.org:
For info, [pix_film], [pix_movie], [pix_video] seem to work fine here with Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX.4.11 (using 5.reference/Gem).
so it is only [pix_image] that makes problems?
Yep, it seems. Here a capture with [pix_image] and [pix_texture].
does the alpha work too?
Yep, it work. With [pix_image], i get blue pixel (in my case, [pix_image] doesn't work). But with [pix_film], all is ok (normal too, because [pix_film] works fine for me). ++
i think i might have fixed it in the v0-91 branch now. at least i get consistent (and correct looking) behaviour on both G5 and i386)
either try out the new universal binary to be found at http:// gem.iem.at/releases/0.91.0/ or wait for the next pd-extended build (tomorrow)
fgmasdr IOhannes
Now, with Pd version 0.40.3-extended-20080601, [pix_image], [pix_film], [pix_alpah] work fine here. Thanx to have fixed this Iohannes. ++
Jack
Le 29 mai 08 à 14:17, Jack a écrit :
OK nice. Thanx Iohannes, I will test it tomorrow with autobuild of Pd- ext. ++
Jack
Le 29 mai 08 à 13:49, IOhannes m zmoelnig a écrit :
Jack wrote:
Le 28 mai 08 à 21:24, zmoelnig@iem.at a écrit :
Quoting Jack jack@rybn.org:
For info, [pix_film], [pix_movie], [pix_video] seem to work fine here with Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX.4.11 (using 5.reference/Gem).
so it is only [pix_image] that makes problems?
Yep, it seems. Here a capture with [pix_image] and [pix_texture].
does the alpha work too?
Yep, it work. With [pix_image], i get blue pixel (in my case, [pix_image] doesn't work). But with [pix_film], all is ok (normal too, because [pix_film] works fine for me). ++
i think i might have fixed it in the v0-91 branch now. at least i get consistent (and correct looking) behaviour on both G5 and i386)
either try out the new universal binary to be found at http:// gem.iem.at/releases/0.91.0/ or wait for the next pd-extended build (tomorrow)
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Quoting Jack jack@rybn.org:
Just for example, here is what i get when i open a simple image with Gem (without alpha) with a recent Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX.4.11.
both screenshots are taken with 0.91.0? it i think it works better with [pix_texture] :-)
All works fine with Pd-extended (20080315) and GEM: ver: 0.91-cvs. So i only use this Pd and Gem now on my PowerPC.
so we probably should use this version for the binary release. i forgot: how do i create a Gem.d_fat from a Gem.d_i386 and a Gem.d_ppc?
I also send an email about a problem with [pix_mask] too.
that is why i started this whole thread...
fgmsad IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On May 28, 2008, at 9:22 PM, zmoelnig@iem.at wrote:
Quoting Jack jack@rybn.org:
Just for example, here is what i get when i open a simple image with Gem (without alpha) with a recent Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX.4.11.
both screenshots are taken with 0.91.0? it i think it works better with [pix_texture] :-)
All works fine with Pd-extended (20080315) and GEM: ver: 0.91-cvs. So i only use this Pd and Gem now on my PowerPC.
so we probably should use this version for the binary release. i forgot: how do i create a Gem.d_fat from a Gem.d_i386 and a Gem.d_ppc?
Add these to CFLAGS and LDFLAGS:
-arch ppc -arch ppc64 -arch i386
Remove "-arch ppc64" if you don't think a 64-bit build is safe.
.hc
I also send an email about a problem with [pix_mask] too.
that is why i started this whole thread...
fgmsad IOhannes
This message was sent using IMP, the Internet Messaging Program.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------ ----
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
On Wed, May 28, 2008 at 5:44 PM, Hans-Christoph Steiner hans@eds.org wrote:
-arch ppc -arch ppc64 -arch i386
Remove "-arch ppc64" if you don't think a 64-bit build is safe.
ppc64 will fail.
Hans-Christoph Steiner wrote:
i forgot: how do i create a Gem.d_fat from a Gem.d_i386 and a Gem.d_ppc?
Add these to CFLAGS and LDFLAGS:
-arch ppc -arch ppc64 -arch i386
it seems my question was unprecise: i know how to compile/link a Gem.d_fat from scratch (that's how the downloadable binary is built), but i was wondering how to do it manually. that is "create a Gem.d_fat from a Gem.d_i386 and a Gem.d_ppc" (combine 2 binaries for different archs into a single multiarch binary)
i don't know whether this is possible at all, but think there ought to be a way...
fmgadsr IOhannes
hi iohannes, not sure what exactly I should test. I would like to help you solve this problem, and the easiest would be if you could provide a small test series that includes all the things that have to be tested. I figure it should contain pix_image, pix_film, pix_movie. but pix movie for example still flickers and with pix_film I am not sure how to use it with pix_mask. also, do you still need testing on pix_write and pix_record? with/without alpha??? marius.
IOhannes m zmoelnig wrote:
as hinted in my last email, Gem seems to have different hardcoded ideas about what RGBA means (esp. on OSX)
the main confusion is about which "type" to use: GL_UNSIGNED_INT_8_8_8_8_REV vs GL_UNSIGNED_INT_8_8_8_8 the solution seems to be simple (_REV on ppc, normal on i686) but it seems to be done inconsistently in the source code, thus resulting in all the alpha problems marius has reported.
i have created a wiki-page that tries to explain the technical implementation of Gem's standard colorspaces, which can be found at http://gem.iem.at/documentation/GemWiki/ColorSpace
i have filled this page to my best knowledge, but i would be glad if somebody who knows what they are doing could have a look at it and confirm (or correct) everything (esp. those lines marked with "?")
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
chris clepper -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jack -
marius schebella -
zmoelnig＠iem.at