6  Plugins of the default distribution

The iceWing package already contains different plugins. This chapter gives a brief overview over all these plugins. Some of the plugins are directly compiled into iceWing and some others are normal external plugins. The external plugins are not installed during the normal iceWing installation. They have to be compiled and installed separately. See the quicktour, section 3.1, for an example of how to install a plugin.

6.1  Plugin grab

The plugin grab is an inbuilt plugin, that allows to acquire images or video streams from grabber hardware, disk or via DACS from external processes. The plugin provides the images under the identifier “image” (YUV color space) and optionally under the identifier “imageRGB” (RGB color space) under the data type “grabImageData”, see page 171. As grab is an often used and very central plugin it was already described in detail in the manual. Especially sections 4.1 and 5.2.3 covered the grab plugins command line interface and its user interface.

6.2  Plugin demo

An external plugin demonstrating all widgets available in iceWing and the different render capabilities of iceWing. The quicktour, section 3.1, used this plugin for a first iceWing demonstration.

6.3  Plugin min

An external plugin showing the basic structure of an iceWing plugin. The plugin does not do anything usefull, it shows only the structure of a complete plugin. This plugin is used in the section 9.1 to introduce plugin programming. If you want to create own plugins be aware that there is also a plugin generator, icewing-plugingen, which is documented in section 7.5. This tool generates a nicer starting point for own plugins.

6.4  Plugin min_cxx

An external plugin showing the basic structure of an iceWing plugin. It’s nearly identical to the min plugin besides that it uses the C++ plugin interface of iceWing. Similar to the min plugin this plugin is used in the section 9.1 to introduce plugin programming. If you want to create own plugins be aware that there is also a plugin generator, icewing-plugingen, which is documented in section 7.5. This tool generates a nicer starting point for own plugins.

6.5  Plugin record

The record plugin is compiled into iceWing and performs optimized saving of images by using a second thread to write the images to disk. Additionally it has support to drop single frames in a controlled manner. If started without arguments the plugin gets called for data with the identifier “image” of type “grabImageData”, the identifier the grabbing plugin uses to provide its images for other plugins. The observed data can be changed via its command line interface.

6.5.1  Command line parameter

-g <ident>

Observe data of type “grabImageData”, the default (with ident = “image”) if neither “-g” nor “-i” is specified. Besides the image data this data type additionally contains grabbing time and file name information, which can be used to name the saved files.

-i <ident>

Observe data of type “iwImage”. This format contains only image information.

6.5.2  User interface

Plugins to handle

Normally, the plugin is called successively for all images which are stored under one ident. E.g. if two grabbing plugins were started in parallel, the plugin is called two times for both of these images. Here you can restrict the calling of the plugin to data elements from only a subset of the plugins. E.g. if you want to save only images from the second grabbing plugin, you can select the second grabbing plugin with this widget.

Record

Off:

The plugin does nothing.

Exclusive:

The received images are saved and the processing of any further plugins during the current main loop run is canceled. Beware: If the record plugin should handle more than one image (for example the two images from two parallel started grabbing plugins), this toggle can not be set to “Exclusive”, otherwise the plugin would not be called for the second image nor for any further ones.

Parallel:

The received images are saved to disk without disturbing any other plugin processing.

Once:

The plugin processes the images until it is called a second time for an image from a plugin which was already processed. After that processing is deactivated automatically.

Framedrop

The plugin maintains a queue where all received images are added. A second thread continously removes images from this queue and saves them to disk. If this slider is not 0, the main thread can wait some ms if the queue gets to long so that the second thread has more time to save the images. If the queue is longer than 4 times the slider value, the main thread waits 200ms, if it’s longer than 2 times, the thread waits 80ms, and if the queue is longer than 1 times the slider value the thread waits 40ms.

Convert to RGB

If selected, the received image data is converted from the color space YUV to to the color space RGB before saving. This is ignored for all movie formats.

Image format

Specifies the file format used for saving images. If “By Extension” is selected, the format gets selected based on the extension of the file name. The different image formats are described in more detail on page 66.

Framerate based dup/drop-frames

If AVI files of the formats AVI YUV444, AVI YUV420, or AVI MJPEG are saved and this toggle is active, frames get duplicated or dropped to adapt to the selected frame rate.

AVI Framerate

If AVI files get saved, this value determines the desired frame rate. Frames are duplicated or dropped to adapt to this value if the toggle button above this slider is active and the selected file format is AVI YUV444, AVI YUV420, or AVI MJPEG. Otherwise this value is only stored in the header of the saved AVI file.

Quality

The quality and thus the compression value used when saving jpeg images or AVI movies encoded as MJPEG or MPEG-4. 100 means a small compression and thus a good quality. For MPEG-4 files this sets the desired bits per pixel from 0.05 to 0.5.

File Name

The file name, under which the images will be saved. You can embed different information in the name by using the following modifiers:

%d

:

The consecutive image saving counter, starting at 0.

%t

:

The milliseconds part of the time the image was grabbed/loaded.

%T

:

The seconds part of the time the image was grabbed/loaded.

%b

:

The name of the current user.

%h

:

The system’s host name.

%p

:

The images file path part of its complete file name.

%f

:

The images file name part of its complete file name.

%e

:

The images file extension part of its complete file name.

%F

:

If the input was a video, the number of the current frame, otherwise 0.

%P

:

The name of the plugin which provided the current image.

Any of the above modifiers can be changed by printf() style format specifiers. E.g. “image%03d.ppm” would result in “image000.ppm”, “image001.ppm” and so on as file names.

Reset FilenameCounter

By using %d in the file name, a consecutive image saving counter is embedded in the image file name. This button resets this value to zero. If currently image recording is active the resetting is done after the recording is again switched off.

6.6  Plugin remotectrl

An external plugin which allows to remote control iceWing with an own Internet sockets based communication protocol and optionally the XCF framework. See http://xcf.sourceforge.net for more details about the external XCF framework. The plugin uses the capability of iceWing to save and load all its current status into a configuration file. Remote control works quite similar: The plugin publishes the functions “void control(char[])” and “char[] getSettings(void)”. The “char[]” means, that you send a normal C-string as parameter to the “control()” function. The content of that string can be any lines of the iceWing configuration file and iceWing accepts the new settings. Similar, the “getSettings()” function returns a string with the current settings of all widgets in the format of the configuration file.

The plugin works similar to the iceWing “-of” option from page 41 for remote controlling via DACS. See also the icewing-control program from the utils directory for a utility, that allows to send such strings to a running iceWing instance. The utility supports the internal sockets based communication protocol, the XCF framework, as well as the DACS framework. See section 7.3 for more details about this utility.

6.6.1  Command line parameter

-p [port]

Use the own internal Internet sockets based communication protocol to provide the two functions. The parameter gives the port of the socket, the default is 4208. If port 0 is given, a free port is selected automatically and printed to stderr.

This is the default if neither “-p” nor “-x” is given.

-x [name]

Use the XCF framework to provide the two functions. The parameter gives the name of the XCF server the plugin uses for publishing the two functions. The default is “xcf”.

6.7  Plugin shmdata

An external plugin which allows to distribute data via shared memory and local unix domain sockets to any number of other local processes, i.e it allows unidirectional one to n communication. Supported are data elements of type “grabImageData”, “iwImage”, and char[].

An example invocation to distribute the images from a grabbing plugin on the sender side and provide them on the receiver side under the same identifier would be:
  > icewing -sp SomeImages -l shmdata -a shmData1 “-p test -g image”
on the sender side and
  > icewing -l shmdata -a shmData1 “-p test -o image”
on the receiver side. The command from the receiver side can be invoked multiple times to distribute the image to multiple iceWing processes.

6.7.1  Command line parameter

-p <socket>

The name of the socket for the communication channel. It will be prefixed with “/tmp/”. This parameter must be given always on the sender as well as on the receiver side.

-g <ident>

Observe data of type “grabImageData”. For example the grabbing plugin provides this data type under the idents “image” and “imageRGB”. Exactly one of “-g”, “-i”, and “-s” must be given on the sender side.

-i <ident>

Observe data of type “iwImage”. Exactly one of “-g”, “-i”, and “-s” must be given on the sender side.

-s <ident>

Observe data of type char[]. Exactly one of “-g”, “-i”, and “-s” must be given on the sender side.

-n <num>

The sender copies the to be send data to a new shared memory region and informs all receivers about it. The receivers inform the sender when they do not need the data any more so that the sender can free the memory region. This number specifies the maximum number of items the sender allocats at the same time before the sender waits that the receivers notify him for memory not needed any more. The default is 2.

-o <ident>

The identifier under which the receiver provides the received data. Must be given exactly one time on the receiver side.

-b

Normally the receiver blocks until new data from the sender is available. If “-b” is specified, the receiver plugin does not block but simply finishes without storing any new data.

6.7.2  User interface

Wait Time and Receive Next

The slider sets the delay (in milliseconds) until the next image shall be acquired from the sender side. If you set it to -1, iceWing waits until you manually press the “Receive Next” button. This -1 works like a “pause-mode”.

6.8  Remaining plugins

The following plugins belong all to a project about hand segmentation and tracking. They are all (a) compiled into iceWing, (b) somewhat old, and (c) probably not really generally useful.

imgclass

Performs color classification of the input image by using a lookup table.

skinclass

Segment skin colored regions. Needs at least one other plugin to perform the real color classification.

backpro

Perform color classification based on back projection. Needs the skinclass plugin.

gsimple

Perform color classification with a gauss distribution. Needs the skinclass plugin.

polynom

Perform color classification with a lookup table. This plugin needs the skinclass plugin.

tracking

Track regions with a kalman filter. Needs the skinclass plugin.