Abstract interface for reconstruction algorithms

[jonschumacher]

As discussed in the slack, the current interface of MPIReco is very focussed on SM-based reconstruction of FFP data. In this issue, I would like to discuss the way to a more general interface that can be used for various reconstruction methods like x-space, SM-based, AI-based approaches for both FFL and FFP systems. As already discussed in Slack, introducing an abstract type AbstractReconstruction together with grouping the keyword arguments into structs is probably the best way to go. These might also get some traits attached in order to further group algorithms together and re-use parts that can be shared. What I would see as beneficial is some sort of chaining approach for the steps that are needed to get to the actual reconstruction. This includes e.g. frequency filtering, Radon transform for FFL reconstructions, calling the actual solver and so on. If the whole package would be organized in a chainable way, exchanging parts for trying new stuff could become easier. It could even be possible to create a GUI that can be used to create new algorithms. In order to create this infrastructure, I would like to start a discussion here on what would be needed to get to a new interface and what could be integrated into it.

[tknopp]

Regarding the "Chaining" thing. This is something that has been implemented in MRI (https://onlinelibrary.wiley.com/doi/10.1002/mrm.24389) software frameworks. In MRIReco.jl (https://onlinelibrary.wiley.com/doi/pdf/10.1002/mrm.28792) we argue a little bit against this flow type of programming since one is effectively creating a new type of programming language.

I currently lean towards creating AbstractReconstructionAlgorithm and try to start from that. I will try chatting with @migrosser about our MRIReco experience. We might (and this is a very hypothetical might) even think about creating a flexible framework that is useful not only for MPI but also for MRI .... Right now these structures between MRIReco and MPIReco are not shared, which can be a pro but also be a con.

[hofmannmartin]

Something that should be considered in terms of modularization is definitely the preprocessing of the data, such as frequency selection and averaging. This shares many reconstruction algorithms and I think it also deserves an abstract interface so that new signal processing steps can be easily integrated.

[jonschumacher]

At least background correction, tf correction, averaging and frequency selection are implemented in MPIFiles with getMeasurements and getMeasurementsFD. But maybe it makes sense to create a type AbstractPreprocessingParameters and a struct CommonPreprocessingParameters which covers the respective parameters from getMeasurements. As a contract/duck typing we always assume subtypes of AbstractReconstructionAlgorithm to always provide some preprocessing parameters. I will try to come up with a first proposal for the interface in some draft PR but I guess this is such a breaking change that this has to grow for a while.

[jonschumacher]

I now added a first (untested) draft of the interface for the discussion: https://github.com/MagneticParticleImaging/MPIReco.jl/pull/18/commits/93867bbeb09e100a9d9b4f94b9030f1a8d1a9513. I find it hard to separate the existing implementations into different algorithms. I guess the multi MPI files are somewhat special, but can other algorithms be split off?

[tknopp]

Here are some explanations on the current dispatches:

• One dispatch into reconstruction algorithms is made here https://github.com/MagneticParticleImaging/MPIReco.jl/blob/master/src/Reconstruction.jl#L111. It goes into multi-patch or single-patch reconstruction. We try to dispatch that automatically.
• Another dispatch is done here https://github.com/MagneticParticleImaging/MPIReco.jl/blob/master/src/Reconstruction.jl#L195. The one is for temporal regularization, which takes several frames into account. The ":reco" is my first attempt at a proper reconstruction type
• Here happens the next dispatch: https://github.com/MagneticParticleImaging/MPIReco.jl/blob/master/src/Reconstruction.jl#L287. If bgDict is empty we use the regular reconstruction. If it is non-empty we also estimate the background from the measurements
• getSF (see here https://github.com/MagneticParticleImaging/MPIReco.jl/blob/master/src/Reconstruction.jl#L172) is also an important source for dispatch. Here, the SM is prepared such that it fits to the later linear solver. It also will generate multi-color or sparse system matrices.
• The last point makes the connection on MultiMPIFile and MultiContrastFile, see for instance https://github.com/MagneticParticleImaging/MPIReco.jl/blob/master/test/Reconstruction.jl#L54. There one can see that the MPIFile handle can be source for a later dispatch.

This just as a small summary. I still struggle to group / classify this into a flat list of reconstruction algorithms.

[jonschumacher]

For me, it looks like at least some of these points are mainly concerned with some specific preprocessing steps. These could be splitted off and put into the preprocessing method of #18. The rest should then be genuine reconstruction algorithms. But one thing bothers me with the preprocessing steps: reusing them in different algorithms duplicates the code for the parametrization since this would go into the algorithm struct. One way would be using macros inside the struct definition but this would then be decoupled from the actual function which introduces a source of error. Other solutions would tend more to the chaining approach. Do you have ideas on that?