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

[zmoelnig at iem.at]

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