[PD-dev] [GEM] more on YUV (was: postrendering crashes)

[zmoelnig at iem.at]

Zitiere chris clepper <cclepper at 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