A key feature of the next OTB release(coming soon) is the new modularized architecture which allows a better organization and documentation of OTB filters and will also facilitate the development and the contribution of external codes based on the library.

This modular architecture is mainly based on the one developed in the frame of ITKv4 which was adapted for OTB needs.

New code architecture

For those who are familiar with OTB sources, the next release will introduce a new organization for the source directory . There is now a Modules directory at the root of the source tree (no more Code/BasicFilters, Code/Common…). Inside, there is a list of groups which consists in a set of cohesive modules.

For instance the “Segmentation” group contains a set of 8 modules (one module = one directory) which provides different types of segmentation algorithms (watersheds, mean-shift, morphological profiles…). Each module has the same code architecture :

• CMakeLists.txt and otb-module.cmake files which contains CMake macros/functions needed for the module definition (name, dependency to other modules…)
• src and include directory: source code of the classes
• test: related tests to module classes

You can build and test an OTB module with the following commands:

• To build classes in a module (for example a module called ModuleExample) -> make OTBModuleExample (run from the OTB build directory)
• To build classes and tests related to this module -> make OTBModuleExample-all (run from the OTB build directory)
• To run tests related to the module ModuleExample  -> ctest -L “ModuleExample” (run from the OTB build directory)

You can find more detail informations about this architecture on the OTB wiki.

Build a custom OTB: activate what you need

This modular architecture allows to build an OTB with only modules that you need and allows also to easily deactivate third party dependencies.

The CMake option “OTB_BUILD_DEFAULT_MODULES” (ON by default) will build all OTB  modules. Turning it to OFF creates a set of new CMake options (one for each OTB groups and modules). There are prefixed by OTBGroup_ for Groups and Module_OTB for modules and allow to define the list of modules that you want to build.

If you want to deactivate all segmentations algorithms in OTB: OTBGroup_Segmentation = OFF

If you want to only deactivate the compilation of Watershed filters in the Segmentation group : Module_OTBWatersheds = OFF

Furthermore, an other interesting feature is the possibility to deactivate all modules related to a third party dependency. For instance if you don’t want to install LibSVM on your system and you’re not interested by OTB filters which are using this library, you can easily deactivate it by switching the CMake options OTB_USE_LIBSVM to OFF. It will automatically deactivate all modules related to LibSVM.

Of all course modules dependencies are managed auto-magically by CMake.

Start from a template module

I provide a template for OTB external module from which you can start. What you need to do:

• Clone the template module from https://github.com/orfeotoolbox/otbExternalModuleTemplate to the Modules/Remote directory in OTB source tree(you’ll need to clone first the OTB trunk)
• Run CMake configuration (you should see a new CMake option named MODULE_TheModuleName)
• Turn this option to ON
• Your module will be built with the rest of the OTB project.
• The template module is almost empty but contains the minimal configuration to add source code, tests and also a template for an OTB application. Now you can start to hack the code in the src, test and app folders!

Hopefully this blog provides some useful guidance to assist OTB users in the transition with the new architecture. Please let us know if you find problems, or if you have questions or suggestions. Your comments are always  welcomed.

Manuel