-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Desired Premult. #66
Comments
See #66 which we used as a test case for developing this template.
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. |
This is meant as a global flag sort of. TRUE there is a read-write for output in doc in kOfxImageEffectActionGetClipPreferences "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. " 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. |
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 |
Standard Change Workflow
standard change
tagfeature/PROPOSAL-NAME
branchmaintainer merges PR to master which closes PR and issue
Requirements for accepting a standard change:
Summary
Add a new plugin property that hosts can set to suggest that effects should premultiply their output.
Motivation
The standard currently has premult properties for input clips; however there is no way for the host to communicate to a generator plugin, or a plugin taking only an opaque or RGB input, whether it should premultiply its output or not.
Explanation
This effect property allows an effect generating alpha to know whether to output premult or straight alpha. If the input is
ImageOpaque
or the effect's type isGenerator
it can't use its input(s) to know this.The value is only advisory; the effect may or may not check this property and may in any case create output clips of any premultiplication state.
Effects using this property should still tag their outputs with the correct premultiplication state.
The property is set on the image effect's effect instance.
Context
This property, when set by the host, should be set during the following calls:
kOfxImageEffectActionBeginSequenceRender
kOfxImageEffectActionRender
kOfxImageEffectActionEndSequenceRender
Valid Values
kOfxImagePreMultiplied
kOfxImageUnPreMultiplied
Documentation Impact
see pull request #62: Desired Premult
The text was updated successfully, but these errors were encountered: