Different start times of cardiac and respiratory logging in Siemens VE12

[viktor-pfaffenrot]

Hi all,

thank you very much for providing such an extensive toolbox!

I am using a Siemens scanner with VE12 software baseline and a 3D-EPI sequnce and unfortunately, we need to start the physio logging one at a time instead of all at once as this would result in the infamous stop-after-5-mins error if no ECG is connected.

Although the software baseline is VE12, I am using the Siemens (VB,./pulse/.ecg/*.resp) option as this is the output of the ideacmdtool logger.

I am synchronizing relative to the first volume and think I managed to find the correct start time of the first logging file relative to the 1st trigger but as logging of the other physiofile has started later, I think providing only one relative acquisition start time is wrong.

I am not sure if I can fiddle around with the code to make TAPAS accept two different start times (one for cardiac, one for respiration).

Might there be a quick solution to that?

Many thanks!

Viktor Pfaffenrot

[mrikasper]

Dear Viktor,

My apologies for the late reply, it must have slipped my attention during the end of the year crunch, and now I am on parental leave. Thank you for using PhysIO!

In principle, PhysIO should take care of the differing starting times automatically, reading the LogStartMDHTime from cardiac and respiratory logfile individually and then synchronizing the time vectors before applying the logfiles.relative_start_acquisition value.

If you have provided the dicom (header) file of the first volume as logfiles.scan_timing input, you will also not need to specify any manual adjustment and can just set logfiles.relative_start_acquisition = 0, because it uses the dicom timestamp to synchronize the time vectors.

If you want to look at the inner workings of that in the code, it's in tapas_physio_read_physlogfiles_siemens. (Note that there will be a new release soon with some changes to that code).

Let me know if this clarifies things for you.

All the best,
Lars

[viktor-pfaffenrot]

Dear Lars,

thank you for your reply and I apologize for only now finding the time to look at it. I should have mentioned that I am working with a 3D-EPI, so I think providing the dicom as start is not working as it looks for slice events which never happened. Hence, I needed to create a small script which finds the relative start times of both cardiac and respiration logs relative to the trigger log.

But if I get your answer correctly, PhysIO aligns the cardiac and respiratory logs as if they have started at the same time and then shift them wrt the relative start time I give, is that correct? If yes, I think I don't need to worry about it.

Could you maybe provide one or two words on how to check that it works? I guess looking at tSNR gains is one option but maybe there are more?

Many thanks and all the best,

Viktor

[mrikasper]

Dear Viktor,

I am not sure I understand the issue about the 3D EPI - is it about the sequence itself (for example, the trigger does not occur at the beginning of the volume) or the DICOM header (the fields for the start time are labeled differently than what PhysIO assumes)? In general, we only need one time stamp for the first (or last) volume and a valid volume TR to get the synchronization from the DICOM file correctly. The slice events are not used, I believe, and slice timing is only important for the later subsampling of the nuisance regressors.

I also checked the alignment procedure again, because I thought you might have misunderstood me, but it turns out you probably discovered a bug.

So what PhysIO should be doing, is:

1. PhysIO will use the individual time stamps of the cardiac and respiratory logfile to create a time vector, so it will respect a different start time.
2. It will then subtract your relative input start time logfiles.relative_start_acquisition from both time vectors.
3. Finally, it should interpolate cardiac and respiratory traces onto the same time vector (with earliest start and latest end time, smallest sampling interval) if necessary.

Unfortunately, step (3) only happens for other formats (e.g., GE or BIDS, see tapas_physio_read_physlogfiles_bids l.266), but for Siemens, I just assumed (because of the equal interpolated sampling rate for both logfiles) that the longer logfile has the correct time vector and perform simple zero-filling for the shorter trace (see tapas_physio_read_physlogfiles_siemens l.283). This might work most of the time if the time vectors are indeed starting at the same time, but in your case (which is not so unusual) will lead to wrong timing for one of the two traces.

So thank you for spotting this, I will have to fix this.

Regarding checking the outcome of the synchronization, you are right that the best way to look at this is in the statistical maps of the nuisance regressors (e.g., separately for cardiac and respiratory RETROICOR regressors in F-contrasts). In our 2017 paper, Fig. 7 we show how drastically a failure in cardiac R-wave detection deteriorates correction quality (and F values). Synchronization issues could look similarly.

I have recently given a tutorial with some demo code for CUBRIC in Cardiff to show how to generate the regressors plus nuisance-only GLM and use automatic contrast generation and reporting (using tapas_physio_report_contrasts) in SPM. Take a look at https://github.com/BRAIN-TO/cubric-physio

All the best,
Lars

[alexsayal]

Hello,

I may have contributed to this issue here #234 , but please check (I only spotted your issue now).

All the best,

[mrikasper]

Dear Alexandre,

Thank your for bubbling this up again - I don't think you are at fault, as far as I remember, this was never dealt with correctly to begin with. I hope I can fix it for the next release - but help is always appreciated :-)

All the best,
Lars