Project Roadmap
A roadmap is a document containing an ordered list of our project's development priorities for the future. It helps us organize our thoughts and communicate to others about what we are trying to accomplish and what we may need help doing. This roadmap does not have deadlines or specific tasks (that's what our project boards are for), but instead, it is a general overview of our future goals.
TomoPy has become quite large and complicated. We have had complaints about the present dependency list and the complexity of our upgraded build system. However, we really have no idea which features are being used, so we cannot make informed decisions about what features to cut or spend development time maintaining.
By breaking TomoPy into separately installable modules, we can get statistics from anaconda about which features are being downloaded, we can decrease on-disk sizes for source and binary modules for users who want only some features, and we can simplify the build process for users who want only some features. We can also provide a standard interface (through Python entry-points) for common tasks (like reconstruction), so that it is easier for third-parties to integrate with TomoPy.
Our iterative algorithms library has a lot of duplicate code. Most of the duplicate code implements the steps of our Siddon parallel beam projection operator. Intermingling the Siddon projection operator with the reconstruction algorithm code also makes these algorithms harder to understand.
By refactoring our code in terms of forward and adjoint projection operators we can decrease duplicate code, make our iterative algorithms easier to understand, and make future maintenance easier.
In order to promote additional reuse of our codebase, we should supply a public C++ interface. This interface may be of special interest to high-performance-computing applications or other performance critical projects who do not want to use Python.
X-ray sources are becoming brighter and data sets are becoming large.
By porting our most used preprocessing and reconstruction algorithms to the GPU we can keep up with large data volumes.
We currently have 3? methods of dividing a task amongst threads/processes/cores/GPUs? We should refactor or unify our approaches.
In order to promote additional reuse of our codebase in lab-scale x-ray imaging, we can provide access to fan geometry.