hi gem-devs.
because chris doesn't like getting no information (and probably others too)
i will checkin something into Gem.
1. particles: upgrade to libparticle-120 (was 111). this does not effect most part-objects, but gives some more control (like there is an age-output at [part_info], there is an alpha-channel with [part_color]...)
2. GemBase: the stoprender() and stoprenderCallback() had been commented out by me. when i tried to compile gem2pdp (0.3) they were needed, so they are in again. probably the [gem2pdp] should stem from [gemhead] rather ?
3. GemPixUtils: here we go (i did it again): i have put colour-conversion routines in here. (routines for acquiring data from a specific format like YUV420P) this (the place) might be horrible, and i am very willing to put this into GemPixConvert (but i needed it quickly, and dirty is often faster on the short hand) as always, for now they are only non-optimized. but this will hopefully change.
4. [pix_rgba] on mac this used to produce the wrong colours. i think the rgba-format for mac is GL_ABGR_EXT, so i changed it to this (but i have not tested it)
5. [pix_add], [pix_sub]: Grey2Grey-support
6. [pix_videoNEW]: had forgotten the "device"-Message to switch between various devices (like my Webcam and my capture-card)
hope that's it
mfg.asd.r IOhannes
- [pix_rgba]
on mac this used to produce the wrong colours. i think the rgba-format for mac is GL_ABGR_EXT, so i changed it to this (but i have not tested it)
pix_rgba should have no function on OSX at all. i had #ifdef'd out all of the code that would do anything. frankly this object is really pointless as the film/video object should decompress to the correct display format. i've never had to use this object in any GEM patch, it may be useful for implicit color-conversion, but that's about it. also, the correct format for OSX is GL_BGRA_EXT. i don't think the one you have above even exists. anyway i will just ifdef out the changes so the object has no effect again.
cgc
I do agree with chris, the user should not have to care too much about color conversion, and as pix_rbga is only needed to convert film output to Gem "native" colorspace it could be done in the film objects themselves.
Guenter
On Wed, 7 May 2003, chris clepper wrote:
- [pix_rgba]
on mac this used to produce the wrong colours. i think the rgba-format for mac is GL_ABGR_EXT, so i changed it to this (but i have not tested it)
pix_rgba should have no function on OSX at all. i had #ifdef'd out all of the code that would do anything. frankly this object is really pointless as the film/video object should decompress to the correct display format. i've never had to use this object in any GEM patch, it may be useful for implicit color-conversion, but that's about it. also, the correct format for OSX is GL_BGRA_EXT. i don't think the one you have above even exists. anyway i will just ifdef out the changes so the object has no effect again.
cgc
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Zitiere guenter geiger geiger@xdv.org:
I do agree with chris, the user should not have to care too much about color conversion, and as pix_rbga is only needed to convert film output to Gem "native" colorspace it could be done in the film objects themselves.
i do agree that uses shouldn't have to care about colour-spaces (it really get's confusing) i also agree that the colour-space conversions should be done in the image- source objects (like film) unfortunately i am not sure, whether the only use of [pix_rgba] is for conversion into "native" colour-space. sometimes i really like having an alpha-channel....
rgba-format for mac is GL_ABGR_EXT, so i changed it to this (but i have not tested it)
pix_rgba should have no function on OSX at all.
(see above)
patch, it may be useful for implicit color-conversion, but that's about it.
right , that's about it.
also, the correct format for OSX is GL_BGRA_EXT. i don't
as i read from GemPixUtil.h (changes by tigital) const int chRed = 1; const int chGreen = 2; const int chBlue = 3; const int chAlpha = 0;
this really looks like something ARGB (but you are right, this is not ABGR)
think the one you have above even exists. anyway i will just ifdef
however, my nvidia'ized gl.h says #define Gl_ABGR_EXT 0x800
out the changes so the object has no effect again.
cgc
anyhow, for some personal reasons i'd like to have colour-space conversions. to give them not too much room, would something like [pix_convert] (or [pix_colourspace] be ok for everybody ? anybody refusing to test them ?
mfg.a.srd IOhannes
On Fri, 9 May 2003 zmoelnig@iem.at wrote:
unfortunately i am not sure, whether the only use of [pix_rgba] is for conversion into "native" colour-space. sometimes i really like having an alpha-channel....
I was thinking the "native" colorspace is with alpha channel, but with yuv this is not the case, as I have heard. (In the film example pix_rgba was used to convert from RGB to RGBA, which I thought is a bit strange).
Yes the alpha channel is quite nice in several circumstances .. will this be lost on OSX when there is no pix_rgba ?
Guenter
rgba-format for mac is GL_ABGR_EXT, so i changed it to this (but i have not tested it)
pix_rgba should have no function on OSX at all.
(see above)
patch, it may be useful for implicit color-conversion, but that's about it.
right , that's about it.
also, the correct format for OSX is GL_BGRA_EXT. i don't
as i read from GemPixUtil.h (changes by tigital) const int chRed = 1; const int chGreen = 2; const int chBlue = 3; const int chAlpha = 0;
this really looks like something ARGB (but you are right, this is not ABGR)
think the one you have above even exists. anyway i will just ifdef
however, my nvidia'ized gl.h says #define Gl_ABGR_EXT 0x800
out the changes so the object has no effect again.
cgc
anyhow, for some personal reasons i'd like to have colour-space conversions. to give them not too much room, would something like [pix_convert] (or [pix_colourspace] be ok for everybody ? anybody refusing to test them ?
mfg.a.srd IOhannes
On Fri, 9 May 2003 zmoelnig@iem.at wrote:
unfortunately i am not sure, whether the only use of [pix_rgba] is for conversion into "native" colour-space. sometimes i really like having an alpha-channel....
I was thinking the "native" colorspace is with alpha channel, but with yuv this is not the case, as I have heard. (In the film example pix_rgba was used to convert from RGB to RGBA, which I thought is a bit strange).
yes the buffer should be filled with R+G+B+A in order for the pix_objects to process the data. GEM currently has no way to work with a 24bpp RGB buffer. so it makes no sense to have the pix_film/video object deliver anything but 32bpp buffers.
Yes the alpha channel is quite nice in several circumstances .. will this be lost on OSX when there is no pix_rgba ?
nope. the native mac pixel format is ARGB and that's what the pix_film/video objects put in the buffers. there's an ifdef for OSX that changes the ordering of the channels and GL_BGRA_EXT is the corresponding GL format.
cgc
Guenter
-
chris clepper -
guenter geiger -
IOhannes zmoelnig -
zmoelnig＠iem.at