= 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 [wiki:infrastructure_rcs Bazaar repository] and documentation is available under the [http://ufo.kit.edu/ufo/doxygen/ 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 [http://library.gnome.org/devel/glib/ GLib], [http://library.gnome.org/devel/gobject/stable/ GObject] and [http://git.dronelabs.com/ethos 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:

  [[Image(architecture.png)]]

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.