OTB 4.0 whitepaper
This page is here to capture all the information about what we expect from OTB 4.0 and how to achieve it.
Contents
Main objectives
- Catch-up with ITK releases
- Clean-up (see ITK V4 wiki page on modularization)
- Split-up OTB into cohesive modules to facilitate maintenance, contributions and user experience
- Stick closer to ITK
- Manuel : New Code Contribution Process (code review system)
- Manuel : Integration of past contributions (bridge OpenCV, Hyperspectral GPU code...)
- Manuel: Improve Development workflow (manage different topics in different branches, provide maintenance release branch), improve coding style control
- Manuel: Improve documentation (crowdsourcing documentation cf http://www.kitware.com/blog/home/post/193)
- Manuel : Facilitate migration for OTB users (cf http://www.kitware.com/blog/home/post/184)
Detailed Objectives
Catch up
A lot of work has already been done, see here.
Clean up
There are some part of the code that could be removed or simplified:
- Useless classes: base classes with no significant reason, unfinished or unusable classes
- Duplicated classes or structures : for instance VectorData vs. OGRWrapper, or RadiometricIndices classes vs. BandMath.
Removing these classes will enhance the global code quality and readability.
We also could refactor some part of the code, for instance the otb::Image and otb::VectorImage classes.
Last, we have a huge set of tests that piled up over the years: some of them are redundant, or not well designed, or useless. Can we get a smaller, better test set with the same coverage ?
Split up
Why ?
- For now the sorting of classes within the few code folders is not consistent. Some folders are quite heavy and messy (BasicFilters, or Common).
- This monolithic architecture makes it difficult to
- Find the code you need,
- Contribute new sets of features into OTB
The idea: split OTB into a set of cohesive modules/sub-modules containing :
- Filters code
- Testing
- Wrapping
- Applications
- Third parties
Stick
We could benefit from sticking to ITK 4.0:
- Easier wrapping (It might suppose to get rid of otb::Image and otb::VectorImage)
- Cleaner and smaller testing
- Modularization
- Remote module cmake-framework for external contribution
OTB could become a set of external modules for ITK 4.0:
- otb-core
- otb-appengine
- otb-geometry
- otb-pansharpening
- otb-machinelearning ...
Open questions
- Do we need to migrate to Git ?
- Do we need to use Gerrit ?
- Do we need to use github ?
- Do we need to use the CMake framework for downloading testing data ?
see Test data management in ITK
- How to preserve history smartly ?
- Can we reuse work done previously regarding the migration to ITKv4 ?
- Is it possible to transform OTB to an ITK module ? group of modules ?
- Doesn't it invert the dependencies ? For now, OTB depends on ITK. After a closer look at what ITK (external) modules are, it seems that this would no longer be true : OTB will became part of ITK at compilation time. How does it cope with our own release schedule and binaries distribution ? Is it possible to distribute modules binaries ?
- What is the status of DLL build of ITK (and thus OTB) on windows platform ?
- External module/Remote module ? Can we build an external module by setting ITK_DIR or do we need a modified checkout of ITK ?
- Can we reuse ITK's cmake infrastructure easily ? Does the following work :
find_package(ITK) itk_add_module(OTBModule1) itk_add_module(OTBModule2)
The plan
Can be done in parrallel :
- Pursue work on otb-itkv4 branch :
- merge with latest ITK 4 (official release), build with external ITK
- decouple ITK and OTB ImageIo completely :
- reimplement our own ImageIO (otb::ImageIO does not derive from itk::ImageIO)
- put our modified buffer converter handling complex into OTB namespace.
- Inventory of OTB classes for cleanup, refactoring, proposed modularization
ls -1 *.h | xargs cat | grep "class ITK_EXPORT" | cut -f3 -d' ' | grep -v class | sed s/\<// | sed s/\:// > manifest; ls -1 | xargs cat | grep "^class " | grep -v ITK_EXPORT | cut -f2 -d' ' >> manifest
- Decide how we can do modularization as ITK -> OpenCV got also this kind of modularization since release 2.4.
