-
Notifications
You must be signed in to change notification settings - Fork 120
Developer FAQ
OpenFX is a C programming language protocol designed to enable a host application and a plug-in (a shared library) to establish a communication in order to extend functionalities of the application. One of the reason it has been designed is for different vendors and software editors to share a common low-level protocol. It has been primarily developed to enable developers to extend an imaging software with 2D image processing plug-ins, but the protocol is generic enough to be extended to any other type of application, such as audio processing, etc... The protocol is cross-platform and should work with most existing operating systems.
OpenFX is controlled by an association of software editors and open-source organizations. The main web-page is http://openeffects.org. Modifications and enhancements to OpenFX are reviewed by all members before being integrated to the common standard.
A good documentation has been written by Bruno Nicoletti here
There is none at the moment, but an example implementation can be found on the official Github repository of the OpenFX association
See the wiki entry here
If a property of a Clip Instance is supposed to be checked on the output clip as-well, e.g: kOfxImageEffectPropPreMultiplication, make sure it is not accessed within the action that is supposed to compute its value. Reasoning is some properties on the output clip can only be inferred by the result of an action on the very same ImageEffect instance that’s inspecting the property on the output clip. In some situations, if the property inspected is called in the wrong action, this can lead to infinite recursion or unspecified behavior.
For example, kOfxImageEffectPropPreMultiplication on the output clip can only be known on after the kOfxImageEffectActionGetClipPreferences action has returned. Any of the properties set by the kOfxImageEffectActionGetClipPreferences inspected on the output clip during that same action is likely to be wrong, or at best, a good guess from the host.
This may not be clear for a plug-in developer when a property is allowed to be accessed and when not, also it may vary a lot depending on the host application.
The best practice for future reference is to document those corner case in the standard and to avoid using the output clip as much as possible and instead use the ImageEffect instance.
On the host application side if a function is unsupported in a suite, set it to NULL instead of adding the function pointer. A plug-in being used in such host may want to know before calling the actual function whether the function actually does something or if it is unimplemented, for example to hide some parameters or exclude some functionalities. E.g:
struct OfxTimeLineSuiteV1 gTimelineSuite = {
TimeLineGetTime,
NULL /*TimeLineGotoTime*/,
TimeLineGetBounds
};
When a plug-in is loaded in the kOfxActionLoad action, if kOfxStatFailed or kOfxStatErrFatal is replied, the host is expected to silently ingest that, not load the plugin and not put up a popup warning to user.
When a host does not support a property (e.g: kOfxImageEffectPropFrameRate), whenever accessing this property it should reply as if the property did not exist, for example kOfxStatErrUnknown and not an undefined value. If a host doesn’t support a parameter type, a similar error should be returned.
This way a plug-in can thoroughly inspect a Host by checking the standard properties to enable/disable features for that Host.
A plug-in that reports kOfxImageEffectPropOpenGLRenderSupported = "true" can have its property set to "false" by the host, but the host must let the plug-in know about it with a call to the kOfxActionInstanceChanged action.