[PD-dev] [GEM] more on YUV (was: postrendering crashes)
cclepper at artic.edu
Tue Dec 24 20:06:58 CET 2002
>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
>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
More information about the Pd-dev