Contents

Context

This project aims at packaging OTB functionnalities as modules/applications/processing chains/call-it-what-you-like, with auto-generated interfaces wrapping the application, and allowing to access the functionnality in a number of different contexts (command-line, GUI, ...)

History

This idea is the result of different initiatives started in the past, and hopefully englobes them all, aiming at being an ultimate version of such a framework (even if we all know that as soon it will be stable and widely used, we will want to move to the next version ;) ).

So let's first give here credit to their original authors, and understand better where it comes from, and what the current implementations look like.

CommandLineArgumentParser

At first, there was otb::CommandLineArgumentParser, a little but very usefull class allowing to write simple application with dynamic parameter handling, well-known from the Unix users.
Namely, it allows to define the interface of a command-line callable program to get something similar to what is described here for example
The developer of the application describe the parameters of the application, give them names, documentation,... and otb::CommandLineArgumentParser handles the parsing of the command line to dispatch values in the proper parameters, generates an help automatically when incorrect syntax is encountered, ...

FLTK GUI generator

David Dubois came later with a contribution consisting of generating an FLTK GUI using the same CommandLineArgumentParser class.

This allows basically the same application to have both a command line interface and a GUI, well suited for non-expert users who are not keen on typing cryptic commands in a shell as all geeks love to do.

QGis plugins

In between, Tisham Dhar came up with the first OTB Qgis plugins, an initiative to push the OTB functionnalities to the widely known GIS called Qgis. You'll find more about this here.

One drawback of the approach is the need to develop, in addition to the applications, a specific QGis GUI each time we want to put a new functionnality in QGis.

OTB-Applications autogenerated interfaces

When integrating the work of David and thinking of how we could migrate all the existing applications based on CommandLineArgumentParser, it quickly came to mind that it would be great to build the GUI with Qt instead of FLTK, and while we were at it, to also wrap them in QGis plugins, benefiting from the experience of Tisham from the first OTB-Qgis plugins.
This work is currently hosted at http://hg.orfeo-toolbox.org/OTB-Applications

The ProcessingChains subdir contains the generic framework describing an application (mostly a revamping of the original CommandLineArgumentParser class to make it more generic).
An application is packaged as a shared library, and contains the definition of one class deriving from otb::Application
It must implement two methods : one for Describing the parameters, one for Executing the application.

Next to it are independent "Wrappers" (application automatically built around the application shared library) :

CommandLine : to get back the functionnalities of the original CommandLineArgumentParser

FLTKGui : integration of the work of David to auto generate FLTK GUIs

QtWidget : a generic QWidget that can be constructed with an otb::Application pointer as parameter, and constructs a GUI dynamically

QtGui : a simple GUI standalone executable based on the QtWidget

QgisPlugin : a generic QGisPlugin, deriving from QtWidget, reimplementing the input image to give access to the QGis raster layers through a combobox instead of a QLineEdit+file chooser, and with the additional step of putting the output images into the Qgis canvas at the end of the processing.

Specification for improved interface generators

The autogenerated interfaces are nice but were directly inherited from the already existing CommandLine application, aiming at backward compatibility during the implementation. As such, the wrappers are ok, but the GUI wrappers lack some fundamental functionnalities to have nice easily usable GUI.
So it has been decided to rework the underlying data models to provide more functional GUIs, keeping roughly the same level of support for command line applications.