Open-source magnetic resonance imaging: Improving access, science, and education through global collaboration

2.1.1 JEMRIS

JEMRIS, written in C++ but taking advantage of a MATLAB GUI, enables fast and efficient MR simulations.^{63, 138} Pulse sequences can be generated by concatenating multiple sequence objects, such as RF and gradient objects, each having its own set of attributes. It enables the simulation of B1 + transmit field inhomogeneity and of multichannel RF transmit systems; the latter is done by providing multiple RF waveforms, each assigned to a given coil channel. Bio-Savart transmit loops can be simulated, and the option to read external coil files is also provided. Besides predefined waveforms, this software can simulate arbitrary RF and gradient waveforms that can be defined using symbolic analytical formulas. Potential applications include simulating nonlinear gradient encoding or the impact of concomitant fields. This tool has been extended to simulate realistic flow motion.¹³⁹ More recently, JEMRIS has been integrated within an end-to-end open-source MR imaging workflow.¹⁴⁰ This workflow enables running a simulation with JEMRIS or to acquire data on a real scanner using the exact same pulse sequence, making it easier to carry out sequence prototyping and debugging. To execute the pulse sequence on different scanners and reconstruct images, Pulseq interpreters,⁷⁷ the ISMRMRD open data format,⁶¹ and open-source reconstruction tools such as BART⁴⁸ are utilized (Figure 1).

2.1.2 MRILab

MRILab also enables carrying out numerical simulations of MRI experiments.^{72, 141} The user interfaces run on Matlab but interface with C++ code and take advantage of GPU capabilities to enable running on a standard PC. When it was first made available, the main differentiating feature of this software was to model tissues composed of multiple compartments. This makes it possible to simulate quantitative magnetization transfer (MT), multicomponent T₁ and T₂ relaxometry, as well as chemical-exchange saturation-transfer (CEST) experiments. This feature is currently also available in JEMRIS.

2.1.3 KomaMRI.jl

An alternative MRI simulation platform has been implemented recently using the Julia programming language.^{65, 142} It has the advantage of providing cross-platform compatibility and high CPU and GPU parallelization, enabling fast computations. It can read pulse sequence files in Pulseq format (see below) and outputs raw data using the ISMRMD standard. Furthermore, it provides integration with the MRIReco.jl reconstruction software package and other reconstruction programs compatible with the ISMRMD raw data file format.

2.1.4 ODIN

ODIN is a GUI-supported C++ software framework to develop and simulate MR sequences.⁷⁶ Contemporary MRI techniques are available: for example, sequence modules for echo planar imaging and spiral-imaging, parallel imaging with GRAPPA reconstruction, 2D-pulses and field map-based distortion correction.

2.1.5 Pulseq, PyPulseq, and TOPPE

Pulse sequence design using vendor-specific code requires a steep learning curve because it typically utilizes low-level programming languages. This can make the testing of new ideas and the translation of a given pulse sequence to systems produced by other manufacturers very complicated. The goal of these tools was to simplify these procedures by relying on high-level programming languages such as MATLAB (Pulseq^{77, 143} and TOPPE^{93, 144}) or the freely available Python language (PyPulseq^{78, 145}).

Pulseq proposed a new compact file format (“.seq”) for describing pulse sequences, based on a hierarchical representation consisting of a timing table that defines when different sequence blocks occur (Figure 2). The seq files can be generated by running high-level scripts or programmed using the JEMRIS GUI and can currently be interpreted and executed on Siemens, GE (via TOPPE), and Bruker commercial scanners. The development of interpreters specific to other manufacturers' platforms or open-source scanners can be expected in the future.

2.1.6 Virtual MRI scanner

Virtual MRI scanner,^{95, 146} a result from the ISMRM 2019 Junior Fellow Challenge,¹⁴⁷ is a web-based platform that enables running virtual MRI experiments, simulating the interaction with a console, patient registration, and selection of the imaging protocol and sequence parameters. Once the experiment is set up, a “.seq” file is written with PyPulseq and Bloch simulations are carried out using a discrete event approach. An important feature of this software is to outsource computationally heavy tasks to a different computer other than that running the GUI.

2.1.7 Spinach

Spinach is a spin dynamics library that carries out calculations using the quantum description of magnetic resonance phenomena.^{90, 148} Computations of complex systems are made possible in reasonable times by keeping only the main contributions from all possible spin-states in the simulated system. This software has the particularity of being able to support simulations of all forms of MR spectroscopy, including not only nuclear magnetic resonance (NMR), but also electron paramagnetic resonance (ESR) and dynamic nuclear polarization (DNP), among others. This is possible by splitting the code so that all core operations can be performed using a general algebraic abstraction applicable to any finite-state quantum system, whereas a separate part of the code is designed to deal with the specific assumptions required to model each spectroscopy modality.

2.1.8 VeSPA

The Versatile Simulation, Pulses and Analysis (VeSPA) software enables users to create RF pulses, simulate their behavior and compare their performance for use in MR applications, including MR spectroscopy.^{94, 149} The software contains a database of pre-existing RF pulse designs that can be refined by the user, and the designed RF pulses can be exported using multiple file formats including ASCII and vendor-specific formats (Siemens). It is also possible to simulate and analyze spectroscopic data using VeSPA.

2.1.9 SigPy

SigPy is a Python tool that includes toolboxes for MRI reconstruction and RF pulse design.^{87, 150} The latter (SigPy.RF) enables designing, for example, adiabatic, multiband, and B₁⁺-selective RF pulses, including k-space trajectory design and parallel transmit capabilities. It also performs Bloch simulations to predict the performance of the designed RF pulses.

2.2.1 ISMRMRD

Most MR vendors have their own MR raw data format that can only be interpreted using proprietary tools, which makes it cumbersome to create vendor-agnostic image reconstruction and postprocessing software. To facilitate software compatibility regardless of the scanner, at an ISMRM workshop in 2013, a group of MR scientists defined an open-source MR raw data format named ISMRM raw data (ISMRMRD).^{61, 151} The ISMRMRD project also provides a standard for reconstructed image data and open-source converters to translate proprietary raw data formats to ISMRMRD. This community-driven initiative was a huge step towards reproducible science and enabled the harmonization of image reconstruction software.

2.2.2 Gadgetron

In parallel to the development of ISMRMRD, the image reconstruction pipeline Gadgetron was created.^{56, 152, 153} The main aims of Gadgetron are to be flexible and modular by utilizing a chain of individual gadgets. These modules carry out tasks such as noise prewhitening, sorting of the data, iterative image reconstruction, and estimation of quantitative parameters. The input and output of each gadget are standardized so that gadgets can be easily combined to generate tailored image reconstruction pipelines. MR raw data (e.g., ISMRMRD) can be sent to Gadgetron via a Transmission Control Protocol/Internet Protocol connection. This allows for the streaming of data directly from the MR scanner to a custom image reconstruction pipeline. The reconstruction can be carried out on a separate reconstruction server with multiple cores of modern CPUs and GPUs that ensure short reconstruction times. This enables, for example, the reconstruction of highly undersampled non-Cartesian MR raw data with iterative image reconstruction approaches during image-guided interventions. Gadgetron is implemented in C++, but high-level interfaces using, for example, Python, are also available, which merge computational speed with rapid prototyping.

2.2.3 BART

BART focuses on image reconstruction providing a range of solvers and regularization functionals (e.g., total variation, sparsity in the wavelet domain, or low-rank approaches).^{48, 154} It is mainly implemented in C++ and image reconstruction can be carried out via the command line. High-level interfaces using, for example, Python, are also available. BART uses its own format for raw and image data but some support for ISMRMRD is already available.

2.2.4 SIRF

SIRF is a framework that allows for the reconstruction of multimodality medical imaging data such as PET-MR.^{89, 155} Conveniently, the framework provides a unified interface to already existing image reconstruction packages (e.g., Gadgetron for MR and Software for Tomographic Image Reconstruction [STIR] for PET¹⁵⁶). In addition to image reconstruction, SIRF also provides image registration capabilities utilizing NiftyReg and advanced iterative optimization techniques using Core Imaging Library (CIL).^{157, 158} These capabilities also allow for motion-corrected image reconstruction.¹⁵⁹

2.2.5 MRIReco.jl

A more recent software package is MRIReco.jl, which enables MR image reconstruction using Julia.^{73, 160} It provides algorithms for iterative regularized image reconstruction, is ISMRMRD compatible, and also contains an MR simulation module.

Figure 3 shows the reconstruction of the same MR raw data file with Gadgetron, BART, SIRF, and MRIReco.jl. This should not be seen as a comparison of different reconstruction packages but an illustration that all these reconstruction packages can process real MR raw data (a docker file providing all the necessary reconstruction packages and a script to reproduce this figure can be found at https://github.com/ckolbPTB/OpenSourceMrRecon). It can also be used as a starting point to try out and compare different reconstruction packages, avoiding a lengthy installation process.

Apart from Gadgetron, all the other image reconstruction frameworks are aimed at offline image reconstruction, that is, the MR raw data need to be exported from the scanner first. This can be challenging to apply in clinical practice. Yarra is a project that provides a general framework to integrate custom image reconstruction methods in the standard clinical workflow for easy translation of novel developments.⁹⁶

2.3.1 Image registration

Image registration aligns two images so that common features overlap and can be used to compensate for misalignments due to subject motion and geometric distortions, align images from different modalities, timepoints (follow-up scans), or subjects (population studies). Among others, registration makes it possible to combine structural images with functional information and improves tumor delineation for surgical planning.

2.3.2 Image segmentation

Image segmentation techniques extract image features by subdividing the image into different regions. Manual MRI segmentation is still a common practice; however, it suffers from poor reproducibility, user variability, and is a very time-consuming task. Automatic segmentation tools have emerged in recent years using different segmentation techniques (e.g., threshold, clustering, edge, region or atlas-based image segmentation and, more recently, deep learning-based segmentation).¹⁷⁴

3D Slicer

3D Slicer supports versatile visualizations and provides advanced functionality such as automated segmentation and registration for a variety of application domains.^{44, 175} Unlike a typical radiology workstation, 3D Slicer is not tied to specific hardware. An example of the 3D Slicer workflow using different open-source postprocessing tools is illustrated in Figure 4.

2.3.3 Quantitative parameter estimation

Commonly, MRI is used as a qualitative imaging modality, that is, the pixel values of reconstructed images are unitless and individually do not provide diagnostic information. Diagnosis is only possible due to the contrast between pathological and healthy tissue. In recent years this has started to change, and more and more quantitative MR techniques have been proposed, which directly provide quantitative (bio-)physical parameters (e.g., T1 relaxation time or blood flow). These parameters can be estimated by fitting a model to a sequence of qualitative images with different contrasts. Examples of the numerous quantitative tools are electric properties tomography,^{53, 179} blood perfusion quantification,^{67, 180} and susceptibility mapping.^{85, 181} Here, we focus on software packages for quantitative analysis that are actively maintained and documented.

3.2.1 Communication and project management

Community is at the heart of open-source and its main workforce. Open-source projects are often inclusive, interdisciplinary, and intercultural. Communities are typically decentralized, and nonhierarchical, and community members often work voluntarily without monetary compensation and without strict deadlines. Because IP is organized as a common good, open-source technologies live independently from their originators or primarily distribution entities (e.g., companies or research institutes). Consequently, conventional communication and management structures with mostly clear responsibilities, goals, and decision-making hierarchies, are often missing. There is yet no standard solution for community governance. For large complex pioneer projects, such as open-source MRI technology, this needs to be piloted and iterated as the project grows. Today, multiple software platforms support decentralized project development and community management (e.g., GitLab and OpenProject), but they are not yet fully streamlined for efficient use in a corporate scenario and also primarily cater to software development.

This knowledge helps to manage expectations of newcomers to the field who seek rapid results, and leave under the impression of slow, chaotic, and inefficient processes. Open source is not a sprint, it is a marathon, and so is the development of the underlying infrastructure.

3.2.2 Documentation and licensing

Clear open-source licensing and complete, comprehensive documentation is crucial for the successful reuse of open-source resources. Numerous projects lack clear licensing terms, thus the use of these resources might lead to copyright infringement. In addition, the quality of documentation across open-source projects varies greatly. Particularly for open-source hardware, the stakes and the risks are much higher because monetary investment and time to build and test a device need to be invested. It is illusive that documentation standards will be unified across all technological disciplines. Therefore, technology-specific documentation criteria (TsDC, DIN SPEC 3105-1¹⁹) are defined and evaluated in standardization efforts to improve open-source hardware documentation. As experience shows, well documented projects can be reproduced without any or with minimal input from the original creator.

3.2.3 Funding and infrastructure

Currently, there are few funding opportunities specifically available for open-source software projects, and even fewer (if any) for open-source hardware projects. Typically, researchers must find alternative paths by incorporating open-source technologies (e.g., as part of novel research proposals). Overall, more scientific results could be produced if essential proprietary technologies are available open source. A prerequisite for that is dedicated funding schemes. Other mechanisms to free designs would be to extend current open science guidelines and the requirements of public funding to open-source software and hardware.

In addition, no infrastructural support exists for developers after the release of a software or hardware. Even though extra efforts must be taken to create an open-source tool, the investment in the development and documentation of the tool is still reimbursed to some extent for the developer (e.g., through journal publications and increased visibility). However, after the release, there are no incentives and no support for ongoing development, bug fixes, maintenance, and user requests. This is particularly frustrating if the tool developed is successful and needed, because the developer is flooded with user requests. Institutional resources that exist, for example, for technology transfer and the costs associated with expensive patent applications or legal offices dealing with nondisclosure agreements, could be extended or partly transformed to strengthen open-source outputs.

3.2.4 Open-source products

Currently, no, or very few products exist around the open-source projects presented in this review. To accelerate the distribution of technology and results produced with these, more participation is needed by the private sector. Not everyone wants and not everyone is able to reproduce open-source technology and there is strong interest in open-source products.

The challenge is that the principles of open source are difficult to conciliate with standard business models because protection of IP is a common practice to attract investment and to secure sufficient funds for product development. This is especially important for the commercialization of medical devices, which usually take several years to reach the market because of the lengthy certification processes. For such long development times, IP brings some security to investors, at the expense of slower development time, limited adoption, and dramatically reduced collaboration. In open-source–based business models the expertise on product development, support, and customization could be outsourced to the open-source community. Companies are curious but still hesitant to make the effort or take the risk to adapt or even connect with these new ways of value creation. To break the ice and accelerate the process, cooperation with innovation-driven businesses, which traditionally rely on IP restrictions, may need dedicated funding schemes.

3.2.5 Medical devices

Open-source hardware cannot be used as a medical device on humans unless regulatory approval has been given. Regulatory approval and its documentation are lengthy processes that require substantial resources for companies. Currently, no blueprints are available to facilitate the roadmap towards regulatory approval. It has to be evaluated to what extent and in which documentation format open-source hardware and software documentation can be aligned along the regulatory pathway. This would greatly ease the transition from research prototypes to actual products and would require less investment by the private sector. It is already difficult to establish open-source hardware documentation, let alone introduce documentation standards that go beyond current levels. This, together with the missing infrastructural support from institutions, seems to be a challenging task. However, based on observations from open-source software development over the last decades, professional documentation practices are being increasingly diffused into state-of-the art research. This trend was largely supported by dedicated software platforms (e.g., Github or Gitlab) allowing widespread collaboration, while enforcing certain documentation standards through built-in Wikis, project pages, git versioning, project management tools, etc. Software tools and blueprints to support documentation structures for regulatory approval are needed and would close the current gap between research prototypes and medical technologies used on patients.