k. this is quite my first project i'm doing with CVS, and i am not very used to developing software in a (physically dislocated) team. so i fear, i have to learn a lot... on the other hand, the CVS-code is something i am working on, and though i try to get my changes somehow stable before commiting them i cannot guarantee this. i try to be verbose in the cvs-logs, but since i don't submit single files, the log will be for all the files submitted

...that makes three of us!

furthermore, the strength of CVS is, that you can can get old sources if the new ones appear to be crashy. please read the CVS-Manual

...this is something I'm still figuring out...;-)

the pix_fx-class just made sure, that you could do what you want with the image-data by proxying the pixBlock i do think now(!), that it was a bad idea to make an own class for this and that it would be better to make the proxying default to the GemPixObj (so you don't have to care at all, if you want to modify (like resize, change format,...) your pixBuf.

...yeah, I never understood the pix_fx stuff...one big thing I'd like to see is (perhaps) a mode in which a stopped movie/still image is sent through the render chain constantly, so that other pix_* objects can still work with it...

IMAGES: i just see several design-flaws within Gem which i try to fix, esp with the Pix-thing the org Gem used to know only 2 kinds of images: rgba (handled by processImage()) and grey-scale (handled by processGreyImage()) since those mac-guys introduced new YUV-format (and me too, like bgra_ext or rgb), i think, this is not appropriate anymore. i therefore suggest (and have done so, without anyone asking) to use following convention process<format>Image() for format-specific processing (like processRGBAImage() or processYUVImage()) processImage() for non-format-specific processing (if you have a function that doesn't care for what format you use) by default, the format-specific functions call (if not overridden by the child-class) the non-format-specific processImage(), which (by default) outputs an error

a similar change will be for the GemPixDualObj proposal: there will be fucntions for any combination of 2 images, like processRGBA_RGBA() or processYUV_Grey() By default, they call the non-format-specific processDualImage() The processLeftGrey() (and however they are called) are deprecated !

YUV: again i would like to stress: please do not make [yuv_*] objects, but make [pix_*] objects with functions for YUV. The processImage() will then bail out, when images other than YUV want to be processed.

...I really side with chris on this: there is too much of a difference between yuv and rgba to necessitate them being in the same object...true, they are both pixel types, and true, we can convert between the two, but many operations on one would be impossible or at least non-trivial to do for the other; controls would also be totally different and not very interchangeable...

TV: ah, the stupid TV-class. I'm still not sure about it (tending to think that it was a bad idea) the intension is, to make clear, that this objects work only with a series of images (aka: a film). Thus the [pix_aging] is a pix-object (because it will produce something "valid" on single images, although it is designed for a series of images), the [tv_biquad] doesn't make sense with only one picture.

GLUT: i'm very sure, that GLUT is not needed for glm (i haven't really looked at the source-code when i used it then...), we should remove it then (as Günter said). f**k the teapot (it was just for fun...)

...I don't think this is needed either: and glm compiles fine without it on OS X...

PS: well, if you can't compile Gem with the new CVS, i took me some hours too, when the macOS-X code was commited....

...sorry, I didn't know about that: what went wrong? I could only assume that things were ok because I either didn't hear anything or OS X people had no problems...

PPS: maybe i am ironic sometimes in this mail without explicitely saying so with all those smileys (i don't like them)....

...irony is very difficult to interpret in email...!

In any event, let's keep the communication going!

tanx, jamie

what i want to have: one "class" of objects, that do image-processing (ok, we have said this several times by now...) All objects should be derived from "one" real class (in C++), the GemPixObj (or GemPixDualObj) as with naming: if you really think, you won't get what you want if objects are called "pix_*" instead of "yuv_*", go on, and make "pix_*" objects and !alias! them to "yuv_*" (with class_addcreator()). this should be easy, and everybody would be happy.

the only thing i can't figure out is how to make it clear which objects work with which color space. the current method of dumping endless error messages to the console is simply awful.

i can easily see building processing chains that don't work at all. without some sort of feedback from GEM it will not be apparent why these chains do nothing or don't work as expected. maybe someone can come up with an elegant solution for this...

now, why do i want this ? of course there are differences between operations in color-space, but maybe, somebody wants this ? multiplying channels with scalars might have completely different results in YUV-space and in RGBA-space. But that's OK! I'd like it this way (it extends the possibilities of image- processing) sometimes we might not be able to do things in a specific color-space. Gosh, that's ok! i do think, plenty of operations (pE. alpha-keying) don't work in Grey-space.

there's no alpha in yuv either, but also no luma in rgba. those are pretty big differences to me, which require not only different coding but also differentiation in the user interface (messaging and arguments,etc). one of the ideas about adding yuv was to not have to use rgb anymore

If i have a fast processor (and in near future we all will have), conversion between yuv and rgba (as far as it is possible) might not be the problem any longer.

i never assume that fast processors and high end graphics cards are being used with GEM. the whole point of writing the yuv_* in the first place is to have fast video on slower hardware!!

live, i use a lowly g3/400 laptop with a pathetic 8MB Rage128 chip, and the stuff i write in GEM runs fine. in fact if it doesn't run ok i rewrite it until it does. of course my faster boxes are nicer to use GEM on ;)

i don't think, that YUV is something "OS-specific". just some OS's support it better than others. maybe this will change. i'd rather prefer it like it is and introduce a "conversion on demand" object before the actual texturing (that will convert YUV to RGB on PC-platforms but not on Mac's)

conversion is fine as long as it's not relied upon heavily. the one pix_ does all will require a bit of knowledge about yuv and rgba from end users to get the hang of it, and the clearer these differences are set down the shallower the learning curve. GEM needs more and better docs anyway, so some color-space info could be rolled in to that.

i'm also in favor of creating a stable and experimental version of GEM in the CVS. that way the stable version will at least be functional, but without yuv, while we sort out everything.

cgc