[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