×

Terminal Output

  • Welcome
  • Standards Discussion
  • Contact
  • Ofx small
  • Welcome
    • Why a Standard?
    • For Implementers
    • Association Business
  • API Documentation
    • API Reference
    • Programming Reference
    • Programming Guide
  • Standards Discussion
  • Contact
Back to standard change list


Clip Preferences and Temporal Invariance Proposed

Standard version: 2.0

Major Change

Several aspects of the API were, in their original conception, perceived to be fixed for the whole temporal duration of an effect, and generally under the control of the application. This, unfortunately, is not true, and has caused problems for various plug-in hosts and developers.

Initially this consisted of what pixel formats and data types were present on input clips and how they should be munged for the plugin, thus the the clip preferences action. Various other properties that were thought to be temporally invariant were added to the action.

The changes suggested here would lead to the death of the clip preferences action.

Data Formats

A plug-in still needs to specify the data format on it accepts data in and what it outputs. To this end. This should be done by a new kOfxImageEffectActionGetPixelFormats action. This would be similar to the current kOfxImageEffectActionGetClipPreferences action, except that….

  • it can be called per frame
  • the inargs include the effect time to calculate the data format at,
  • the out args only consist of the properties to indicate pixel type and component type.

This needs to be worked in with the suggested plane extensions in a consistent way.

A corresponding call is needed in the image effect suite, that reports the data format of a clip at a specific time, something like clipGetPixelFormats

A property should be available on plug-in and host indicating if they support per frame data formats. If not, the behaviour is the equivalent of the old API.

Note that, as they can now vary with time, we should then remove the following properties from clip, as they need to be fetched at a time via the clipGetPixelFormats,

  • kOfxImageEffectPropComponents
  • kOfxImageEffectPropPixelDepth
  • kOfxImageClipPropUnmappedPixelDepth
  • kOfxImageClipPropUnmappedComponents

Temporally Invariant Attributes

Some effect attributes are temporally invariant, these are the remainder of the properties of the clip preferences argument, being….

  • the frame rate,
  • the field order,
  • whether the effect can be continuously sampled,
  • whether the effect is frame varying.

This could be done in one of two ways, either by another action, which the host calls when it needs to, or by having properties on the effect instance that are set by the plug-in in response to parameter changes.

Back to standard change list


Discussion

Comments

"munged"? Do you mean "managed"? I hope not munged: http://whatis.techtarget.com/definition/munge

Dennis Adams | 11:49 am, 25 Aug 2016

There is no mention about the pixel aspect ratio. Some image sequences may contain in rare cases images with varying pixel aspect ratio

Alexandre | 11:28 am, 25 Aug 2016

(Pierre Jasmin):  I can conceive a system that supports for example dropping an effects for the duration of a video track that is made of different clips with different properties. As a result the attributes including temporal ones could be changing over time. Is there really a need for per frame evaluation here or we only have to deal with "cuts" in terms of Attributes? If it's only cuts seems the individual cuts should return time in local effects time (starting at 0) and the Timeline suite support returning time in timeline domain. No?

to do: Need an example of "per frame" potential  meaning

Pierre Jasmin | 3:13 pm, 6 Jun 2015
  • Pierre Jasmin : Give me an example where the pixel depth, components,… would need to vary over time
  • Bruno Nicoletti : It's not a case about needing to, it is whether the host behaves that way. For example in Nuke, you can easily have a node with different sets of image data available at different times. I believe that Fusion is similar.
  • Pierre Jasmin : In some app it's possible to have effective frame rate vary over time (e.g. after effects api - local time step vs time step)
  • Bruno Nicoletti : not all aspects of all applications need to be replicated, a variable frame rate is probably applicable to only a very few apps, but I could be wrong.
unattributed | 9:49 am, 8 Mar 2014
Back to standard change list
  • OFX @ Github
  • Association Information

Copyright ©2023 The Open Effects Association