Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include information on non-steady state volumes #23

Open
emdupre opened this issue Apr 20, 2020 · 16 comments
Open

Include information on non-steady state volumes #23

emdupre opened this issue Apr 20, 2020 · 16 comments
Assignees

Comments

@emdupre
Copy link
Collaborator

emdupre commented Apr 20, 2020

I can't seem to find the number of non-steady state volumes included at the start of each run. Do these vary by task ?

I ask as an example HCPTRT run (sub-01_ses-002_task-relational_run-01_events.tsv) lists the first stimulus onset at 10.033 seconds, while another (sub-01_ses-002_task-wm_run-01_events.tsv) lists the first stimulus onset at 10.516 seconds. For the listed TR of 1.49s, I would then expect to drop 6 TRs for the first task and 7 TRs for the second.

Having this information available directly in the documentation would help in correctly interpreting this -- at least for me ! Thanks 😸

@pbellec
Copy link
Contributor

pbellec commented Apr 20, 2020

I would like @bpinsard and @jcohenadad to confirm, but I don't think you need to exclude scans due to non-steady state. Those are typically eliminated early, and do not make it to the nifti files. I am not sure where the delay in stimulus onset at the beginning of the scan is coming from. Maybe the timing of the stimulus includes the dummy scan? In that case it would be critical to understand what is dropped directly during transfer from the console, and possibly fix the stimulus timing in the bids collection directly.

@jcohenadad
Copy link
Collaborator

could someone please add in this thread a link to the pdf protocol that was used to acquired the data discussed here? If "Sequence - Part 1 / Introduction" flag is ON, it means that the first volumes are not included in the output DCM files (and a fortiori in the nifti BIDS package).

@pbellec
Copy link
Contributor

pbellec commented Apr 20, 2020

@jcohenadad
Copy link
Collaborator

from this link, introduction flag is off --> the first volumes of the output time series are likely not at steady state

@bpinsard
Copy link
Collaborator

Good question!
@emdupre do you usually drop all the TRs until the first onset?
I guess most people remove a fixed number (3 for instance).
Also, in the multiband sequence, a few single-band references are acquired before the recorded volume starts (from the sound within the scanner and artifacts in the physio, I would say 2 accelerated, and 1 single-band, but it is not documented).
I could go back to the scans with a phantom to have a better idea of when a T1 steady-state is approximately achieved.

@pbellec
Copy link
Contributor

pbellec commented Apr 20, 2020

@bpinsard A related issue is load_confoundsand recommended best practice to load data with nilearn. I wonder if volume suppression should be done at this stage, as part of the confound matrix, just like we do for censoring. This would avoid fMRI time series getting out of temporal sync with all the other info we provide (e.g. stimuli).

@emdupre
Copy link
Collaborator Author

emdupre commented Apr 20, 2020

Thanks all for the quick responses !

@bpinsard I do usually drop a set number of volumes (usually 1or 2 after I expect to have achieved steady state, for a total of eg 5 TRs). That being said, I also usually see different tasks start at the same TR so I was just a little confused about the data structure 😅

@bpinsard
Copy link
Collaborator

For the tasks, it is a question for HCP! It seems like they were each created by different person/labs, not sure how they chose the timings.

@emdupre
Copy link
Collaborator Author

emdupre commented Apr 20, 2020

Fair enough ! 😸 So yes, if we have an idea for which volumes were acquired before the steady state (and appropriate multiband) acquisition was reached, that would be great to know !

For now, I'll assume 5 volumes should be dropped. But please let me know if you see issues, here !

@jcohenadad
Copy link
Collaborator

i would create a mask of GM+WM (they share similar T1), plot the average for each time point, and decide (based on arbitrary threshold) when plateau is reached. That would give you more confidence about how signal varies in your own dataset.

@emdupre
Copy link
Collaborator Author

emdupre commented Apr 27, 2020

OK, I just wanted to follow-up on this, since I sat down with the data for both movie and task:

  • In nibabel's orthoview, I'm not seeing the characteristic intensity drop that I expect from collecting non-steady state volumes (at least based on my experience doing so with GE scanners).
  • Weaker evidence, but: In the movie _events.tsv files, stimuli are reported as starting at exactly TR0.

I'm now leaning towards @pbellec 's initial suggestion that these volumes are in fact being dropped somewhere in the pipeline. To confirm this, I've inspected the stimulus timings for the different tasks, but it's raised a few additional questions:

  1. From my interpretation of the task stimuli, it seems that the movies should have been preceded by a 6 second instruction block. Is this instruction block accounted for in the provided event timings ? That is, does the 0th TR correspond to the start of the movie or the start of the instruction block ?

  2. The psychopy fMRI settings suggest that the TR should be 2 seconds, while the documentation suggests they match the hcptrt acquisition at 1.49 seconds. The header and JSON files themselves confirm 1.49 seconds. So, I'm quite confident it's actually 1.49 seconds and that I'm just interpreting this incorrectly, but I'd feel better with additional confirmation !

Would appreciate any clarification, here !

@bpinsard
Copy link
Collaborator

The instruction block happens before movie and tasks in psychopy (not hcptrt) and is before the scanner is started, so that the stimuli doesn't corrupt the response. With the non-systematic ~15sec delay between the end of the instruction and the beginning of the movie segment, that instruction shouldn't leak in a robust way in BOLD response for the first TRs of the scans.

The movies starts at the first TTL, right after the reference scans that the CMRR sequence acquires. So the movie file is started at the first slice of the first TR.

Each movie segments (the one provided in /stimuli) is edited to start with a black screen, and then a fade-in to the movie. Between movie segments there is an overlap of a few seconds to catch-up, in particular when the cut is automated (can cut in the middle of a shot/sentence). With the HRF delays, the stimuli of the first non-black frame should arrive at 6-7sec=TR4-5. Maybe we should have included a longer black-screen baseline.

The psychopy TR setting is not used anywhere, but I should remove it, good catch. The TR=1.49s for all func scans.

@emdupre
Copy link
Collaborator Author

emdupre commented Apr 27, 2020

Great, thanks for the info @bpinsard ! I'm still a bit confused, and I appreciate your patience helping me work through this !

Looking at bourne_supremacy_seg01.mkv as an example, the fade-in is quite short, with stimuli on screen by the first TR (as indexed by the 0:01 timestamp on my local player). I just want to confirm this is what you meant above.

Otherwise, any insight on how we could confirm that we have in fact dropped the non-steady state volumes somewhere ? And, if we have, I'd just want to circle back to @pbellec 's question for HCPTRT:

I am not sure where the delay in stimulus onset at the beginning of the scan is coming from. Maybe the timing of the stimulus includes the dummy scan?

I don't have access to the EPrime files for HCPTRT, so I just want to confirm that the timing there is still as expected ! Could the delay correspond to instructions, instead of non-steady state volumes ?

Thanks again for your patience !

@pbellec
Copy link
Contributor

pbellec commented Feb 26, 2021

reviving this thread. I am actually still not sure what's going on here. If the movie starts at the first volume, and if somehow Siemens automatically drops the first couple non-steady state volumes, then there could be a few seconds of shift between the fMRI time series and the movies, which is significant. Otherwise, we need to drop some volumes at the beginning of each run.

@bpinsard
Copy link
Collaborator

During multiband acquisition there are:

  • reference volumes (including single-band one(s)): these do not send a trigger, thus do no start the task. A single single-band reference volume (SBRef) is saved, but it is acquired when the task has not started.
  • regular multi-slice volumes: these are all in the series that are exported from the scanner and are all in the BIDS.

Most of the tasks include a black screen at the beginning, but for movies this is encoded in the movie file itself with a fade-in. It is possible that this black screen is a bit short to exclude many volumes, though I feel that the fact that the reference volumes (not present in regular non-SMS sequences) will help reach the steady-state before the real acquisition starts. Also, for the movie segments are overlapping (as it sometimes cut in the middle of a sentence) so that if dropping the first few volumes will remove the black-screen as well as the previously shown stimuli.

Though I agree that we should be more careful in including long-enough beginning and end baseline in future tasks.

@pbellec
Copy link
Contributor

pbellec commented Dec 21, 2022

alright, revisiting this again ... the thread that keeps on giving. Should we recommend dropping the first three volumes?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants