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

[bbogart at ryerson.ca]

Hey guys,

As for naming, how about pix_foo_yuv for the yuv versions of the objects..

As for YUV in general I think it would only be used by more advanced users, mostely because the colorspace is imply that much more difficult to get your head around. As such I would say objects should be rgb by default and the yuv choice only comes in when you know you want it. 

I think the waysoftVNS deals with colorspace is more as Johannes describes, with very fast conversion between colorspaces (altivec) I think you can specify the color space of a video source by send the source object a message. Perhaps something similar in Gem where the pix_ objects check what kinda of data they are getting and act accordingly, ie printing a message saying that pix_blah only supports YUV, and you must use pix_yuv to convert the rgba stream in order to use this object. 

with all the efforts with coloured patchcords, how about changing the color of an object when it gets a datastream it does not support. Some of the other packages (eyesweb) only lets you connect compatible data types, otherwise it simply refuses to connect the objects. 

Some ideas from my perspective anyhow.

Ben 

----- Original Message -----
From: chris clepper <cclepper at artic.edu>
Date: Friday, December 20, 2002 7:39 pm
Subject: Re: [PD-dev] [GEM] new postrender crashes OS X

> >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
> 
> 
> 
> 
> -- 
> 
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
>