No clear way to ignore known dummy frames for ICA-AROMA, etc... #13
Comments
|
It seems to me like a very reasonable feature that we can add and set on by default. WDYT @chrisfilo @jdkent ? |
|
So we already detect non-steady-state volumes. Would we be able to reuse that? And is that a sensible default behavior? |
|
My concern would be relying on the non-steady-state detector working
equally well for all subjects. I think having a truncation based on that as
a default would be good, but would also like a switch to explicitly (and
always) drop the first 4, etc...
Ideally, we could leave the frames in, use them for registration, then drop them for the rest of processing.
|
|
That seems reasonable. My main concern in asking is whether we can avoid adding more options, when we don't need need to. Come to think of it, I wonder if there's anything in BIDS indicating the first non-dummy scan. It seems like the place to encode information like that is in the dataset, not in the command line arguments. |
|
Interesting problem! My intuition was that ICA-AROMA would generate noise component(s) that were associated with the dummy frames and wouldn't (significantly) impact the other signal components, but this wouldn't be the first (nor the last) time my intuition was incorrect. @alexlicohen When you compared the truncated versus non-truncated ICA-AROMA methods, you truncated the non-truncated data after ICA-AROMA, correct? I assume so, but I want to be explicit. I think I have some data that can play with truncating a different number of volumes and see if the components change. As for the general process of truncation (outside the context of MELODIC/ICA-AROMA), I understand that this can be accomplished with adding columns to the design matrix with a "1" in the row that represents the volume you wish to ignore and "0"s for every other row. Given that is correct, you can effectively remove that volume without manipulating the data. My concern for changing the number of volumes that are output by fmriprep is that it may change the interpretation of the Thus if we decide that dummy volumes do negatively impact the generation of MELODIC components, then we could remove the volumes before MELODIC, run ICA-AROMA, and then either:
|
|
Yes, we basically trimmed the file before fmriprep, or trimmed the file after the nonagress ICA-AROMA. We have also been trying truncating the non ICA-AROMA files (tsv and nii.gz) after fmriprep for comparison…
…-Alex
On May 17, 2018, at 5:59 PM, James Kent ***@***.***> wrote:
Interesting problem!
My intuition was that ICA-AROMA would generate noise component(s) that were associated with the dummy frames and wouldn't (significantly) impact the other signal components, but this wouldn't be the first (nor the last) time my intuition was incorrect.
@alexlicohen <https://github.com/alexlicohen> When you compared the truncated versus non-truncated ICA-AROMA methods, you truncated the non-truncated data after ICA-AROMA, correct? I assume so, but I want to be explicit. I think I have some data that can play with truncating a different number of volumes and see if the components change.
As for the general process of truncation (outside the context of MELODIC/ICA-AROMA), I understand that this can be accomplished with adding columns to the design matrix with a "1" in the row that represents the volume you wish to ignore and "0"s for every other row. Given that is correct, you can effectively remove that volume without manipulating the data.
My concern for changing the number of volumes that are output by fmriprep is that it may change the interpretation of the events.tsv file if the fMRI data was constructed for a task. I like @effigies <https://github.com/effigies> suggestion to incorporate the # of dummy volumes in the dataset itself
Thus if we decide that dummy volumes do negatively impact the generation of MELODIC components, then we could remove the volumes before MELODIC, run ICA-AROMA, and then either:
keep the volumes removed (and hope the events.tsv accounts for this)
add the unaltered dummy volumes back in and pad the aroma confounds in the confounds.tsv with the average of the component (or 0?)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/poldracklab/fmriprep/issues/1136#issuecomment-390027146>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIPa_xygPpDoJLzvCsbDUAKvXtpak_-kks5tzfK-gaJpZM4UDrgJ>.
|
|
We could do what we are doing already for compcor - see nipreps/fmriprep#361 |
|
Yeah, and I think @alexlicohen was saying that would be a reasonable default (speaking of which, is there a citation for AROMA or CompCor or similar algorithms performing more reliably with dummy scans removed?), but there should be a way of specifying the known number of dummy scans. I agree that's useful, but think it makes more sense to be encoded in BIDS metadata that we read. Is there such a field, or would you have any objection to proposing such a field? |
|
Yes, we've got two fields, albeit now I see there is a typo in spec 1.1.0 (the first one should be "...discarded by the scanner (as opposed to...)
|
|
Thanks for reporting the typo - I fixed it in the current draft. Some questions/comments:
|
|
I'll look into nipreps/fmriprep#1, and we haven't tried nipreps/fmriprep#2.
For nipreps/fmriprep#3, technically, if NumberOfVolumesDiscardedByScanner is zero, then
we should be dropping the first frames. For modern sequences, this would be
4, etc... and thus you would know that the scanner dropped the frames
already. A separate variable would have to control how many you WANT to
discard (then subtract out how many the scanner already dropped, then how
many the user excised from the DICOM).
|
|
Just to make it clear - I don't oppose adding this feature, but I would like to explore if what we already provide (via non-steady state detection) is sufficient. We iterated over the heuristic a couple of times, but if it is not robust enough there is indeed a need for manual option. |
|
I will look through our tsv files, to be clear, this is what we've tried so far: (Using a subject from the GSP which all retain the nonsteadystate frames: https://dataverse.harvard.edu/dataset.xhtml?persistentId=doi:10.7910/DVN/25833) GSP -> fmriprep, use ICA-AROMA output -> cut 4 frames -> correlation maps There were obvious differences spatially and strength-wise in the maps. We haven't yet tried (but I'm having our RA do this now): We have also done: but not:: |
|
Just to clarify. There are many potential confounds in the confounds.tsv file (including ones necessary for performing aggressive ICA denoising). For your comparison I would only include the columns related to non-steady state. How many non-steady state volumes are detected in your data? Are any of the ICA components picking on them? Are those components classified as noise? |
|
We usually get two columns:
I.e.:
|
|
These findings are consistent with my expectations:
I think the main question is if there are cases where you have evidence of more non-steady state volumes than detected in data which would warrant the manual specification. If not we can just implement the pre ICA denoising using non-steady state detector outputs. |
|
One motivation is to try and replicate the output of an older (no longer supported) pipeline using fmriprep. In that pipeline, the first 4 frames were removed. Other than duplicating the entire dataset sans the first four frames, there is not a current way to do that in fmriprep... I agree that it likely does the detection correctly, and steady state is achieved by frame three in our dataset, but it is not consistent across subjects and I think adding the option of specifically dropping a set numbers is a valid one. (as a general default, I agree with your idea for using the nonsteadystate flags going into the ICA processing.) |
@chrisfilo Can we go ahead and add this for now for testing purposes? Per the original AROMA paper, they did this too:
So the intended use of AROMA is for data that is already all steady state... |
|
Sure - please send a pull request.
Best,
Chris
PS Apologies for brevity and potential typos. This message was composed on
a phone.
…On Wed, May 23, 2018, 7:43 AM Alexander Li Cohen ***@***.***> wrote:
If not we can just implement the pre ICA denoising using non-steady state
detector outputs.
@chrisfilo <https://github.com/chrisfilo> Can we go ahead and add this
for now for testing purposes?
Per the original AROMA paper, they did this too:
Preprocessing of the training set was carried out using tools from the
FMRIB Software Library (FSL; http://www.fmrib.ox.ac.uk/fsl; Smith et al.
(2004), Woolrich et al. (2009), Jenkinson et al. (2012)) and involved *(1)
removal of the first five volumes to allow for signal equilibration,* (2)
head movement correction by volume-realignment to the middle volume using
MCFLIRT, (3) global 4D mean intensity normalization and (4) spatial
smoothing (6 mm FWHM). Importantly, no temporal filtering was applied at
this stage of processing. Next, we applied ICA to the preprocessed
participant-level data, using automatic dimensionality estimation as
implemented in FSL MELODIC.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/poldracklab/fmriprep/issues/1136#issuecomment-391373425>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOkp8cYlMX9cMI-wV51jJ-7oPa-Fuqpks5t1XWLgaJpZM4UDrgJ>
.
|
|
Chris, I wish I could, but I'm not familiar enough with the fmriprep code to know where to change this. Can you point me in the right direction, and/or is someone else available to do this? -Alex |
|
I think the best way would be to add a regression step just before MELODIC You can reuse some of the filtering code from compcor and All of this could be controlled by a command line switch which will alternate between removing detected non-steady volumes, a fixed number or none. I hope this helps! If you open a PR early (as a work in progress) we can guide you more accurately. |
|
Hi @rciric, could you have a look into this discussion and make a suggestion as regards what we can do in this regard in the context of nipreps/fmriprep#1540 ? |
|
This is now built into the fMRIPost-AROMA CLI. |
We are processing the GSP 1000 dataset, which does have dummy frames in the fMRI data, but we want to use the ICA-AROMA output. It would seem more logical to remove these frames up front before MELODIC is run. Informal comparison finds distinct differences in fcMaps between leaving them in vs truncating the file before fmriprep is run. What should be the appropriate sequence of steps here?
The text was updated successfully, but these errors were encountered: