Zitiere chris clepper cclepper@artic.edu:
Hey guys,
As for naming, how about pix_foo_yuv for the yuv versions of the
objects..
i initially started writing the yuv stuff like that. there is still a pix_filmYUV hanging around.
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] ?
As for YUV in general I think it would only be used by more advanced users, mostely because the colorspace is imply that much more difficult to get your head around. As such I would say objects should be rgb by default and the yuv choice only comes in when you know you want it.
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 ?
pix_film (yuv->rgba) * 2 -> pix_luma-key (rgba->yuv->rgba) -> pix_texture
compared to keeping it in yuv:
yuv_film -> yuv_luma_key -> pix_texture
the first one is doing a hell of a lot of pointless work to get the same thing done. i pick the second method.
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]
this is exactly two more objects ([pix_yuv] and [pix_textureformat]) and one more message for the pd/gem-programmer to create, and does not cost "anything" (apart from void function-calls, which i don't take into account with respect to image-processing) on platforms that provide YUV-space and does cost more on platforms that don't, but hey! it is portable my primary goal with Gem is to have a platform for graphics that is supported by many OS's and does exactly the same on all OS's i will not have linux-only or macOS-only stuff in Gem as it is. For things like this, i would recommend to have a look at gemee (but i would rather not fork development)
mfg.ds.r IOhannes