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

[tknopp]

I would love to see MRIReco at some point being migrated to AbstractImageReconstruction. I personally don't have hacking time but if someone with more MRI knowledge could pair up with @nHackel, this would be really cool.

I think one crucial element would be to define a hierarchy of MR reconstruction algorithms to better understand what type hierarchy one should target there. So one needs to think of algorithm families that share common elements. And that is exactly where input would be needed for Niklas.

[aTrotier]

I will be happy to help but I am not sure to have enough knowledge on this topic especially with ML and DL approach.

Maybe @JeffFessler has some thoughts about that ?

[JeffFessler]

Perhaps https://github.com/JuliaNLSolvers/Optim.jl could provide inspiration. I have not thought about type hierarchies for algorithms.

[nHackel]

@cncastillo and @aTrotier, I have not managed to think more about using AbstractImageReconstruction in MRIReco (other than the abstract wish that, that might be cool 😄). But I did have some time to update the MPIReco documentation and that kind of shows how a reconstruction package based on that interface might look like. Here is the documentation.

Maybe we can schedule a meeting sometime in the upcoming months and I can talk a bit more about it and answer some questions

[cncastillo]

Wow very nice documentation!

Maybe we can schedule a meeting sometime in the upcoming months and I can talk a bit more about it and answer some questions

That would be great, count me in! 😄 I am currently in California, so I could do 7:00 here any day, that should be 16:00 in Germany.

[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]

Nice, I squeezed the icon a little bit.

---

Let's vote ?

[tknopp]

I like the newest one from @cncastillo most ( but the other one is also nice! )

[mrikasper]

Thank you for your efforts, both of you!
 
I like @cncastillo's version as well, but can we rearrange the colors so that they are in the same way as in the Julia logo triangle (i.e., green on top, red on the left, purple on the right, and maybe the blue as color for the bore)?

[cncastillo]

Sure!

[mrikasper]

Beautiful, thank you, @cncastillo !

[JeffFessler]

I'll be at ISMRM in Hawaii. Happy to participate there. No time to do anything before then sadly...

[cncastillo]

Hi everyone! (tagging just a few @nHackel @aTrotier @JeffFessler)

First, I encourage you to submit an abstract to JuliaCon 2026, specifically to the Health Mini Symposium (organized by me and Jacob Zelko):

---

Second, Google Summer of Code is slowly approaching (the proposal deadline is 31st of March). This is a very good opportunity to finish features with the help of very enthusiastic and capable students. If you are interested in participating and you have a 3-month project idea, please let me know! (I might need to figure out the details on how to include proposals coming from MagenticReconanceImaging)

[aTrotier]

Do you think we should focus on only one project ?
Let see if somebody else can propose something. I did not put a lot of thought on this idea.

What do you think is useful to add/fix in MRIReco that can benefits to koma ? @cncastillo

[nHackel]

Hmm the only project I'd have in mind would be a proof-of-concept of changing the reconstruction interface to use AbstractImageReconstruction.jl, but I don't think I'll have enough time to properly supervise another student on my own at the moment and I'm not sure if MRIReco would currently benefit from the other interface.

As long as we can still "fit" all our algorithms in the current interface and don't require it to be more extendable/hackable, we are probably fine with leaving things as they are.

I'd also focus on whats interesting for KomaMRI.jl if you have any concrete ideas

[tknopp]

@cncastillo: One more general question: Right now we have the sub package MRISimulation that we primarily use for generating simulation data that can be used for reconstruction. It is somewhat important that it is a) fast and b) allows to exactly describe extended models like for instance the field-inhomogeneity model, or arbitrary trajectories. My question is: under these constraints: is it possible to do all this in Koma.jl? So, is possible to have "fast paths" for the idealized imaging equations or do you always need a full bloch solver (which I would assume is much more expensive that FFT/NFFTs). Potentially this could be a GSoc.

[cncastillo]

Sorry for the delay. I will reply to all comments below:

@aTrotier

Do you think we should focus on only one project ?

It doesn't really matter, it can be more than one project. But if you have three projects, each of those need three mentors. So your total dedicated mentoring time = 1 project.

If you ask me both "handle all the dimension of an acquisition" and a "TWIX reader" seem very useful.

@nHackel

I'd also focus on whats interesting for KomaMRI.jl if you have any concrete ideas

Mmm, "handle all the dimension of an acquisition" seem like a good one, as we always have had problems reconstructing 3D data (JuliaHealth/KomaMRI.jl#323) and probably multi-echo, multi-slice, etc.

@tknopp

is it possible to do all this in Koma.jl? So, is possible to have "fast paths" for the idealized imaging equations or do you always need a full bloch solver

We could create new simulation methods: "FastGRE", "FastSE", "FastbSSFP", etc. that use the steady-state formulas for each sequence, and gave k-space data using a NFFT.

The requirements would be:

• field-inhomogeneity model,
• arbitrary trajectories,
• coil sensitivities,
• am i missing something else?

The only blocker is that I haven't found the time to finish JuliaHealth/KomaMRI.jl#548 (which implements coils). So I could propose a project to add coil sensitivities and "fast paths" for some common sequences.

[aTrotier]

Ok,
are you all agree if we push forward the project : increase of the dimension handle by MRIReco ? @nHackel @tknopp
I remember having this discussion and I think one of you wanted to do more abstract in order to handle any new dimension (and not rely on the MRD format

Do you want also to add a summer project in order to finish the multi-coil PR of KomaMRI ?