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 most basic abstractions are

• Filters that act on data and
• Buffers representing data with all its associated meta data.

A Buffer hides all details about memory management (be it CPU host memory or GPU memory) and provides a common interface for querying meta data and a pointer to the raw data. The meta data must include

• number of dimensions,
• length of each dimension,
• a flag if a valid GPU representation is available.

and could include meta data like

• what kind of special image type (sinograms, images in frequency domain etc.) it is,
• mutex(es) for shared access of threads,
• alignment and
• associated file name and type.

Such meta-data depends on the actual filter and is added to the filter object as a GObject property rather than a simple field.

It is assumed, that the base data type for each pixel is 32-bit single-precision floating point, which means that source data must be converted and scaled to the range [0.0,1.0].

An ubiquitous scheduler sets up the threading system and connected hardware accelerators like GPUs. As this is the only instance that knows where Filters can run, it should decide if a Filter should run on the GPU by inspecting the chain of computation. Furthermore, if a Filter does not need to work on a whole buffer (that means data is separable), the scheduler might also split the Filter by creating two or more instances and provide them with split data.

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.