Roadmap 2025

[aTrotier]

Hi MR community,

I am starting to work on MRIReco.jl more intensively and I will be happy to work on some enhancements. Maybe others are also volunteer for that ?
I think @tknopp don't have a lot of time for development but maybe you have some goals/vision for the repository ?

Some question that might help to define a roadmap :

• Who is using MRIReco.jl either in subpackage like @cncastillo or for their daily routine research job ?
• What functions are you using ?
• What features / enhancement would you like to see ?

Related to discussion : #149

[aTrotier]

For my part I am using MRIReco for both preclinical (bruker) and clinical reconstruction (siemens). I am using MRIReco for the conversion. For advanced reconstruction (subspace / CS...) I generally work with BART to validate my works and then moved on to MRIReco to see if it also works and stick with it if it is the case.

I am starting to work more and more with pypulseq (siemens) and this year I would like to perform an inline reconstruction with gadgetron -> Gadgetron.jl -> MRIReco.jl -> scanner

Suggested enhancement :

• Siemens data reader (Related to Native Siemens Reader #73 ) : I am either converting the data with siemens_to_ismrmrd or with pymapvbvd (called via CondaPkg.jl / PythonCall.jl). Maybe we can use the parameter_map from siemens_to_ismrmrd in order to create the RawAcquisitionData structure correctly filled.
• Associate different trajectory / subsampling for each dimension, right now It is only the case for the echo dimension.
• Long term rework of the dimension available :
  • more homogeneous between the different object (sensitivity maps is expected has x,y,z,ch but the image after reconstruction x,y,z|sl,echo,ch,rep
  • handle more dimensions (MRD EncodingCounters : average / slice / contrast / phase / repetition/set /segment +/- user)
• Benchmark against BART more frequently (reconstruction time / memory consumed but also accuracy see Fista algorithm : accuracy problem #114 )

[aTrotier]

Copy of our last roadmap discussion :

1. Fixing the accuracy / convergence issues for CS Fista algorithm : accuracy problem #114
2. implement and benchmark wavelet transformed for non-square / not 2^n matrix Maximul level transform for Wavelet operator in non 2^n matrix tknopp/SparsityOperators.jl#12
3. Model-based reconstruction (moba in BART, PyQMRI)
4. unified EPG package.

[aTrotier]

Does the MR community interested in a Julia alternative of qMRLab ?

I have started to do some stuff in QuantitativeMRI.jl but it in standby and would really need more discussion to plan ahead of time the features / inter-operatibility with other packages

[nHackel]

I am starting a new job next year and I am not entirely sure yet how much time I will have for MRIReco and related packages (NFFT.jl, RegularizedLeastSquares.jl and LinearOperatorCollection.jl), but I do have some features planned that I want to do in 2025 that relate to MRIReco.jl:

NFFT.jl:

This year I've added GPU-support to the mentioned packages, however the GPU NFFT implementation is still lacking behind the CPU one. In particular, I think it's the preprocessing where the GPU just works with a sparse matrix. Here, @tknopp and I need to take a look if the implementation is feasible and "worth it". Alternatively, there were some other NFFT implementations that have decent GPU support. We might also just make an operator based on that package available to MRIReco.jl.

AbstractImageReconstruction.jl

In our magnetic particle imaging reconstruction package MPIReco.jl, we ran into the issue that the number of reconstruction algorithm variants could not be easily maintained by a dict or keyword-argument interface. In particular, if we wanted to add a new preprocessing step or a different algorithm all together, we always have to "manually" put int a new branch in the code like:

function reconstruction(data; algorithm = "newAlgo", kwargs...)
  # chose algorithm
  if algorithm == "simple"
    reconstruction_simple(...)
  else if ...
    ...
  else if reconstruction == "newAlgo"
    reconstruction_my_algo(data; kwargs...)
  end
end

This also stops other people from being able to extend our reconstructions with variants in their packages since they can't easily add a new branch to our existing methods.

Likewise since keyword arguments don't take part in dispatch, we weren't able to make effective use of Julias multiple-dispatch to handle specific types of processing steps or reconstruction steps. As an example we did have dispatch on the type of reconstruction input, but now thos break down we have two algorithms that are supposed to work for the same type of data. Another issue is that a flat dictionary can't handle two variables with the same name relating to different processing steps. We had a case where the same argument would need to be applied to the measurement data and the data necessary to build the operator but with different values. All those cases are things we couldn't depict in our existing interface and which would also affect MRIReco.jl

This was our motivation behind AbstractImageRecosntruction.jl, which we've also been working on this year. The idea here is that a reconstruction algorithm is a stateful object/struct that implements a reconstruction as a series of process-ing steps with a given structure of (nested) parameters. The idea is to have both an algorithm, parameters and the data to dispatch on. New variants of processing steps or even algorithms can then be implemented by adding new structs. This extension of course works across package boundaries.

I've recently added some documentation to AbstractImageReconstruction.jl where I implement a small CT reconstruction framework to show how the interface is intended to be used. We've also changed our MPIReco.jl framework to completely use it and it really helped to quickly prototype and implement new reconstruction algorithms or rather variants of existing algorithms which differ only in very specific processing steps.

The abstract interface also offers a lot of utility functions. For example, one can provide a user a "template" of an algorithm, which is essentially the structure of an algorithm and its parameters where the parameters only have to be partially filled in.. This can be used to provide standard recos such as the ones we have in MRIReco.jl, but also to store the concrete instance that reconstructed an image. These templates also meant to be easily "discoverable" programmatically, so that they can be displayed in the REPL or a GUI Other functionality is caching, where we can transparently cache processing results between reconstructions.

My more concrete plan is to further improve the functionality of the abstract packge and MPIReco.jl. In particular, I want to have a generic reconstruction GUI with tomographic data viewers that dynamically adapts its parameter input to a given plan and I also want to look into support potentially distributed computations. During these implementations the interface should also stabilize a bit more, though we are very happy with what we can do with it already.

I am definitely interested in also extended this interface to MRIReco.jl, but I'm not sure yet if I can provide a proposal this year and it would be a fairly different interface. We wouldn't lose any functionality and gain more options and we could even try to be backwards compatible by mapping the existing calls onto the "new" interface

[aTrotier]

AbstractImageReconstruction.jl seems great. It will take me some time to really understand the implication but it kind of looks like the gadgetron / gadgets implementation : https://github.com/gadgetron/gadgetron

Not sure if we should keep the backward compatibility rather than focusing our efforts of keeping the documentation up-to-date :)

[aTrotier]

Should we start again the MRIReco Community Meeting ? Is the community large / active enough ? @mrikasper

I see some activity around KomaMRI @cncastillo :)

[tknopp]

One question that would be on my list is, if we should put the individual packages into dedicated repositories. In that way one could join the two ISMRMRD implementations (https://github.com/gadgetron/Gadgetron.jl and MRIFiles.jl). Of course that would already possible now but probably it is easier to do once the repositories are split. Ideally everything moves into MRIFiles.jl and Gadetron.jl could then rely on that package.

[nHackel]

We can also now do CI-Tests across repositories, so we also don't lose that CI information. Well MRIFiles could see if it breakes something upstream but the upstream wouldn't automatically see that MRIFiles broke, but I think that is good enough