Hi, I don't know if that helps, but here is what I get when I connect a pix_info to a pix_image: colorspace 32993. (which is supposed to be GL_BGRA). is this what it should be? when I connect pix_image to pix_color (and texture and square) the image is messed up (colors are yellowish blue and luminance are somehow combined). when I connect pix_image to pix_yuv the image appears blueish and I get colorspace 34233 (GL_YCBCR_422_APPLE). [color] works (colorspace 32993).
another problem is this: [pix_image] | [pix_rgba] | [pix_texture] when I rename the object pix_rgba to pix_color, then the image gets yellow. but then even when I disconnect pix_color and go directly from pix_image to pix_texture the image stays yellow, until I reload the image (then it is fine again).
I can test which other pix objects are broken (pix_alpha for example...) marius.
Hello Marius, i'm on G4 powerbook 12" Macosx.4.10 with pd-extended 0.39.3 Gem ver: 0.91-cvs
Le 7 nov. 07 à 16:33, marius schebella a écrit :
Hi, I don't know if that helps, but here is what I get when I connect a pix_info to a pix_image: colorspace 32993. (which is supposed to be GL_BGRA). is this what it should be?
Hmm, strange, in the help GL_BGRA is colorspace 6408 and the result with my RGBA image is also 32993.
when I connect pix_image to pix_color (and texture and square) the image is messed up (colors are yellowish blue and luminance are somehow combined).
I never use [pix_color] (always [color] or [colorRGB]), but here my image disappear !
when I connect pix_image to pix_yuv the image appears blueish and I get colorspace 34233 (GL_YCBCR_422_APPLE).
I get 34233 too.
[color] works (colorspace 32993).
with [color] after [pix_yuv] i still have 34233
another problem is this: [pix_image] | [pix_rgba] | [pix_texture] when I rename the object pix_rgba to pix_color, then the image gets yellow.
Not here, the image disappear
but then even when I disconnect pix_color and go directly from pix_image to pix_texture the image stays yellow, until I reload the image (then it is fine again).
Same result here
I can test which other pix objects are broken (pix_alpha for example...) marius.
[pix_alpha] hmm i don't like this object : lot of problem on macintel !
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
If you use pix_film instead of pix_image to load the image do you have the same problems?
On Nov 7, 2007 9:33 AM, marius schebella marius.schebella@gmail.com wrote:
Hi, I don't know if that helps, but here is what I get when I connect a pix_info to a pix_image: colorspace 32993. (which is supposed to be GL_BGRA). is this what it should be? when I connect pix_image to pix_color (and texture and square) the image is messed up (colors are yellowish blue and luminance are somehow combined). when I connect pix_image to pix_yuv the image appears blueish and I get colorspace 34233 (GL_YCBCR_422_APPLE). [color] works (colorspace 32993).
another problem is this: [pix_image] | [pix_rgba] | [pix_texture] when I rename the object pix_rgba to pix_color, then the image gets yellow. but then even when I disconnect pix_color and go directly from pix_image to pix_texture the image stays yellow, until I reload the image (then it is fine again).
I can test which other pix objects are broken (pix_alpha for example...) marius.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
with pix_film the pix_info gives me a colorspace output of 34233, but I cannot use it with pix_color, that gives only white color... pix_rgba does some conversion, but then again pix_stays is white. [pix_film] (pix_info: 34233) | [pix_rgba] (pix_info: 32993) | [pix_color] (white) this is with gem 0.91 from cvs nov 5 from (comes with the latest pd-extended). marius.
chris clepper wrote:
If you use pix_film instead of pix_image to load the image do you have the same problems?
On Nov 7, 2007 9:33 AM, marius schebella marius.schebella@gmail.com wrote:
Hi, I don't know if that helps, but here is what I get when I connect a pix_info to a pix_image: colorspace 32993. (which is supposed to be GL_BGRA). is this what it should be? when I connect pix_image to pix_color (and texture and square) the image is messed up (colors are yellowish blue and luminance are somehow combined). when I connect pix_image to pix_yuv the image appears blueish and I get colorspace 34233 (GL_YCBCR_422_APPLE). [color] works (colorspace 32993).
another problem is this: [pix_image] | [pix_rgba] | [pix_texture] when I rename the object pix_rgba to pix_color, then the image gets yellow. but then even when I disconnect pix_color and go directly from pix_image to pix_texture the image stays yellow, until I reload the image (then it is fine again).
I can test which other pix objects are broken (pix_alpha for example...) marius.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
pix_color replaces all of the pixels in an image so getting a solid color is what one would expect. I don't know what you are trying to do with pix_rgba, but I don't think there is any reason to use this unless you need to convert YUV or grey to RGB.
I responded to your other thread about pix_alpha not working, but I could not reproduce the problem. I ran a diff on pix_image and pix_alpha and both appear to be the same code on my machine and CVS.
On Nov 7, 2007 2:49 PM, marius schebella marius.schebella@gmail.com wrote:
with pix_film the pix_info gives me a colorspace output of 34233, but I cannot use it with pix_color, that gives only white color... pix_rgba does some conversion, but then again pix_stays is white. [pix_film] (pix_info: 34233) | [pix_rgba] (pix_info: 32993) | [pix_color] (white) this is with gem 0.91 from cvs nov 5 from (comes with the latest pd-extended). marius.
chris clepper wrote:
If you use pix_film instead of pix_image to load the image do you have the same problems?
On Nov 7, 2007 9:33 AM, marius schebella marius.schebella@gmail.com wrote:
Hi, I don't know if that helps, but here is what I get when I connect a pix_info to a pix_image: colorspace 32993. (which is supposed to be GL_BGRA). is this what it should be? when I connect pix_image to pix_color (and texture and square) the image is messed up (colors are yellowish blue and luminance are somehow combined). when I connect pix_image to pix_yuv the image appears blueish and I get colorspace 34233 (GL_YCBCR_422_APPLE). [color] works (colorspace 32993).
another problem is this: [pix_image] | [pix_rgba] | [pix_texture] when I rename the object pix_rgba to pix_color, then the image gets yellow. but then even when I disconnect pix_color and go directly from pix_image to pix_texture the image stays yellow, until I reload the image (then it is fine again).
I can test which other pix objects are broken (pix_alpha for example...) marius.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
marius schebella wrote:
Hi, I don't know if that helps, but here is what I get when I connect a pix_info to a pix_image: colorspace 32993. (which is supposed to be GL_BGRA). is this what it should be?
on apple it should.
when I connect pix_image to pix_color (and texture and square) the image is messed up (colors are yellowish blue and luminance are somehow combined). when I connect pix_image to pix_yuv the image appears blueish and I get colorspace 34233 (GL_YCBCR_422_APPLE).
this might be a minor bug in the color-conversion routines (depending on the quantity of blueishness), but should not be related to your other problems.
[color] works (colorspace 32993).
[color] does not have anything todo with the pix-colorspaces. it is always in RGBA and works on Geos instead of Pixes.
another problem is this: [pix_image] | [pix_rgba] | [pix_texture]
when I rename the object pix_rgba to pix_color, then the image gets yellow. but then even when I disconnect pix_color and go directly from pix_image to pix_texture the image stays yellow, until I reload the image (then it is fine again).
this is "normal" behaviour, and has to do with the way Gem tries to minimize operations. if you don't like it, you can file a feature request (i don't think it is a real bug)
mfg.as IOhannes
-
chris clepper -
IOhannes m zmoelnig -
Jack -
marius schebella