= 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 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.