Changes between Version 3 and Version 4 of docs_architecture


Ignore:
Timestamp:
Apr 9, 2011, 6:21:21 AM (15 years ago)
Author:
Matthias Vogelgesang
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • docs_architecture

    v3 v4  
    33The 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
    44
    5 * the core library ''libufocore'' in `ufo-core`,
    6 * bindings to other dynamic languages in `ufo-bindings` and
    7 * concrete applications in `ufo-tools`
     5* the core library ''libufocore'' in `core`,
     6* bindings to other dynamic languages in `bindings` and
     7* concrete applications in `tools`
    88
    9 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].
     9The 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].
    1010
    1111== Specifications and Requirements ==
    … …  
    1515* Object-oriented interface implemented in C
    1616* Language bindings to at least Python
    17 * Loads TIFF, EDF and raw data formats
    18 * Base image type consists of single-channel (grey values), single precision, 32-bit floating point pixels
     17* Loads TIFF, EDF, HDF5 and raw data formats
     18* Base image type consists of single-channel single precision, 32-bit floating point pixels
    1919* Multi-threaded
    2020* GPU-capable
    2121* As light and fast as possible
    2222
    23 Furthermore, the core library must provide the following basic algorithms
     23Furthermore, the core library must provide the following basic algorithms as a set of filters:
    2424
    2525* Point operations
    … …  
    4242* number of dimensions,
    4343* length of each dimension,
    44 * size in bytes of each element and
    4544* a flag if a valid GPU representation is available.
    4645
    … …  
    5251* associated file name and type.
    5352
    54 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.
     53Such meta-data depends on the actual filter and is added to the filter object as a GObject property rather than a simple field.
     54
     55It 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].
    5556
    5657An 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.
    … …  
    5960=== Plugins ===
    6061
    61 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
    62 
    63 * OpenCV,
    64 * ImageMagick.
    65 
    66 A plugin must provide
    67 
    68 * `plugin_init(void)` to initialize the plugin if needed,
    69 * `plugin_destroy(void)` to free any structures created by the plugin,
    70 * `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,
    71 * `plugin_get_filter_description(char *filter_name)` to return a human-readable description of the purpose of filter `filter_name` and
    72 * `filter_foo(char *data, int32_t width, int32_t height, int32_t bytes_per_pixel)` to call the filter.
    73 
    74 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.
     62Every 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.