Software Architecture

The UFO software framework is a set of building blocks to easily create image processing applications with high-speed demands. Its source code resides in a public Bazaar repository? and documentation is available under the ​API link. On source level, it is conceptually divided into

• the core library libufocore in core,
• bindings to other dynamic languages in bindings and
• concrete applications in tools

The core library provides an object-oriented API based on the platform-independent libraries ​GLib, ​GObject and ​ethos.

Specifications and Requirements

If the following requirements are met, the API can be declared reasonably stable and applications can build upon the public interfaces:

• Object-oriented interface implemented in C
• Language bindings to at least Python
• Loads TIFF, EDF, HDF5 and raw data formats
• Base image type consists of single-channel single precision, 32-bit floating point pixels
• Multi-threaded
• GPU-capable
• As light and fast as possible

Furthermore, the core library must provide the following basic algorithms as a set of filters:

• Point operations
  • Basic math
• Tomography-related
  • FFT
  • Filtering
  • Back-projection
• Laminography-related

Design

The basic abstractions are

• Elements that get aggregated to a nested graph structure,
• Sequences and Splits defining how child elements are ordered,
• Filters in leaf Elements that act on data and
• Buffers representing data with all its associated meta data.

Furthermore a Resource Manager creates and distributes resources such as Buffers, OpenCL memory and kernel objects, etc.

A Buffer is bound to an OpenCL device and returns its data either as a simple float pointer or an OpenCL memory object. A source Filter (which has no input but generates an output stream of data) requests a Buffer object from the Resource Manager, fills the data and pushes it to its output queue. The next Filter pops this Buffer uses the data and pushes it again until the last Filter releases the Buffer object to the Resource Manager for further recycling.

Container elements such as Sequences and Splits also take the buffer from their input queue but distribute it according to their semantics:

• A Sequence just pushes the data to the first child filter
• A Split pushes the data according to its mode of operation, specifically it could
  • push the data in round-robin fashion,
  • push the data randomly to its children or
  • copy the input and distribute these copies.

The following image sketches the components and a simple configuration:

Each Element and Filter provides a finished GObject signal, notifying all subscribers that work has finished and the Element or Filter is not going to push more data. In particular, a Filter notifies its container Element and the specialized Splits and Sequences relaying that signal to all its children.

Plugins

Every filter has the parent UfoFilter which in turn is derived from EthosPlugin. Therefore, each filter is a plugin and loadable at run-time. Right now, only one distinct EthosPlugin can be instantiated at a time, which means that stateful filters should only be used once. In the future we are going to use the similar libpeas library which, however, requires gobject-introspection-1.0 that is currently not in the openSUSE 11.3 repositories.