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, ...)
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.
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.
The code is hosted at http://hg.orfeo-toolbox.org/OTB-QGis-plugins
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 core functionnalities are hosted at http://hg.orfeo-toolbox.org/OTB-Applications/file/tip/ApplicationGenerators.
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.
Wish List :
- Bounded numerical parameters
- Default values for parameters as long as it makes sense
- Multiple parameter (mainly input images list)
- RAM consumption parameter for all applications
- Parameter groups (wrapped in QGroupBox for Qt GUI)
- Dependance between parameters (if parameter X is used, show/make visible parameter Y)
- For choice (enumerated) parameters, provide dependent parameters depending on the current choice
- Standard/Advanced parameters
- Each time a parameter is updated, call a callback to update values of other parameters
- need to have state management in parameters (fixed by user, auto-computed by application...)
- not only the value must be updated, but also the style (number of digits for double values, switching from meters to degree for specifying origin between UTM and WGS84 ?)
Parameter types :
- Input image
- Input complex image (for SAR imagery)
- Output image
- Input vector data
- Output vector data
- File name
- Directory name
- Numeric (int/float as a first step)
- Choice (enumerated value)
- Geometry/CRS (specified by EPSG, WKT, image file, txt file containing a WKT..)
- DEM (SRTM directory, average elevation, arbitrary raster)
- Radius (=Int parameter, always with the name "Radius")
- Region (= Origin + Size)
- Point/Index (for example, seed of region growing algorithm). in Qgis, possibility to select by mouse click on the canvas
- Interpolator Type
- Pixel Type (for output raster)
- Spatial subset/spectral subset, always available for input image parameters. Directly integrated in Input image parameter ?
- Parameter group
- Mathematical expression (corresponding widget with green/red background depending on expression validation)
I/O Put the I/O mechanism out of the applications :
- the commandline/QtGui/Qgis plugin will instanciate otb::ImageFileReader and provide the applications directly otb::VectorImage objects
- possibility to wrap the application in Monteverdi using the pipeline mechanisms
- Logging framework, with different I/O implementation depending on the wrapper
- Error reporting
- Progress reporting
- Translation support (must-have for QGis integration)
- Tile processing : to make streamable any chain that does not support streaming out-of-the-box
- Syntaxic sugar to wrap simple filters as easily as possible
Interface generators :
- command line application
- FLTK GUI
- Qt standalone GUI
- Qgis plugin
- functional C interface / plugin interface (+ application which loads them dynamically ? but this applciation exists : its QGis)
- Java wrapper
- Python wrapper (with numpy interface for input/output images ?)
- Monteverdi module
- IDL function
- ENVI GUI
- Doc generation for integration in Software Guide
- Grass ? Is this really needed if we integrate QGis ?
- WPS service + GUI calling the service based on a WPS client lib, with the same interface layout as the other GUI
- interface with several CNES proprietary softwares
- Categories of parameters based on default behavior : absolute, relative to other parameter, not applicable ?
- Check values atomically/as a whole ?
- 3 main methods in the application
- Describe the interface
- Update parameters (called each time one of the parameters is updated)
- Execute (in fact it's more "Build Pipeline", as some generators will not necessarily run the pipeline)
The project is hosted in an independent repository for the moment : http://hg.orfeo-toolbox.org/OTB-Wrapper
Current state is that the main parameters types are available in the core lib, with their corresponding QtWidget. It is not complete yet.
Some examples applications are in the Example directory. Here are some screenshots of what it gives for a simple smoothing application :
All existing applications (the ones in OTB-Applications) will be ported to the new framework as soon as we have a similar level of functionnalities (a Qt + a CLI interface generator).
We will also be able to rewrite all the Tisham's QGis specific plugins in this new framework.