Editing docs_architecture

= 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 * 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, * 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. === Plugins === A plugin is a shared object with well-defined entry functions and a set of filter functions. The main purpose is interfacing with other graphics processing libraries or languages without having access to the sources of the core library, for example * OpenCV, * ImageMagick. A plugin must provide * `plugin_init(void)` to initialize the plugin if needed, * `plugin_destroy(void)` to free any structures created by the plugin, * `plugin_get_filter_names(void)` to return an array of filter names that are provided by the plugins and are also the corresponding function names to call, * `plugin_get_filter_description(char *filter_name)` to return a human-readable description of the purpose of filter `filter_name` and * `filter_foo(char *data, int32_t width, int32_t height, int32_t bytes_per_pixel)` to call the filter. On the UFO side a plugin is loaded by creating an UfoPlugin object and passing the name of the .so file. An UfoPlugin is a relatively thin wrapper that just calls `dlopen()` (or the respective equivalent on other operating systems) to load the shared object and returns UfoFilters by reading the function pointers according to the filter name.