MagneticResonanceImaging
Replies: 6 comments 14 replies
-
|
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 :
|
Beta Was this translation helpful? Give feedback.
-
Copy of our last roadmap discussion :
|
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
I have heard about qMRLab, but I am unfamiliar about what they do. It seems like a good idea! |
Beta Was this translation helpful? Give feedback.
-
|
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.jlIn 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
endThis 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 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 |
Beta Was this translation helpful? Give feedback.
-
|
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 :) |
Beta Was this translation helpful? Give feedback.
-
|
A small sidenote to AbstractImageReconstruction.jl. I've recently released the initial version of DaggerImageReconstruction.jl. That package allows us to move whole reconstruction algorithms or just parts of one to a different Julia process. With that I can configure and work with a reconstruction on my laptop and have the actual reconstruction happen on a different machine which features a GPU or just stronger resources in general. Another setting would be accessing data which is only available in certain machines. This is all implemented generically, so any reconstruction package implementing AbstractImageReconstruction could get these features for "free" |
Beta Was this translation helpful? Give feedback.
-
|
It would be really interesting if we can use AbstractImageReconstruction.jl directly on the scanner with Pulseq and get fully open-source sequences and reconstructions :)! |
Beta Was this translation helpful? Give feedback.
-
|
That would be super cool! I have a bit of a time crunch for a conference atm, but towards the end of march and onwards I could prepare a small presentation about AbstractImageReconstruction.jl and show it to you two @aTrotier, @cncastillo. More than a year ago I had a briefly talked with Mirco Grosser about migrating MRIReco, but there we mostly talked about just wrapping the high-level I just don't have the extensive domain knowledge to properly design the integration on my own, but maybe together and potentially some other developers/users we can design a plan. In theory that could also be a GSoC project, but it might be too experimental |
Beta Was this translation helpful? Give feedback.
-
|
I would love to see MRIReco at some point being migrated to 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. |
Beta Was this translation helpful? Give feedback.
-
|
Should we start again the MRIReco Community Meeting ? Is the community large / active enough ? @mrikasper I see some activity around KomaMRI @cncastillo :) |
Beta Was this translation helpful? Give feedback.
-
|
Thumbs up for the meetings! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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:
Small issues:
|
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
I don't know how large is the community, but we could also start to do some webinars like BART or gadgetron |
Beta Was this translation helpful? Give feedback.
-
|
Sorry I forgot to reply to this.
I am happy to explain more during a meeting. But basically, I met with my student one hour per week, and talked to him on Slack to help him. 3 hours per week in total maybe? I could dig the GSoC survey where I estimated how much time was spent on my student. But overall it was a very positive experience, there are very talented students applying to GSoC and we can later give them recommendation letters if they apply to a job + the GSoC stipend, so overall is a win-win scenario. We should really start planning a few self-contained projects where we need some extra hands and upload them for students to see, as the next GSoC will be soon!
We should definitely do this. It would be very nice to meet if anyone else is going to Hawaii :). It would be nice to create a logo for the "MR Julia community", we could print stickers and give them during ISMRM. It is a pretty effective way to do some publicity.
Can you tell me what would be the most needed functions? It shouldn't be very difficult to get something working for an initial release of a Pulseq.jl package. I have all the pieces I just need to put them together. We could have a GSoC student implement a few and hopefully have Unitful.jl support.
The Pulseq writer is almost done in JuliaHealth/KomaMRI.jl#284 it just needs an extra push. I have used it already in this work https://archive.ismrm.org/2024/5097.html. For the EPG/PDG I really want to include them, but I think I want to focus on finishing the multi-coil implementation first (@Stockless has some preliminary results) and then make the default Bloch simulator differentiable, so we can optimize Pulseq sequences directly. Maybe we could set a meeting and work together on this! I am just missing some hands to finish these. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @cncastillo
I will create a dedicated topic.
Done : https://github.com/MagneticResonanceImaging/MRILogo.jl but it is still open to discussion :)
My idea for this course is to ask a group of students to build a Quantitative MR sequence (something like a single-slice MP2RAGE for T1 mapping,Variable Flip Angle for T1, MESE for T2, T2 prep sequence) using pulseq. They take a look at the results with Koma and if it works (after I also take a look at the code), we give them access to the scanner to test it. The missing functions that can help with that are:
I can work on some of them and we could see if it is possible to propose them for GSoC |
Beta Was this translation helpful? Give feedback.
-
|
I'll be at ISMRM in Hawaii. Happy to participate there. No time to do anything before then sadly... |
Beta Was this translation helpful? Give feedback.
-
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 :
Related to discussion : #149
Beta Was this translation helpful? Give feedback.
All reactions