This project is read-only.
The documentation is currently under construction. If your desired topic is not covered yet, please check back soon. If you have urgent questions please contact us.

NIPO Product Documentation

The NIPO class reference provides an overview and detailed documentation of all classes contained in NIPO.
Download the Class Reference below (CHM)
NIPO Documentation.chm

NIPO basics

NIPO is a component framework, i.e. the functionality and application purpose is determined by its plugin modules NIPO is written in pure and is compatible to Mono.
Bascally, NIPO can be used for applications that (at least roughly) follow the IPO- (Input, Processing, Output) principle. It allows to define Plugins for Input, Processing and Output. A basic NIPO configuration consits of at least one Input Plugin, and one Output Plugin. Between input and output a processing plugin may perform operations on the data stream. Data in NIPO is passed between plugins using an event--based system.
The image above gives an overview on NIPO. The processing chain itself is actually a processing plugin to chain up multiple procesing plugins. The result of the data processing operation is passed to multiple output channels.
Additionally NIPO also uses service plugins (which essentially provide services to the other plugins like data lookup) and observer plugins (that have no predefined function and thus can be used for almost everything).

Plugin types

NIPO defines three basic and two advanced types of plugins. Input-, processing- and output-plugins are the basic plugin types. They build the NIPO processing chain. Data flows from input through processing to the output plugins. Service and observer plugins are advaned types that are not immediately necessary to run NIPO instances.
Service plugins provide certain services to plugins (like shared data or utility functions). NIPO defines a generic service discovery mechanism that can be used to search for a certain service. If the service type is known in advance, a plugin can also search for a service by its (.net-) type.
Observer plugins have no predifined functionality. They act as pure event handler and are invisible to other plugins. Using the generic event descovery mechanism they can catch events in NIPO. This enables to extend the core NIPO functionality. As an example, think of a plugin that collects statistics on the data flow (how many bytes of data are processed, what is the system load, ...). Such a plugin would be implemented as an observer and just consume internal events. There are various other application scenarios for observer plugins like providing a user interface (this may also be done by an output plugin) or providing instance dependent services to an external application.
For more information on service and observer plugins pleas see AdvancedNIPO

Plugin communication

NIPO plugins communicate via events. There are predefined events for the IPO chain plugins to pass data from one stage to the other. For each data packet that an input plugin produces it raises an event. This event is then handled by the processing plugin. Event dispatching can be done synchonously and asynchonously (this can be configured on a per-plugin basis). Each plugin can define its own events and use an event-registrar to make it accessible to other plugins. Using this you can define your own communication flow within NIPO (like loopbacks and branches). See the AdvancedNIPO page for more details

Some examples

  • Receiving and displaying a multi-source video file
Scenario: A video consists of an audio stream and a video stream. Each stream is stored on a seperate server. In order to view the video properly, the audio and video sources must be retrieved in parallel. The video should be displayed at the client and, at the same time, the video should be stored in a file.
Solution with NIPO: We need a general purpose Input plugin, that retrieves binary data from a network stream. We take two instances of this input plugin, one for audio, one for video. The processing plugin performs multiplexing of audio and video. One output plugin is used to show the video, a second output plugin writes the video to a file.
  • Processing data from multiple cameras
Scenario: We have a network of cameras transmitting data to a central server (e.g. over TCP/IP). At the server we want to perform different computer vision tasks like background subtraction or object tracking. We need to be able to quickly change the task performed at the server and we also want to combine multiple image operations.
Solution with NIPO: We need a suitable input plugin to receive the data from the camera (we could use the one from above and only read binary data). We use a processing chain to be able to perform multiple processing steps before output. We need the processing plugins capable of computer vision tasks (one for every tasks, so that we can recombine them). Thus, we may have a background subtraciton plugin, a object detection plugin, a tracker plugin and many more (note: due to the power of P/Invoke you can easily use native code or native libraries for heavy processin tasks). As output we may use the visualization from the above samples (note how easy it is to reuse the plugins for very different application scenarios)
  • Implementing a pipes & filter application
Scenario: Pipes & filters is a very famous pattern.
Solution with NIPO:
  • Making working on scientific data flexible
Solution with NIPO:

Where was NIPO used already?

  • Flexible Clustering in Networks of Smart Cameras
  • Geobashing MMMOG server backend

What about performance?

There is of couse a performance overhead when using NIPO opposed to building a monolithic application. But we assume this overhead to be very small. Whenever the NIPO instance is started the communication between plugins is done by standard .NET events. There is no additional computation overhead. The memory overhead consists mainly of the Controller, the logging and other services.
Up to now we do not have reliable test results on a possible performance overhead. What we have is a reallife test. We built a NIPO application which essentially performed a geographic search (i.e. searching objects in the vincinity of a geographic location). The input and output were .NET Remoting endpoints (i.e. there were requests coming from an external network node). We could perform our operations at 500 requests per second without noticeable load on our 1,86GHz@2GB Ram server (we had peeks up to 20% processor load). This shows that NIPO works reliable also under demanding circumstances. This test was part of research work which is currently being published. We will give a reference here soon.

How to use NIPO

NIPO is not a standalone application. It was designed as a library to be used inside other applications. This enables a broader spectrum of applications using NIPO. Of course, there will be a starter application which can be used for many purposes.
So, to use NIPO you include the library in your application. For details on the further steps see UsingNipo.

How to write IPO- Plugins

If you want to write your own input, processing or output plugins, please see WritingPlugins

Advanced topics

To see information on service and observer plugins as well as other advanced topics like how to build chains of plugins in NIPO please take a look at AdvancedNIPO

Last edited Mar 24, 2010 at 3:11 PM by bedieber, version 25


No comments yet.