home contents changes options help

last edited 5 years before 2009

by Bruno Nicoletti 4/28/04

Ownership

OFX is a plugin API for effects on moving imagery. It was developed and is owned by The Foundry Visionmongers Ltd, but been released under a BSD style Open Source license. It was developed with broad consultation within the industry.

Core Architecture

OFX is a C API that is defined purely by a set of header files. There are no host side symbolic dependancies, no libraries to link against and only two symbols that a plug-in must export.

The core elements of OFX can be used to implement any kind of API, for example a sound effects API, an image import API or even a spell checker API. This core architecture has been used to define an API for processing images in a visual effects host. Both the API and the plug-in implemented with it are strongly versioned,

In all cases, OFX uses a simple message passing mechanism to drive a plug-in. This mechanism is flexible, generic and easily extensible in a backwards compatible manner.

Hosts functionality is supplied via named and versioned suites, which are a related set of functions encapsulated as pointers in a C struct. A variety of suites are defined by the API, for example the property suite allows a plug-in to get and set properties on various objects while the parameters suite is used to define and manipulate user visible parameters. This suite mechanism allows for backwards compatible extension to the API and for hosts to provide custom extensions. There are currently six mandatory suites that an image effect host needs to provide.

Image Effects API

The OFX Image Effects API supports imagery of the following bit depths

  1. 8 bit integer
  2. 16 bit integer
  3. 32 bit floating point images.

The following component types are supported

  1. four component RGBA pixels,
  2. single component alpha images.
  3. four component YUVA images (optional).

A host or plug-in must support at least one of the bit depths and the RGBA pixel type.

There are three kinds of image processing architecture that OFX supports. These are

  1. full frame processing of images all the same size in the same location,
  2. full frame processing of images of multiple resolutions at arbitrary positions,
  3. tiled processing of images of multiple resolutions at arbitrary positions.

What level of architectural support is provided is up to the host or plug-in. However a host (or plugin) may refuse to interoperate with a plugin (or host) that does not provide enough support.

The Future

Many things have been deliberately left out of version 1 of the API, to avoid holy wars and speed up the initial definition. The following are being actively considered for V1.1 of the API

  1. support for non colour image data types (e.g: vectors, normals, object IDs, z depth and more),
  2. dynamic parameter creation
  3. exotic parameter types, splines, 3D cameras, lights,
  4. hardware accelerated GPU based rendering.


comments:

A good start -- Thu, 29 Apr 2004 14:31:33 -0700 reply
Your document is a good start. I have a number of questions.

  1. Is the OFX API solely based on structs of function pointers?
  2. The document doesn't give any why. Why fptrs instead of COM? Why not variargs? What other design approaches were considered? I'm not saying to go into the reasons to any depth in the document, rather that they should be touched upon so you avoid a lot of repetitive questions of the form, "Did you consider blah, blah, blah?".
  3. Are plug-ins in the same process space? If a plug-in is talking to a separate process or a remote machine how does it transmit through a fptr? Does it access shared memory or copy tiles?
  4. The channel types supported seem inadequate and rigid. Support for future GPU programming is suggested, but there is no Half float GPU type. Nor is there 32-bit unsigned type for Z. Both of those types are supported in OpenEXR. Another type missing is binary unsigned, a Pixar-developed HDR format (0 to 2.0) used at DreamWorks and elsewhere for rendering.
  5. Since adding types to an API is cumbersome, have you considering passing data as a void* and having a type field that specifies what it should be cast to on the other end?
  6. The OFX channel layout seems inadequate and rigid. How will it support systems that do not interleave RGBA but layout each channel in its own buffer?
  7. As with channel types, why is channel architecture hard-wired to the API? What about Z channel?

After the Architecture Overview the next thing a new user would logically want to read is a "Hello World" example. I can think of two basic examples I'd want to see: a raw RGB file reader/writer and a blur filter. Are there a couple minimalist examples of those available?

Thanks!

Robin Rowe

"Hello World" example -- Tue, 11 May 2004 07:59:51 -0700 reply
The OFX website has some simple "Hello World" type OFX plugins packaged together w/ their Hedgehog OFX server. It is available for download at: http://www.thefoundry.co.uk/OFX/Hedgehog_Overview.html

Andy Prock