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@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@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hey guys,
As for naming, how about pix_foo_yuv for the yuv versions of the objects..
i initially started writing the yuv stuff like that. there is still a pix_filmYUV hanging around.
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.
the complexity really depends on the operation. for proper chroma-keying and color adjustment one must know about yuv color space. other functions like blurring, mixing and masking are just like their rgb counterparts.
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.
the GEM objects do detect which color space is being used by the bits-per-pixel of the pixmap. the conversion for every object just doesn't make any sense at all. let's say you want to luma-key two movies in DV or photo-jpeg codec, here's what would take place in the auto_conversion scenario:
pix_film (yuv->rgba) * 2 -> pix_luma-key (rgba->yuv->rgba) -> pix_texture
compared to keeping it in yuv:
yuv_film -> yuv_luma_key -> pix_texture
the first one is doing a hell of a lot of pointless work to get the same thing done. i pick the second method.
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.
those are both good ideas. i'm not sure about the state of pd's gui and how well such changes would be accepted. i haven't done any work on the tcl/tk end yet, so i don't even know how to do this.
Some ideas from my perspective anyhow.
thanks for all your ideas. i really like to hear input from GEM users.
cgc
Ben
Zitiere chris clepper cclepper@artic.edu:
Hey guys,
As for naming, how about pix_foo_yuv for the yuv versions of the
objects..
i initially started writing the yuv stuff like that. there is still a pix_filmYUV hanging around.
as ben pointed out: how about sending a "want YUV"-message to a proper [pix_film] and not having to worry whether you should need a [pix_filmBGRA_ext] or [pix_filmLUMINANCE] ?
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.
the complexity really depends on the operation. for proper chroma-keying and color adjustment one must know about yuv color space. other functions like blurring, mixing and masking are just like their rgb counterparts.
so why segregating them ?
pix_film (yuv->rgba) * 2 -> pix_luma-key (rgba->yuv->rgba) -> pix_texture
compared to keeping it in yuv:
yuv_film -> yuv_luma_key -> pix_texture
the first one is doing a hell of a lot of pointless work to get the same thing done. i pick the second method.
i was rather thinking of something like [pix_film] (on demand, tries to load YUV, if it fails (because the codec does not support it (is this possible), loads RGBA) -> [pix_yuv] (if pix_film returns YUV this does *nothing*, if we only have RGBA it converts to YUV) -> [pix_luma-key] (everything done in YUV-space) -> [pix_textureformat] (converts into a format that can be textured by the openGL-implementation - on macOS it might do nothing) -> [pix_texture]
this is exactly two more objects ([pix_yuv] and [pix_textureformat]) and one more message for the pd/gem-programmer to create, and does not cost "anything" (apart from void function-calls, which i don't take into account with respect to image-processing) on platforms that provide YUV-space and does cost more on platforms that don't, but hey! it is portable my primary goal with Gem is to have a platform for graphics that is supported by many OS's and does exactly the same on all OS's i will not have linux-only or macOS-only stuff in Gem as it is. For things like this, i would recommend to have a look at gemee (but i would rather not fork development)
mfg.ds.r IOhannes
as ben pointed out: how about sending a "want YUV"-message to a proper [pix_film] and not having to worry whether you should need a [pix_filmBGRA_ext] or [pix_filmLUMINANCE] ?
that would work, but the question of feedback to the user remains. how do you make it clear which objects work with which color-space properly? and when do you need to convert? would this be automatic or user controlled?
the complexity really depends on the operation. for proper chroma-keying and color adjustment one must know about yuv color space. other functions like blurring, mixing and masking are just like their rgb counterparts.
so why segregating them ?
i think i've said this before:
At 6:35 PM -0600 12/16/02, chris clepper wrote:
here is my reasoning for making the [yuv_] set objects:
- a separate set of objects would be easier to leave out of compiles
for platforms that don't support it.
...
- there is not a one to one correlation between yuv and rgb color-spaces.
...
- Gem already had the pix_ naming convention which made it clear
that pix = image processing and that stringing pix_objects together would result in a functional chain. my initial attempts to extend pix to yuv seemed to destroy that, so i decided that yuv_objects would make their own chains to avoid confusion.
...
i was rather thinking of something like [pix_film] (on demand, tries to load YUV, if it fails (because the codec does not support it (is this possible), loads RGBA) -> [pix_yuv] (if pix_film returns YUV this does *nothing*, if we only have RGBA it converts to YUV) -> [pix_luma-key] (everything done in YUV-space) -> [pix_textureformat] (converts into a format that can be textured by the openGL-implementation - on macOS it might do nothing) -> [pix_texture]
ok. how about this: pix_film -> pix_luma_key -> pix_alpha -> pix_composite -> pix_texture
that's a total mess to mix and match yuv and rgba when you have alpha in one and not the other. i don't immediately see a good solution to this apart from lots of conversions that either happen in the objects automatically or a bunch of conversion objects added to the chain.
i can go on and on with examples like this, and would have to test all of these combinations if yuv_ is integrated into pix_. pix_ objects imply that they all work together, and that should be the case if yuv is added. also it seems like if conversion is going to be necessary for most situations and platforms then maybe it shouldn't be included in the CVS at all.
i will not have linux-only or macOS-only stuff in Gem as it is.
i just don't see how that's possible to maintain. osx is not linux which is not windows, so there has to be some things that can be done on one platform and not another. otherwise GEM just becomes a lowest common denominator of these platforms, and not a full featured app on any of them. if you don't take advantage of the strengths that each platform has, then why even bother making the app run on it in the first place?
cgc
hi folks,
i've been having a bit of break from the keyboard so apologies if i'm rehashing here... it looks like the yuv stuff is causing some really good discussion about GEM development. excellent!
i might hazard my opinion on some of the issues with yuv: - in general i suspect it's more costly to convert from one colour space to another to do a particular operation (say chromakey or lumakey) than it is to simply use that operation in the other colour space, even if it's a little awkward. this is even more the case if you then want to convert back to the original colour space. in the most extreme case, doing a pixel by pixel format conversion in the inner loop of the algorithm is going to be better than doing an image conversion and then running the algorithm. - as far as i can see, the only issues of platform/machine dependence with yuv are in the film codec and texture upload stages. format conversions can easily be included in the relevant objects when the underlying software and hardware do not provide the feature natively.
for these reasons (and for others more capricious), i would argue: - that all objects should be pix_XXXX objects. - all pix_ objects should operate on all image types (luminance, rgb, rgba, yuv), with the exception of the few objects which are truly format restricted (only those explicitly using the alpha channel i think) which should print an (accurate!) error message. - format conversions should only be done with explicit objects (pix_toyuv), except in image source (e.g. pix_film) and image sink (e.g. pix_texture) object where they may be done implicitly. - image sources should allow their format to be chosen through an argument or a message. they should announce the format when the image or film is loaded. should their default be system dependent to maximise performance, or system independent to maximise consistency? - a pix_info object should provide information at its outputs about the image passing through it: pixel dimensions, format and anything else relevant
it would be relatively easy to add pix_ base class automatic format conversion support as a stop-gap. this can be done with a nasty out-of-place conversion and reconversion with a performance warning printed to the console. this would allow this general behaviour to be acheived in the short term before implementing each pix_ object for each image format.
hmm i wonder if there are clever ways to use generic programming techniques to allow the algorithms to be implemented almost independently of the image format... and to allow new image formats to be added without adding code to the pix_s?
in general, i don't think that there's a really easy solution to automatic format negotiation in video data flow trees is there? i've done a bit of work with directshow on windows which tries to be very general and succeeds in being rather comlicated and hard to use...
daniel
chris clepper writes:
as ben pointed out: how about sending a "want YUV"-message to a proper [pix_film] and not having to worry whether you should need a [pix_filmBGRA_ext] or [pix_filmLUMINANCE] ?
that would work, but the question of feedback to the user remains. how do you make it clear which objects work with which color-space properly? and when do you need to convert? would this be automatic or user controlled?
the complexity really depends on the operation. for proper chroma-keying and color adjustment one must know about yuv color space. other functions like blurring, mixing and masking are just like their rgb counterparts.
so why segregating them ?
i think i've said this before:
At 6:35 PM -0600 12/16/02, chris clepper wrote:
here is my reasoning for making the [yuv_] set objects:
- a separate set of objects would be easier to leave out of compiles
for platforms that don't support it.
...
- there is not a one to one correlation between yuv and rgb color-spaces.
...
- Gem already had the pix_ naming convention which made it clear
that pix = image processing and that stringing pix_objects together would result in a functional chain. my initial attempts to extend pix to yuv seemed to destroy that, so i decided that yuv_objects would make their own chains to avoid confusion.
...
i was rather thinking of something like [pix_film] (on demand, tries to load YUV, if it fails (because the codec does not support it (is this possible), loads RGBA) -> [pix_yuv] (if pix_film returns YUV this does *nothing*, if we only have RGBA it converts to YUV) -> [pix_luma-key] (everything done in YUV-space) -> [pix_textureformat] (converts into a format that can be textured by the openGL-implementation - on macOS it might do nothing) -> [pix_texture]
ok. how about this: pix_film -> pix_luma_key -> pix_alpha -> pix_composite -> pix_texture
that's a total mess to mix and match yuv and rgba when you have alpha in one and not the other. i don't immediately see a good solution to this apart from lots of conversions that either happen in the objects automatically or a bunch of conversion objects added to the chain.
i can go on and on with examples like this, and would have to test all of these combinations if yuv_ is integrated into pix_. pix_ objects imply that they all work together, and that should be the case if yuv is added. also it seems like if conversion is going to be necessary for most situations and platforms then maybe it shouldn't be included in the CVS at all.
i will not have linux-only or macOS-only stuff in Gem as it is.
i just don't see how that's possible to maintain. osx is not linux which is not windows, so there has to be some things that can be done on one platform and not another. otherwise GEM just becomes a lowest common denominator of these platforms, and not a full featured app on any of them. if you don't take advantage of the strengths that each platform has, then why even bother making the app run on it in the first place?
cgc
--
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Tue, 24 Dec 2002, chris clepper wrote:
i will not have linux-only or macOS-only stuff in Gem as it is.
i just don't see how that's possible to maintain. osx is not linux which is not windows, so there has to be some things that can be done on one platform and not another. otherwise GEM just becomes a lowest common denominator of these platforms, and not a full featured app on any of them. if you don't take advantage of the strengths that each platform has, then why even bother making the app run on it in the first place?
I do not see why there should be things that can be done on one platform and on the other not. Actually I think that platform independency is very important for GEM.
I am not a specialist in graphics, but for me, YUV,RGB etc is just a different way of handling images, which boils down to additions, multiplications, etc...
Can you explain how the Operating System comes into play here ? Or is it the processor rater ?
Greetings,
Guenter
thank you
mfg.asd.r IOhannes
zmoelnig@iem.at:
i will not have linux-only or macOS-only stuff in Gem as it is. For things like this, i would recommend to have a look at gemee (but i would rather not fork development)
... you probably want to say that OS specific things as well as experimental stuff can be written as externals, just as in gemee, right ?
Guenter
(I can not remember that there are OS specific things in gemee, but rather very experimental gem objects).
guenter geiger wrote:
zmoelnig@iem.at:
i will not have linux-only or macOS-only stuff in Gem as it is. For things like this, i would recommend to have a look at gemee (but i would rather not fork development)
... you probably want to say that OS specific things as well as experimental stuff can be written as externals, just as in gemee, right ?
exactly. i really want GEM to run on all platforms with the same behaviour (but maybe not with the same performance) but i guess, it's not günter i have to tell this...(smile)
and i really do not want to lose the mac-people, now that they have done so much work...
(I can not remember that there are OS specific things in gemee, but rather very experimental gem objects).
i just thought that this should be the mechanism to do such things
mfg.as.dr IOhannes
guenter geiger wrote:
zmoelnig@iem.at:
i will not have linux-only or macOS-only stuff in Gem as it is. For things like this, i would recommend to have a look at gemee (but i would rather not fork development)
... you probably want to say that OS specific things as well as experimental stuff can be written as externals, just as in gemee, right ?
exactly. i really want GEM to run on all platforms with the same behaviour (but maybe not with the same performance) but i guess, it's not günter i have to tell this...(smile)
...right: I mean, we can't write altivec code for you to use, and vice-versa for ya'll and MMX! Also, we use different codecs and stuff, but that should all be transparent, anyway...
and i really do not want to lose the mac-people, now that they have done so much work...
hi IOhannes,
...don't worry: we're still here! Just got quiet for awhile during a little break ;-)
...I think chris and I have come around to putting everything into pix_*, but that means there will be alot of objects that don't have rgba functionality, which is kinda useless on macs now; also, I think it'd be to everyone's advantage to move to YUV processing, even if there is a last minute conversion before texturing, because of the reduced amount of data for manipulation, and the fact that most codecs are decompressed to yuv, then converted to rgba anyway (see libmpeg)...I'm also keen on the idea of having movie/film/video objects that change color space based on messages sent to them, but we've got alot of coding to make this all work...;-)
ok, end o'tirade/dreaming-out-load!
jamie
Quoting tigital tigital@mac.com:
...don't worry: we're still here! Just got quiet for awhile during a little break ;-)
...I think chris and I have come around to putting everything into pix_*, but that means there will be alot of objects that don't have
hey ! sounds like christmas has come back again.... very happy that this (yes: tiresome) discussion is obviously coming to an end.
mfg.as.rd IOhannes
Quoting tigital tigital@mac.com:
...don't worry: we're still here! Just got quiet for awhile during a little break ;-)
...I think chris and I have come around to putting everything into pix_*, but that means there will be alot of objects that don't have
hey ! sounds like christmas has come back again.... very happy that this (yes: tiresome) discussion is obviously coming to an end.
Did you read the rest of what he said?
At 2:22 PM -0500 1/7/03, tigital wrote:
but that means there will be alot of objects that don't have rgba functionality, which is kinda useless on macs now; also, I think it'd be to everyone's advantage to move to YUV processing
So that means someone will have to get cracking on the rgba code end for 40+ yuv_ processing objects. Which brings up another point about developing code for two color-spaces: does this require all developers to write their objects for both or do we just wait for someone to eventually come along and finish the implementation? Also, one developer might not know how to write yuv code and thus writes only rgb versions. Or another developer thinks yuv stuff is the only way to go and can't be bothered to write rgb versions. So now we have a large difference in which platforms can do what using the exact same objects. This is precisely the thing you have been railing against lately right?
The idea of auto-conversion in each object when one object lacks the code for one color space is a bad idea. The performance hit will be quite high and at that point you might as well do software openGL rendering as well.
So what other options does this leave? Dumping endless error messages in the console? Require the user to have lots of conversion objects in the render chain? How is the difference between the two made clear on the docs and in the pd patcher? And what clues will GEM give the user to alter the patch to preform correctly? I don't think an adequate solution has been devised yet.
cgc
mfg.as.rd IOhannes
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hi all,
Thinking out loud is always dangerous... particularly on-list... but I thought I'd throw expand on the generic programming idea I mentioned a while ago.
chris clepper writes:
The idea of auto-conversion in each object when one object lacks the code for one color space is a bad idea. The performance hit will be quite high and at that point you might as well do software openGL rendering as well.
As far as I can see, the best outcome is to have implementations of pix objects for luminance, BGR, RGBA and YUV images. It would also be useful (in the long run) to have the potential for images with floating point components rather than integer. How can these things be achieved?
I think that the golden rules as far as performance is concerned, are: 1) use the smallest possible representation 2) minimise copying (and therefore format conversion) 3) use the representation that best suits the operations in the render chain
Difficulties are: 1) golden rules can be contradictory... need to find best balance for any given render chain on any particular hardware. This would be rather hard to do automatically - although not impossible. 2) limited support for some pixel formats from codecs and textures in openGL (on some platforms) 3) nobody wants to write code for four (or more) pixel formats 4) this is inherently complicated 5) we want to achieve: - sensible (efficient, easy) default behaviour - easy probing to see what's actually going on with image formats - easy forcing of particular behaviour (ie force the use of particular formats and/or conversions to occur).
Idea: To minimise the coding effort for multiple formats by using pixel abstraction and generic programming.
Most pix_ type operations seem to work according to one of the following schemes: - step through each pixel, process pixel, write back pixel - take a whole pixel from one part of the image, write whole pixel to another part of the image
Can the algorithms be abstracted away from the pixel format to reduce the effort of coding the image processing algorithms? They can to some extent. - If whole pixels are being moved around then the format isn't important to the algorithm if there's the notion of a generic pixel object. - Pixel by pixel conversion to/from a standard format could be done when the image (or pixel) is accessed and component level processing is done. The format would probably be RGBA. This is how some systems do pixel format abstraction I think. - Pixel processing usually uses one or more of the following values: red, blue, green, alpha channel luminance chrominance saturation, lightness (or value or ...) The values used are usually part of the algorithm... and should be chosen according to the algorithm rather than the pixel format... the pixel object class should be able to provide these values for any pixel (regardless of its underlying format). Perhaps the pix_ object can be interrogated to find its preferred pixel format.
If this is done using generic programming techniques, then the polymorphism can be collapsed at compile time, so the code can be quite efficient... and the compiler can do loop unrolling or whatever tricks it knows how to do. It would also be possible to provide optimized implementations for particular formats, if so desired, which would allow MMX/ altivec to be added.
These things might actually make it quite easy to write fast pix_ objects quickly... and get versions for each pixel format from the same code.
Is this all a load of baloney, or does anyone think it might fly? It seems to offer the possibility of implementing each pix_ object using the most suitable format and getting implementations for other formats automatically. The performance for the preferred format should be as good as a direct implementation (?) and the performance of the other formats should be reasonable (?)
I'll hack together some non-GEM based code to explore this idea. I'll let you know how it goes...
Daniel
Zitiere chris clepper cclepper@artic.edu:
Did you read the rest of what he said?
Hi
At 2:22 PM -0500 1/7/03, tigital wrote:
but that means there will be alot of objects that don't have rgba functionality, which is kinda useless on macs now; also, I think it'd be to everyone's advantage to move to YUV processing
So that means someone will have to get cracking on the rgba code end for 40+ yuv_ processing objects. Which brings up another point about
well, yes
developing code for two color-spaces: does this require all developers to write their objects for both or do we just wait for someone to eventually come along and finish the implementation?
depends on you. of course it would be great if you would write for all colourspaces, but i don't think anyone can force you to do so (esp. if it was very simple in (say) YUV-spcae but very complicated in RGBA)
anyhow, i think that a large number of algorithms can be extended to any colourspace (daniel's mail). use processImage() then
Also, one developer might not know how to write yuv code and thus writes only rgb versions. Or another developer thinks yuv stuff is the only way to go and can't be bothered to write rgb versions. So
;-)
now we have a large difference in which platforms can do what using the exact same objects.
i don't think so. YUV-processing (not necessarily displaying) should be easy on *any* platform..
btw: has anyone tested this [pix_yuv] object already ?
This is precisely the thing you have been railing against lately right?
does "railing" means "insulting you" ? if so, sorry
The idea of auto-conversion in each object when one object lacks the code for one color space is a bad idea. The performance hit will be quite high and at that point you might as well do software openGL rendering as well.
right.
So what other options does this leave? Dumping endless error messages in the console?
Which is a start, though maybe not very user-friendly
Require the user to have lots of conversion objects in the render chain?
what do you intend to do ? i do think, in practice there might never be more than 3 or 4 conversions, normally only 1 (or 2). As you have pointed out already, most codecs will have to convert YUV2RGB(A) anyhow, so we might gain one conversion here and lose it somewhere else (on some platforms)
How is the difference between the two made clear on the docs and in the pd patcher?
Which difference ? How is the difference between linear and logarithmic (dB) values made clear to pd-users. or between frequency and MIDI-note-numbers. Does this imply some a-priori-knowledge. But of course, these are very rude comparisions
And what clues will GEM give the user to alter the patch to preform correctly? I don't think an adequate solution has been devised yet.
right, something to do for us (or me :-()
of course, conversion objects could be used, but what if an object's possibilites are extended and it suddenly supports more colourspaces that would make conversion superfluous or (of course) things worse. Will then have to make some possibility to broadcast an objects favoured colourspace up the rendering chain, so that conversions could be muted.
and make a stupid [pix_convert] object that has to be inserted between all other [pix_]-objects and does (optional) conversion to the wanted colourspace. Unfortunately, this sounds ridiculous somehow. And/or make [pix_rgba] et al. do optional conversion by default which can be overridden by a "force"-flag.
maybe it could be a flag for the [gemhead], that says: "do automatic conversion if needed". I think, users should know that conversions take time and setting this behaviour to the default might be a "not so good" idea, since people wouldn't know that they were doing something nasty but would wonder why on earth their brandnew PC was *so* slow.
anyhow, i'm sure there will be some way to device an adequate solution...
mfg.cdsa.rs IOhannes
On Tue, 7 Jan 2003, chris clepper wrote: <snap> .....
writes only rgb versions. Or another developer thinks yuv stuff is the only way to go and can't be bothered to write rgb versions. So now we have a large difference in which platforms can do what using the exact same objects. This is precisely the thing you have been railing against lately right?
No, writing code for YUV colorspace is not something platform specific. If the scenario you are painting happens, then these algorithms will be available for YUV colorspace only, but on every platform. (unless, of course, you write them in ALTIVEC).
Finally, to bring a real world example, I am happy that Mark didn't write GEM platform specific for SGI's ... we all know why. Platform specific code is bad and should be minimized.
I think that Daniels thoughts about how to handle all of this are very interesting ..
Greetings
Guenter
Hi !
Zitiere bbogart@ryerson.ca:
Hey guys,
As for naming, how about pix_foo_yuv for the yuv versions of the objects..
what i just wanted to make clear, is that there should not be any difference between rgba- and yuv- processing (i have heard this before) rgba-objects are not called rgba_foo or pix_foo_rgba either, nor do grey-objects maybe i will have some christmas-days and come back with a completely changed mind. who knows ?
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.
kind of what i thought.
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.
this is exactly what i want. (and what it does now)
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.
well, i'm not part of the GUI-fraction of pd-users...
mfg.a.r IOhannes
-
bbogart＠ryerson.ca -
chris clepper -
daniel heckenberg -
guenter geiger -
IOhannes zmoelnig -
tigital -
zmoelnig＠iem.at