On Friday 21 September 2012 11:12:01 Steinar H. Gunderson wrote:
> This should probably not be a per-plugin parameter, though; color space
> should be part of the API (and it should be at the caller's discretion to
> choose, not the plugin -- it wouldn't be an unreasonable demand to have all
> inputs' color spaces be equal to the output color space, though).
>
> What to do about non-colorspace aware plugins that need to mess with pixels
> is an open question; they should probably be marked as such. You could
> maybe argue that Frei0r should convert to/from sRGB around the plugin, but
> I doubt it's worth it.
>
> /* Steinar */

As Poynton said, there is no exact colorimetry in video.
So I think we should not try to make any attempt in that direction, and even
allow ourselves some sloppiness (freedom), to keep things simple.

Many plugins, like geometry transforms, blurs, sharpens, etc. do not need to
worry about colorspaces, and are in this respect "universal".

What I had in mind were those plugins that, for example, need to do luma
separation for some reason, the trivial example being "convert to B&W".
These plugins profit from a hint about what primaries were used to make the
video fed to them, just to avoid gross errors, not to achieve any colorimetric
precision.

Marko Cebokli