You are here: Start » Programming Conventions

Programming Conventions

Organization of the Library

FabImage Deep Learning is a collection of C++ functions that process machine vision related types of data. Each function corresponds to a single data processing operation, e.g. DetectEdges_AsPaths performs a Canny-like 2D edge detection. As a data processing library, it is not particularly object-oriented. It does use, however, modern approach to C++ programming with automatic memory management, exception handling, thread safety and the use of templates where appropriate.

Namespaces

There are two namespaces used:

• ftl – the namespace of types and functions related to Fab Template Library.
• fil – the namespace of types and functions related to FabImage Deep Learning as the whole.
• fis – FabImage Studio Code Generator equivalents of FabImage Deep Learning functions. Not recommended to use.

Enumeration Types

All enumeration types in FabImage Deep Learning use C++0x-like namespaces, for example:

namespace EdgeFilter
{
    enum Type
    {
        Canny,
        Deriche,
        Lanser
    };
}

This has two advantages: (1) some identifiers can be shared between different enumeration types; (2) after typing "EdgeFilter::" IntelliSense will display all possible elements of the given enumeration type.

Example:

Function Parameters

Contrary to standard C++ libraries, machine vision algorithms tend to have many parameters and often compute not single, but many output values. Moreover, diagnostic information is highly important for effective work of a machine vision software engineer. For these reasons, function parameters in FabImage Deep Learning are organized as follows:

1. First come input parameters, which have "in" prefix.
2. Second come output parameters, which have "out" prefix and denote the results.
3. The last come diagnostic output parameters, which have "diag" prefix and contain information that is useful for optimizing parameters (not computed when the diagnostic mode is turned off).

For example, the following function invocation has a number of input parameters, a single output parameter (edges) and a single diagnostic output parameter (gradientImage).

Diagnostic Output Parameters

Due to efficiency reasons the diagnostic outputs are only computed when the diagnostic mode is turned on. This can be done by calling:

In your code you can check if the diagnostic mode is turned on by calling:

Optional Outputs

Due to efficiency reasons computation of some outputs can be skipped. In function TestImage user can inform function that computation of {{TestImage.outMonoImage}} is not necessary and function can omit computation of this data.

the TestImage Header with last two optional parameters:

Example of using optional outputs:

In-Place Data Processing

Some functions can process data in-place, i.e. modifying the input objects instead of computing new ones. There are two approaches used for such functions:

1. Some filters, e.g. the image drawing routines, use "io" parameters, which work simultaneously as inputs and outputs. For example, the following function invocation draws red circles on the image1 object: INVALID EXAMPLE 'InPlace1'
2. Some filters, e.g. image point transforms, can be given the same object on the input and on the output. For example, the following function invocation negates pixel values without allocating any additional memory: INVALID EXAMPLE 'InPlace2'

Please note, that simple functions like NegateImage can be executed even 3 times faster in-place than when computing a new output object.

Work Cancellation

Most of long-working functions can be cancelled using CancelCurrentWork function. Cancellation technique is thread-safe, so function CancelCurrentWork can be called from different thread. If fil function was cancelled then ftl::CancellationError is thrown.

To check cancellation status use the IsCurrentWorkCancelled or ThrowIfCurrentWorkCancelled functions.

Library Initialization

For reasons related to efficiency and thread-safety, before any other function of the FIL library is called, the InitLibrary function should be called first:

Debug Preview

For diagnostic purposes it is useful to be able to preview Images and image based data primitives. You can achieve this by using functions from the Debug Preview category. They can be helpful in debugging programs and displaying both intermediate and final data.