There is little to no information about the colour space (tone curve and RGB chromaticities) in which image sample values are to be interpreted.
Historically there has been some assumption that the tone curve is probably linear, with a nominal black point at 0.0 and nominal white point at 1.0, but this is not specified and is often not the case.
Depending on the host, unmodified images presented to plugins may be linear, or "video" (typically Rec.1886, or a simple gamma curve), or "log" (e.g. Cineon log, or a modern log curve such as ARRI LogC), or "HDR" (e.g. Rec.2020) or any number of other curves. The primaries may be Rec.1886, or a larger gamut such as Rec.2020 or ARRI WideGamut. Plugins have no way of knowing what the numbers in the image represent. Similarly hosts have no way of knowing in which colour space(s) (if any) a plugin would like its inputs, nor the colour space of its output image.
Some plugins won't care what space the images are in. Some however need to know in order to make sense of the data. A lens flare, for example, needs to behave very differently (a) when the input data is linear with highlights well above 1.0 (b) when the input data is log-like with highlights preserved but much lower in the range, (c) when the input data is in a display-referred colour space where highlights have been rolled off to fit under 1.0.
It may be that some plugins and/or hosts prefer to work with non-RGB primaries, e.g. X'Y'Z'. A mechanism to specify colour spaces could support this.
At first glance I'd suggest
Define strings to identify well-defined tone curves, and well-defined sets of primary chromaticities. This is necessarily vague since without defining tone curves using formulae we can't offer general support. Chromaticites could be identified precisely as three (x,y) coordinates but that might be too much?
Add kOfxImageClipPropToneCurve and kOfxImageClipPropPrimaries properties to clip property sets to identify the colour space of the clip, if known
Add kOfxImagePropToneCurve and kOfxImagePropPrimaries properties to image property sets to identify the colour space of the data, if known
Hosts set these properties where they know the colour space of input clips
Define a protocol so plugins can request that input clips are converted by the host into a specific colour space
Define a protocol so plugins can identify the colour space of their output image (during setup time, before rendering)
Here's notes from last meeting -
-> Some “simple” color space enumeration clip properties could be immediately useful (Log-like [e.g., S-Log, ACEScc], Gamma-like [e.g., Rec.709, Rec.2020], linear 0-1 [needed?], linear HDR [e.g., ACES]).
-> Some “detailed” color space clip properties could be useful down the road (named gamut [e.g, “Rec.709”, “Rec.2020”, “ACEScc”), named curve [e.g., “Rec.709 gamma”, “HLG”, “PQ”]). Perhaps even primaries coordinates, optional white point. Hard to pass curve definition math though.
-> It would be useful for a plug-in to indicate which simple color spaces it can work in, and hosts converts if possible (e.g., Lift/Gamma/Gain color corrector prefers Log-like or Gamma-like curve and cannot work in Linear). Alternatively, this could be indicated in getClipImage like some other clip properties are. In either case, it is optional and the host does not have to do this conversion.
-> Can a plug-in change the color space of an output clip? Many hosts would not be able to deal with this; can we table for now?
(Pierre and Fabien add): there is also the topic of color picker - color parameter relation to that