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

[cncastillo]

I have heard about qMRLab, but I am unfamiliar about what they do. It seems like a good idea!

[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 :)

[cncastillo]

Thumbs up for the meetings!

[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

[cncastillo]

I think many of these enhancements could be a Google Summer of Code project. I participated this year and it was a very good experience, and a lot of work can be done in the summer (http://juliahealth.org/JuliaHealthBlog/posts/ryan-gsoc/Ryan_GSOC.html). Even if not part of GSoC, many students are looking for programming projects related to medicine. I am sure @TheCedarPrince would be happy to include some ideas/proposals. Also, if they are math related I think there are some that could be included as a class project for Northeaster University (https://discourse.julialang.org/t/northeastern-university-looking-for-research-projects-for-student-teams/114880/12).

Also, Juliacon 2025 will have a dedicated JuliaHealth mini-symposium to show of the state of Julia for biomedical applications, and I am sure it would be a good place to get some more students interested :) ! It would be very nice to have more people from medical imaging, the abstract submission site will be open soon! I will be there! https://juliacon.org/2025/

Is any of you planning to go to the ISMRM in Hawaii? We could have an informal meeting there, and maybe plan a Julia related member initiated session (https://www.ismrm.org/24m/mis/) for next year (2026). For a while I been meaning to do a MRI-oriented introduction to Julia, I will be doing one in January (https://github.com/LIBREhub/Advanced-Scientific-Computing-Using-Julia/), and maybe something similar can be done at ISMRM, with talks related to the current ecosystem and what is currently possible in Julia, and what needs a few extra hands.

While is not all only MRIReco enhancements, I would be particularly interested in:

• Koma/MRIReco: Automatic differentiation support (we briefly talked about this with @tknopp and @nHackel, but I had no time to test it before ISMRM, but I have been experimenting with it)
• Koma: Implementing GPU accelerated EPG or PDG methods
• Pulseq: Finish the Pulseq writer in Write Pulseq JuliaHealth/KomaMRI.jl#284 (Koma)
• Pulseq: Finish the Pulseq helper functions with Unitful.jl support in Pulse Designer JuliaHealth/KomaMRI.jl#305 (I have talked to Maxim Zaitsev and Jon-Fredrik Nielsen, to move these with the previous point to a dedicated Pulseq.jl package)
• Pulseq: Extensions handling and multi-echo reconstruction JuliaHealth/KomaMRI.jl#308

Small issues:

• MRIReco: MRIReco load time #199
• MRIReco: avoid the need to do using MRIReco.RegularizedLeastSquares

[aTrotier]

Happy New Year!

Great idea about both the GSoC projects. I'm not entirely sure how much involvement is required from us, but it would be helpful if you could share your past experience during a meeting—specifically, how much involvement is needed, the scope of the projects, and so on.

I won't be attending ISMRM this year (it’s too far from France!), but it’s a great idea to try starting something at ISMRM for the MR Julia community—perhaps something like the BART secret session.

By the way, I need to build an MRI course focused on simulation, Pulseq, and reconstruction. I think most of it will be in Julia, except for the Pulseq part for now. Maybe the examples we create could also be used for an ISMRM initiative.

I’d be happy to help with the following points:

• A Julia-dedicated Pulseq writer, including the MR extension label.
• EPG/PDG simulation capabilities, especially for simulating 3D spoiled sequences. (It seems many issues with komaMRI are related to the increased number of isochromats in the spoiling direction.)

[aTrotier]

I don't know how large is the community, but we could also start to do some webinars like BART or gadgetron