CMMR data quality and feature suggestion

[magerkurth]

Dear Lars

My name is Joerg and I am an MRI physicist at the Birkbeck-UCL Centre for Neuroimaging at UCL. My former colleague Tobias Hauser advised me to get in contact with you regarding the topics below. We would like to have your opinion on the following two subjects CMRR and Gadgetron.

CMRR

We are currently assessing MRI Physio recording using the Siemens hardware for our centre and came across the Tapas PhysIO toolbox which looks very well developed and ideal for processing the data.

Coming from a conservative approach and cautious about the Siemens PMU problems in the past, we compared the data output from the CMRR sequence with the raw data exported via TWIX. During the experiments, we short circuited the ECG leads with a brass screw to form loops to pick up the gradients, allowing direct comparison of the scanner trigger data of the CMRR, the optical trigger output, which we lengthen and feed back to the "external 2"  PMU input, and the actual scanner operation.

Our findings were:

Cardiac

• CMRR and TWIX data are identical from a scaling and sampling point of view
• The CMRR data has random dropouts (signal=0), where the TWIX data has not

ECG

• Same as cardiac compared to Twix, but drop outs in the CMRR signal. See example plot below

Resp

• Same as cardiac compared to Twix, but drop outs in the CMRR signal. See example plot below

Trigger

• CMRR, picked up gradients via ECG and Ext input matches, but a small constant time offset towards the picked up gradients. This is to be expected and is not a concern

Did you came across the drop outs? Do you have any idea why they arise and whether they are always short enough to get smoothed out during filtering? We know that it does not relate only to our system, as the data on https://github.com/CMRR-C2P/MB/issues/253 show similar drop outs.

Perhaps this is really a CMRR issue but since you will have dealt with data from their sequence.

Gadgetron

( https://github.com/gadgetron/gadgetron/wiki/Manual)   We also run sequences where we export a Twix-like physio (and MRI) data stream using the Gadgetron on-line streaming framework. The file format for this is ISMRMRD (https://www.ismrm.org/MR-Hub/reviews/ismrmrd.html). We can also can do this for the CMRR sequence. The optical trigger is re-injected via the external input 2 as described, to ensure synchronisation. Currently, the BIDS format seems the best option to provide raw data to your toolbox using such an injected trigger. The Generic text data seems not to allow for a trigger trace. Is this the case? We are looking for a straightforward and general way to import the ISMRMRD physio data to Tapas with minimal user intervention based on one file only.

We are wondering whether to design a general data input scheme via a Matlab structure? This would allow also to provide sequence settings automatically extracted from the Gadgetron ismrmrd data file. For example

physiodata.cardiac.data = …. physiodata.cardiac.samplerate = 200 physiodata.respiratory.data = …. physiodata.respiratory..samplerate = 50 . . physiodata.sqpar.Nslices = 20 physiodata.sqpar.TR = 1 . physiodata.custom.subject.id = 1234 physiodata.custom.scan.completed = -1 . etc.

We are aware that there are a lot of data formats available already in this toolbox. But a structure would allow for more flexibility in terms of extensions in the future and custom fields (not currently used by Tapas).

I am happy to take on this job together with my colleague who will work on the Gadgetron side. I myself, have 15 years of Matlab experience, programmed several in-house SPM toolboxes and worked extensively with physio data recording and its real-time processing in the past.

Please let me know what you think about our data findings and data input proposal. Would be great to talk online if you prefer.

BW

Joerg

[mrikasper]

Dear Jörg,

thank you very much for your thoughtful and detailed request. I was really impressed by the degree of scrutiny you applied to compare the physiological logging and timing synchronization on the Siemens system. Let me try to unpack my thoughts:

CMRR

• I developed the CMRR Reader (or "Siemens_VD_Tics", as we called it) without working on a Siemens system myself. @SaskiaBollmann provided a lot of background for the implementation and manual. For a long time, I was under the impression that the Tics-timing based system would be the future of Siemens Phys-logging, but as I learnt in a recent IDEA course, it still seems to be that the classical "VB" logfiles are the default.
• I am no expert on the TWIX export, how do you exactly do that? Do you use the ideacmdtool for manually starting the logging?
• I am not sure I saw the spiking before in the CMRR/Tics-data, but I also looked only at a limited amount of datasets. It might very well be that this is a pulse programming question.
• We did, however, see spikes in HCP data when Samuel Harrison developed his advanced respiratory processing and volume computation, which is now part of PhysIO. There is a recent "despiking" functionality for the respiratory data, and bandpass filtering for the cardiac data (see screenshot) to circumvent this, and it might very well be that this works for your data.
• If the TWIX-export is free of this artifact, I think there is in principle nothing wrong with using the "old" logfile format. You can match the timing of the Logfiles and DICOMs in PhysIO (it uses MDHTime), which should be sufficient.

I hope this helps for now, but I am very happy to have a closer look at the data with you!

ISMRMRD, BIDS and PhysIO Data Structure

I will get back to you soon about this feature request, I think it is a very worthwhile consideration.

All the best, Lars

[mrikasper]

Dear Jörg,

now to follow up on your second topic, which I also find very inspiring:

ISMRMRD, BIDS and PhysIO Data Structure

We are also looking into using Gadgetron and ISMRMRD for data streaming and setting up a vendor-independent image reconstruction pipeline at my new workplace BRAIN-TO Lab. So I am familiar with the general format and concept, but not so much with streaming physiological data from the system in real-time. It would be great to learn more about this!

With respect to the PhysIO Data structure, in principle the physio = tapas_physio_new() struct is something like this (if you scroll through that function, there is a lot of documentation). I have plans for making PhysIO object-oriented in the drawer for years, but it's never been a priority, because most advantages are "nice-to-have" (context-dependent help for input parameters, allowed input value check etc.) and Matlab's object orientation flavour might be confusing for non-computer science users. But if there is enough interest and help in something along these lines, I am happy to make it happen.

If I understand your proposal correctly, I guess the main disadvantage at the moment is that some meta-data in sqpar (Nslices etc.) has to be set up before calling tapas_physio_main_create_regressors(), while the data itself is populated within the main function. What you refer to as physiodata.cardiac.data exists after the tapas_physio_read_physlogfiles call as physio.ons_secs (short for onsets in seconds, an unfitting variable name that exists for historical reasons, est. 2008). Different preprocessing stages (e.g., filtered time courses) and extracted physiological measures from the data, e.g., heart rate variability, are stored there as well (see FAQ).

If you select to save the physio.mat file, all that data is available after running PhysIO as well, and can be used, e.g., to recreate some plots via tapas_physio_review().

So maybe the easiest way to achieve what you want to do, is to allow tapas_physio_new() to take a file as an argument (which could be the BIDS .json header that is extendable) and populate sqpar and custom fields (which you could already add before the call to new() and should be happily copied and ignored, because physio is just a struct).

Again, I have no insight into the realtime workings of ISMRMRD for physiological recordings, but once we work with ISMRMRD files, wouldn't such functionality, combined maybe with an ISMRMRD_To_BIDS-converter (or a tapas_physio_read_physlogfiles_ismrmrd) meet your requirements?

Do you think I represented your feature request well? If not, these were my unfiltered ideas, so apologies for any confusion - I am happy to set up a meeting to understand your use case better.

And in general, help to improving PhysIO is always very, very welcome, so thank you for offering it!

All the best, Lars

[ojosephs]

Hi Lars,

Joerg (@magerkurth) is unfortunately on sick leave at the moment but I'm sure he will want to get back to this once he's recovered.

I can comment a little more on the Twix / ISMRMRD / Gadgetron side. In general, to get the PMU physio data to be stored in the twix meas.dat file a specific sequence flag has to be set. Also physio recording has to be enabled in the "Physio" sequence tab by selecting a trigger option (any will do). Then, when the sequence is run, the physio data are stored in the Twix meas.dat files as "SYNCDATA" packets interleaved with the MR ADC data. We do this for our own IDEA home-written sequences and it seems it is also done in the CMRR sequences if you choose one of their physio logging options since the SYNCDATA are in their meas.dat files in these cases. I think this control is independent of the ideacmdtool direct PMU logging, but am not 100% certain. The method we use is documented in a pdf entitled "Other Miscellaneous Topics" (;-)) from the IDEA course or I can share with you privately if you have an IDEA license, etc. Or it would be appropriate to use the IDEA discourse forum for these issues which are specific to SIemens internal processing.

Twix files with (or without) SYNCDATA packets can be converted to ISMRMRD offline with https://github.com/ismrmrd/siemens_to_ismrmrd or, online, by IceGadgetron (or the Siemens version, "Fire"). In ISMRMRD the "SYNCDATA" are termed "waveforms" (as opposed to the ISMRMRD MR "acquisitions").

Gadgetron can process the "waveforms" similarly to how it handles "acquisitions" so one can incorporate physio data into the reconstuction directly from the incoming data stream. We use this for on-line plotting of the physio data, for example, using the recently re-worked and execellent Gadgetron Matlab interface (https://github.com/gadgetron/gadgetron-matlab).

I hope this helps and look forward to taking this forward.

Oliver