Understanding figure outputs

[marni-23]

Dear Lars,

I am new to fMRI and looking at physiological noise correction. I have found your toolbox to be very helpful and user friendly. Thank you!

I have tried to use the toolbox (via SPM Batch editor) on two different participants using the 3T PPU Phillips example script. I have had varying results and I am particularly interested in understanding the quality control measures to look out for in the output. For instance:

1. What are the key aspects to look out for (in the figures) when trying to understand whether the noise correction worked correctly and how best to proceed with the data?
2. After reading your paper, it seems that if a participant has only a respiratory histogram peak at 0, this participants respiratory data would need to be excluded. In this case, is it reasonable to continue using the cardiac regressors and exclude the respiratory data?
3. I am working with a clinical population (ADHD) and was wondering whether there were certain aspects within the script that you would recommend adjusting to account for this population?

Also, sorry if this is a silly question but could you clarify how to determine the onset slice and how exactly this affects processing of the data?

I have attached here a link to the log files and results from two participants. Apologies for not attaching them here, the files were too large! Would it be possible for you to have a look at these to see if they look reasonable? I'm particularly concerned about the respiratory data in both participants.

Many thanks in advance, Marni

https://drive.google.com/drive/folders/1lxT3LgdFkcuNNtls0tJ5fj1ALcH2DfLa?usp=sharing

[mrikasper]

Dear Marni,

It's great to hear you got PhysIO to work. I have downloaded your data, but it will take a couple of days to get back to you.

In the meantime, did you have a look at our FAQ and the original PhysIO paper, which explains some of the most important plots and quality considerations?

Also, you might want to browse this issue forum here for closed issues with the label physio, because a lot of issues have dealt with physiological recording quality.

All the best, Lars

[marni-23]

Dear Lars,

Thank you for having a look at my data. It's very much appreciated!

I have had a look at the FAQ, the original paper and this forum which have all been extremely helpful in teaching me how to use the toolbox. I will continue to browse these (and other sources) in the meantime to see if they can clarify any issues I'm facing with my plots/data quality.

Best wishes, Marni

[marni-23]

Dear Lars,

Just following up... I have tried to run PhysIO on other participants and it seems that the automatic peak selection does not pick up most of the peaks (please see image attached). I have also ran through the post-hoc manual peak detection process and that doesn't seem to change things much. Any advice on this would be greatly appreciated.

Best wishes, Marni

[mrikasper]

Dear Marni,

My apologies for not getting back to you earlier. I was on vacation and then busy with Covid and the next TAPAS release.

First of all, do you happen to have the SCANPHYSLOG* files for your subject as well - these are the ones I am familiar with for Philips data. The ScanPsaLog* files you provided seem to be similar, but have two important differences:

1. They have 12 columns - instead of 10 or 11 as I am used to from the Logversion 1 or 2, see the Philips/ECG3T_V2 example below
2. There is no gradient timecourse (gx,gy,gz) recorded alongside the physiological time series. This will make it difficult to synchronize the physiological traces to the scan volumes.

If you happen to have the SCANPHYSLOG files, could you please send them to me for further scrutiny? Otherwise we can try to work with these files, it might be as simple as ignoring the extra column.

All the best, Lars

• Your data:

## SPMMRC Nottingham
## 5/17/2022 12:47:46 PM
## 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
# v1raw v2raw  v1 v2  ppu resp vsc  gx gy gz mark mark2
0 0  0 0  4591 -230 0  0 0 0 0000 0000
0 0  0 0  4591 -230 0  0 0 0 0000 0000
0 0  0 0  4591 -230 0  0 0 0 0000 0000
0 0  0 0  4671 -235 0  0 0 0 0000 0000
0 0  0 0  4671 -235 0  0 0 0 0000 0000
0 0  0 0  4671 -235 0  0 0 0 0000 0000

• example Philips/ECG3T_V2:

## Physlog file version = 2
## UniversitaetsSpital Zuerich (SRN = 00072), Release unifycdas (SWID 15.15)
## Mon 03-04-2017 11:56:41
## 8 5 4 3 12 11 3 2 0 0 0 2 0 0 5 5 20 20 0 1 [cal=0, reqid=0]
## Dockable table = FALSE
# v1raw v2raw  v1 v2  ppu resp  gx gy gz mark mark2
0 0  0 0  -639 4608  144 0 29 0000 0210
0 0  0 0  -645 4608  -413 0 -69 0000 0210
0 0  0 0  -645 4608  -542 0 -96 0000 0210

[marni-23]

Dear Lars,

Thanks for getting back to me! And no worries about the delay!

Apologies, I had not noticed that our physio log file format differs from the norm. I have now had a look at all the physio files collected from our experiment and it seems they all have 12 columns. Also, the gradient timecourses are not available for any participant. As such, I've been using the nominal option to derive the slice acquisition timing. Would this be okay?

I have attached here a link to a couple of our log files (A06 refers to the subject above with the peak detection issues). Please let me know if you have any problems accessing the files or if you would like any more information.

Many thanks in advance, Marni

https://drive.google.com/drive/folders/1qp0K0nGYeSDRTrtb3joFV8jMpt9dGFyD?usp=sharing

[mrikasper]

Dear Marni,

Thank you for the additional subjects. What I meant is whether you have another file type besides ScanPsaLog* for your physiological logging. Typically, there is also a file SCANPHYSLOG* saved for each run. Could you check that, please?

Regarding the lack of the gradient traces, this is indeed an issue for synchronization of scan and physiological data. If you use nominal timing and you fMRI runs all ended normally (no premature manual stop of the scan), nominal timing relative to the last (not first) scan is precise up to a few 100 ms...which might still be OK for most physiological applications, but not brilliant.

Maybe you can ask an MR physicist in your group whether these traces could be written out as well. They should look like in the Philips/ECG3T_V2 example.

Alternatively, if you have access to Philips pulse programming, there is a way to change the code to pretend the fMRI sequence is cardiac triggered (only for the logging, it's not actually triggered), and in that case, one of the marker columns will have the onset events of each scan volume automatically.

All the best, Lars

[marni-23]

Dear Lars,

Thank you for your response and sorry about the misunderstanding! Unfortunately, we do not have the additional file you mentioned, we only have the ScanPsaLog files available.

In terms of the synchronisation, we are interested in the brainstem region so it is important that we are quite precise with the synchronisation and the physiological noise correction. Given that we’ve collected all our data, I assume we cannot add these gradient traces in at this point in time? I will be sure to raise the issue about fixing these traces within our group for future studies.

With this current study, would you recommend using PhysIO with the nominal option and use additional noise correction measures to supplement this?

Many thanks, Marni

[mrikasper]

Dear Marni,

I have updated the Physio branch to TAPAS to read in your files with 12 columns, please download and try it out: https://github.com/translationalneuromodeling/tapas/tree/physio

The cardiac data looks reasonable for the subject I checked (A01), though a bit noisy. The respiratory data, however, seems to have phases where the breathing belt was not recording (see yellow highlight in zoom, maybe detached from the subject?), and this will affect subsequent regressors.

You can also spot these constant phases in the histogram as multiple large peaks:

You can still use it as is, just the respiratory regression will not be so powerful.

For the synchronization, you will most likely not be able to get this data for the past subjects (though it doesn't hurt to check the log folder at the scanner, typically it is not automatically deleted). However, as the timing should be the same for every subject and is only protocol (scan)-dependent, you could try to acquire another dataset with the same sequence and either scan trigger markers or gradient timecourse logging switched on. From this, you can infer when the first scan started (or last scan ended) relative to the onset of the logging. Once you know that, you can adjust the log_files.relative_start_acquisition parameter accordingly for all your already acquired data, and keeping the nominal option for the scan timing.

I hope this helps!

All the best, Lars

[marni-23]

Dear Lars,

Thank you for updating Physio to read in my set of files. It works perfectly!

And thank you for having a look at the data. Would you suggest any additional noise correction steps to take when the respiratory regression is not so powerful, as is the case with the above subject?

Regarding synchronisation, I will definitely have a look at the log files in case it is stored at the scanner otherwise acquiring another dataset after fixing the gradient timecourses logging sounds like a reasonable way to overcome our issue.

Thank you for all your help! It’s been really valuable.

Best wishes, Marni

[mrikasper]

Dear Marni,

I am happy it works and will close the issue for now.

Regarding additional noise correction steps, you can always use noise ROIs (anatomical Component correction, Behzadi et al., 2007), which is the data-driven method PhysIO provides. You just need a tissue probability mask for CSF or white matter that you retrieve from SPM's unified segmentation, for example.

But I would make it subject-dependent. If 80% of the respiratory time course are fine, I would still use that.

All the best, Lars