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