= 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 `ufo-core`,
* bindings to other dynamic languages in `ufo-bindings` and
* concrete applications in `ufo-tools`

The core library provides an object-oriented API based on the platform-independent libraries [http://library.gnome.org/devel/glib/ GLib] and [http://library.gnome.org/devel/gobject/stable/ GObject].

== 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 and raw data formats
* Base image type consists of single-channel (grey values), 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

* Point operations
  * Basic math
* Tomography-related
  * FFT
  * Filtering
  * Back-projection

== 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,
* size in bytes of each element and
* 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.

A ''Filter'' accepts zero (then acting as a ''source'') or more input Buffers, computes on the Buffer's data and places the result in zero (acting as a ''sink'') or more output Buffers. When the result is ready, it notifies all connected outgoing Filters which take their input from the respective output.

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.