[PD-dev] [GEM] new postrender crashes OS X

zmoelnig at iem.at zmoelnig at iem.at
Fri Dec 20 21:03:56 CET 2002


Zitiere tigital <tigital at mac.com>:

hi !

> >please read the CVS-Manual
> ...this is something I'm still figuring out...;-)
me too (that's why i was referring to the manual)
> 
> >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...

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.

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.
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 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)
> >

> >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...

it was just: forgotten defines and stuff like this
i didn't complain, because i expected this when i was checking out your sources
i just meant, it could happen to you too, once or twice..
> 
> >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...!

that's why i wrote this PPS
> 
> In any event, let's keep the communication going!
yep


mfg.a.rds
IOhannes

> 
> tanx,
> jamie
> 




More information about the Pd-dev mailing list