-
Notifications
You must be signed in to change notification settings - Fork 11
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
Comments
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. |
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). |
@jcohenadad I think all that is part of the docs, here https://docs.cneuromod.ca/en/2020-alpha/_static/mri/functional_protocol_HCP-trt.pdf FYI linked here https://docs.cneuromod.ca/en/2020-alpha/MRI.html#functional-sequences |
from this link, introduction flag is off --> the first volumes of the output time series are likely not at steady state |
Good question! |
@bpinsard A related issue is |
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 😅 |
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. |
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 ! |
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. |
OK, I just wanted to follow-up on this, since I sat down with the data for both movie and task:
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:
Would appreciate any clarification, here ! |
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. |
Great, thanks for the info @bpinsard ! I'm still a bit confused, and I appreciate your patience helping me work through this ! Looking at 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 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 ! |
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. |
During multiband acquisition there are:
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. |
alright, revisiting this again ... the thread that keeps on giving. Should we recommend dropping the first three volumes? |
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 😸
The text was updated successfully, but these errors were encountered: