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

[chris clepper]

>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



--