Desired Premult. about openfx HOT 3 OPEN

Could we take advantage of the current set of properties? What if the host sets kOfxImageEffectPropPreMultiplication on the output clip to specify its desired premul output. The plugin can read this and obey it, but is still allowed to change it.

from openfx.

This is meant as a global flag sort of.

TRUE there is a read-write for output in doc in kOfxImageEffectActionGetClipPreferences
During render these properties are read-only

https://openfx.readthedocs.io/en/doc/Reference/ofxImageEffectActions.html#group__ImageEffectActions_1gae66560a2d269b17e160613adf22fd7d0

"This should be called once after creation of an instance, each time an input clip is changed, and whenever a parameter named in the kOfxImageEffectPropClipPreferencesSlaveParam has its value changed. "
//
This is meant even when we create instance, now I have a premult boolean checkbox in many tools, would check if TRUE or FALSE based on this flag and even hide the checkbox if this property is supported.

Unless I was putting a bunch of code to calculate this in clip preferences action I would likely just set output if input is Opaque to DesiredPremult. There could be a doc note added for ClipPreferences about that, yes.

from openfx.

Ok here's my suggestion

We add a cross reference in doc/comments for the ClipPreferences kOfxImageEffectPropPreMultiplication the premultiplication of the output clip

whereby if DesiredPremult prop is supported (status == 0) then host is expected to set DesiredPremult on output clip. Plugin can over-write back to Opaque. Only in that circumstance then an host can safely carry-on Opaque further down than direct imported source images or conversion from 3 channels to 4 for plugin. This way it's safe, does not potentially break anything (turns undefined into a bug) as there is conditional on a new property being supported.

Nothing in the API specs envision an host would be responsible to convert a plugin setting Straight to Premult... i.e. Plugins are expected to handle both cases. We are just making sure which case is perfectly clear.

Pierre

from openfx.