A strategy for massive redesign of image processing filters
What changes will be made and why they would make a better Orfeo ToolBox?
This is the big picture I have in mind for merge request !268 (please read it before proceeding any further). I would rather avoid this deep down in the MR comments section, hence this request for comments.
High level description
!268 introduces a new functor filter that is very easy to use with any functor or lambda. It can replace many of the functor based filters currently defined in OTB. The following cases are covered:
./Modules/Filtering/ChangeDetection/include/otbBinaryFunctorNeighborhoodJoinHistogramImageFilter.h ./Modules/Filtering/ImageManipulation/include/otbBinaryFunctorImageFilter.h ./Modules/Filtering/ImageManipulation/include/otbTernaryFunctorImageFilter.h ./Modules/Filtering/ImageManipulation/include/otbBinaryFunctorNeighborhoodImageFilter.h ./Modules/Filtering/ImageManipulation/include/otbUnaryFunctorNeighborhoodImageFilter.h ./Modules/Filtering/ImageManipulation/include/otbUnaryImageFunctorWithVectorImageFilter.h ./Modules/Filtering/ImageManipulation/include/otbBinaryFunctorNeighborhoodVectorImageFilter.h ./Modules/Filtering/ImageManipulation/include/otbUnaryFunctorNeighborhoodWithOffsetImageFilter.h ./Modules/Core/Common/include/otbUnaryFunctorImageFilter.h ./Modules/Core/Common/include/otbQuaternaryFunctorImageFilter.h ./Modules/Core/Common/include/otbUnaryFunctorVectorImageFilter.h
And the following could also be with a little extra work (though I would question some of them):
./Modules/Filtering/ChangeDetection/include/otbBinaryFunctorNeighborhoodJoinHistogramImageFilter.h ./Modules/Core/Common/include/otbUnaryFunctorWithIndexWithOutputSizeImageFilter.h ./Modules/Filtering/ImageManipulation/include/otbUnaryFunctorWithIndexImageFilter.h
Keep in mind that we are not only talking of those filter, but also of all the filters that derive from them: the current practice in OTB is to add a new class deriving from the functor base class templated with the functor, and we are sort of forced to do so in most cases to get
I would like to propose to remove all those classes, and only keep:
- The generic functor filter
- An extensive library of well tested and documented functors
Additionally, I would like to hunt down any filter that could fit into this design and that is currently not implemented as a functor filter, and apply the same pattern to it.
And we should not stop there, we could have :
- A generic filter for processing a run-time defined stack of input images of the same time (useful for processing time series for instance)
- A generic persistent functor filter that allows to define functor / lambas to derive stats and global features
- A generic functor filter for processing vector data with images ...
Risks and benefits
The benefits are numerous:
- A very large amount of boiler plate code is removed from OTB, which means less testing and compiling time, less bugs, less features to document
- Testing will be shorter to compile and more efficient: we only need to write extensive testing for the generic filters, and then we could write small and fast unit tests for functors, without I/O or even linking / running ITK stuff on the way.
- For users (that write code) there is less obfuscation of what is actually done: usually functors / lambdas are short and easy to read, whereas filters are not.
Here are some risks I can see:
- This breaks backward compatibility deeply. It is a large refactoring that will require users to adapt
- The amount of work is quite large to get there. Also it could be the occasion for more clean-up
- A large part of the software guide will be made irrelevant. Again, it is the opportunity to write something better (and shorter).
Alternatives for implementations
Work on generic filters can be started right away (as for !268 ). The big plan (porting all filters that can fit) needs some planning, hence this request for comments.
Who will be developing the proposed changes?
This should be a joint effort.