
Breath-hold free MRI
Image degradation due to the heartbeat and respiratory motion is a major problem in MRI cardiac exams. Many strategies have been developed by the scientific community to handle breathing and heartbeat motion including cardiac gating, tracking, and breath-held cine imaging. However, breath-held protocols can only be performed on patients able to sustain it. This burden affects the comfort of the patient in the MRI tunnel and may yield poor image quality due to inconsistent breath-holding. In addition, breath-holding lessens the effective scan time relative to the overall examination time due to the need for recovery between breath-holds.
The “Imagerie Adaptative Diagnostique et Interventionnelle” laboratory (INSERM U947) has proposed a new method (called GRICS) patented in November 2007 and published in "Magnetic Resonance in Medicine", which allows free breathing during MRI cardiac exams. The algorithm cancels motion artefacts in MR images by solving for both a motion-corrected image and its associated motion model map. The map coefficients relate motion signals acquired from external sensors to actual cardiac and respiratory displacements. With this method, the realization of 2D and 3D clinical protocols in free breathing becomes feasible and cardio-respiratory movements are no longer a barrier to increasing the spatial resolution of MR images.
The initial prototype of the GRICS code was written for the Matlab environment. The aim of this work was thus to "transfer" the GRICS technique for exploitation in a clinical environment and demonstrate its robustness and superiority over existing methods. This required addressing three major points :
-
Transferring the GRICS algorithm to a supercomputer for fast reconstructions.
-
The automatic collection and optimization of physiological information through external sensors and the registration of these data with the MRI raw images.
-
Integration of the GRICS procedure in the pipeline of the MRI machine (General Electric) for a transparent use and exploitation of this new method by the clinician.
The GRICS program was initially redesigned and rewritten in C++ for the multi-core environment. Several optimisation issues were raised and resolved to parallelise the algorithm. This first stage of parallelisation had resulted in a considerable computation time reduction (for 16 cardiac phases: approx. 45 min with the multi-threaded C++ version against 27 hours for the Matlab version). Regarding the stage of parallelisation on an HPC cluster (i.e. reconstruction of cardiac phases on different computation nodes), we preferred to have recourse to a local contractor so that we can focus on the automation of the remaining steps of the imaging procedure (i.e. automatic physiological signal processing and MRI integration).
Physiological signals
The physiological signals are collected using a modified version of the Maglife (Schiller Médical, Wissembourg, France) patient monitoring system. These signals are converted into optical pulses, transmitted outside the scan room through optical fibers, and then processed on the Signal Analyser and Event Controller (SAEC) computer and electronics system.
The SAEC system is a set of hardware (i.e. the sensors) and software designed for managing and post-processing MRI (Acquisition windows signals, MRI gradients …) and physiological signals (Electrocardiogram signals, Respiratory signals …). The initial version of the SAEC developed for the LabVIEW environment allowed for a first prototyping of the GRICS technique, but the solution was no longer suitable for clinical use. The new architecture of the SAEC is based on newly developed
-
digital sensors,
-
a real-time kernel application (called SAEC-RT), and
-
a remote graphical user interface (called SAEC Console) for display and control commands.

MRI-SAEC material configuration for GRICS imaging
The sensors, which had different functioning and communication modes in the LabView version were redesigned and simplified. Indeed, in the previous version, some sensors were developed for direct connection to the Maglife while others used analogue communication interfaces. The new sensors follow a uniform model for signal processing and digital transmission on a serial link with the real-time PC. These developments required regular tests and audits for MRI compatibility as all these sensors are positioned close to the patient and, therefore, they are subject to (i) an intense magnetic field, (ii) magnetic field gradients, and (iii) interferences due to radio frequency emissions.
The “SAEC-RT” is a real-time daemon which runs in a Linux system we have customized with a patch for real-time processing (version 2.6.33.9-rt31). This daemon retrieves the physiological and physical signals from the connected sensors, ensures real-time processing for the cardiac gating, and offers several signal pre-processing algorithms (Bandpass Filters, QRS detection algorithm flavours, single and double respiratory gating,...).
The "SAEC Console" is a graphical application developed under Qt (version 4.x) that serves as an interface for the “SAEC-RT” real-time system. This interface allows the clinician to calibrate and visualise the physiological signals in real time as well as controlling various parameters required for signal processing tasks.

SAEC Console
Summary
An MRI exam conducted with the Matlab prototype of GRICS required several non-optimized and manual steps (see table below). The reconstructed images were usually available several hours (and days) after the MRI exam.
Henceforth, GRICS reconstructions are launched at the end of raw data acquisition and the resulting images are pushed directly to the MRI console. Thus, all 1-6 below operations are now automatic (i.e. elimination of manual interventions between the different stages of reconstruction).
Several parameters can be set to tune the functioning of the optimised GRICS algorithm. Depending on the desired picture quality, the computation time ranges from 53 seconds to 12 minutes. We opted on a choice of parameters for the calculation of the overall image equivalent to twice the time of data acquisition. Thus, we get the images on the MRI console after roughly 4 minutes (speed 200). Investigating Doctors considered this period fine. It is possible to further improve the algorithm so that it quickly displays a low-resolution image in less than a minute (acceleration 1000) and then produce a high-quality version in a few more minutes.

