MRM Highlights
All Posts
By Agah Karakuzu
Leveling the development of pulse sequences is far from a bed of roses. Moreover, product sequences often leave researchers in the dark about implementation details that can contribute to differences in multicenter studies. The authors of the May MRM Highlights pick propose a powerful yet lightweight software solution, gammaSTAR, which was recently described in MRM in a paper entitled “Portable and platform‐independent MR pulse sequence programs”. We sat down with Cristoffer Cordes and Matthias Günther from the University of Bremen and Fraunhofer MEVIS and discussed how their gammaSTAR software might pave the way for unified, vendor-neutral and collaborative pulse sequence development.
MRMH: How did you get involved in MRI research?
Cristoffer: I started my academic career studying mathematics in Bremen, my home town. I like to work with abstract and theoretical concepts and that’s why I chose mathematics to begin with. Then I went to South Carolina for a year to do a master’s degree in a medicine-related field. When I returned to Germany to do my PhD, I got interested in a fascinating field that suited my interests perfectly, namely MRI simulation! So, my PhD topic was decided, and it later translated into the gammaSTAR framework.
Matthias: My history with MRI dates back 25 years. I was doing my German diploma thesis in a completely different field, particle physics. Although this topic was very interesting from a theoretical perspective, its application was less exciting. One day a friend of mine asked me whether I might be interested in a completely different field, MRI. I thought I could at least give it a try. At the time, my wife said “you will get bored after six weeks”, but I’m still working on it now and I really don’t think I’ll ever get bored with it. It is very exciting working in this field.
MRMH: What led you to the idea of developing a vendor-agnostic framework for pulse sequence programming?
Cristoffer: During my PhD, I had one big problem: I had the textbooks, but I did not have the sequences. I wrote my software to calculate theoretical signals, but found it virtually impossible to get it on the scanner easily. This is how the gammaSTAR project came about. Pulse sequences tend to get really complex over time and hard to maintain. I get real joy from trying out new ways of dealing with this complexity.
Matthias: My struggles came when we started working on arterial spin labeling (ASL). We were trying to introduce this really neat technique into clinics. This meant a lot of collaborators using our sequences. At a certain point, due to vendor and version issues, we found ourselves having to provide 8-9 different versions of our ASL sequences. As a result, it was not always the same MRI physics being played out on different systems. Even though the results looked similar, we were still getting differences. Eventually, we decided we needed to separate MRI physics from the hardware implementation, and that’s why we decided to develop gammaSTAR.
MRMH: What advantages does gammaSTAR offer users and developers?
Cristoffer: With gammaSTAR, you can dive directly into a sequence. You can see the calculations from protocol to final pulse shape, and get instant feedback if you change one of the input parameters. All that is possible without installing anything on your computer! All you need is a modern web browser; you don’t even require internet access or access to our servers, because it’s all self-contained. The framework is really efficient thanks to graph structures, to the point that it even enables real-time imaging.
Matthias: You need a few hundred kilobytes to describe a full-fledged sequence. Furthermore, you can easily make it part of the DICOM header. With this piece of information, you, eventually, can take an image from a Siemens scanner and run exactly the same sequence on a Philips, GE or a Bruker system. It is a really huge effort to save all the MR physics in a relatively tiny container.
Cristoffer: We designed gammaSTAR to work on the scanner without having to compile a sequence. The sequence can still be changed after being loaded on a scanner. It can be adapted to cope with different hardware limitations. You can also change various other parameters such as slice positions and resolution or certain preparation modules.
Matthias: With a web browser interface, we can really start to think about collaborative sequence development. The web-based technology of gammaSTAR makes it much easier to jointly develop sequences.
MRMH: Could you describe the process of developing a new gammaSTAR sequence? What do I need to run it?
Cristoffer: If you want to develop a gammaSTAR sequence, the best starting point is a sequence that already exists. Then you can add to that, parameterize it and connect it to your scanner. It will likely fail at the first try (a standard event in any pulse sequence development process) if you connect it right away. Therefore, you first need to debug it and run some checks to see whether all the events are physically feasible from a hardware point of view. Then you can export it to a JSON file and place it in a certain directory in your scanner workstation. If the runtime still passes after you hit the start button, you will obtain your measurement. You can choose to use the native reconstruction framework, or open alternatives. We’ve tried Gadgetron and it works nicely.
Matthias: The gammaSTAR driver is a sequence that interprets the JSON file to run the hardware. Right now, this driver is implemented similar to a research sequence, and therefore requires a research license. Of course, the ideal solution would be for the driver to be legally part of the product of the manufacturers on all systems.
MRMH: How do you see publicly available pulse sequence descriptions facilitating reproducibility in MRI research?
Matthias: In publications you can’t adequately describe in all details what you’re doing and how the sequence works. This is their main limitation. When you try to implement something from another publication, you therefore find this to be really difficult. There are too many degrees of freedom and many different ways of implementing something, and much of this is not specified. Yet this information can make a huge difference to the outcome.
Cristoffer: Currently, many techniques cluster around a specific vendor and a specific set of people who have a research agreement, and that research only takes place within this small cluster. Obviously, this is not good from the perspective of communicating pulse sequence development and many opportunities are missed due to this problem. Maybe we can repeat the success of the ISMRM Raw Data format (ISMRMRD) for pulse sequences. I hope to see an increase of related discussions at the ISMRM Annual Meetings.
Matthias: We have three vendor-defined sub-communities in MRI. Within each community, it is relatively easy to share code. But, if you want to compare your method to existing state-of-the-art techniques, it is almost impossible to do this across sub-communities, because you would have to re-implement them. This is a problem I hope we can get rid of some day. We should be able to download pulse sequences from the web and run them on our scanner regardless of what brand we have.
