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