Changes between Initial Version and Version 1 of docs_architecture

Timestamp:

Feb 16, 2011, 8:57:57 PM (14 years ago)

Author:

Matthias Vogelgesang

Comment:

--

docs_architecture

@@ +1 @@
+= 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.