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

Revisiting ICA Aroma and SPM 12 #47

Open
EmilyBelleau opened this issue Apr 20, 2020 · 4 comments
Open

Revisiting ICA Aroma and SPM 12 #47

EmilyBelleau opened this issue Apr 20, 2020 · 4 comments

Comments

@EmilyBelleau
Copy link

Hello,

I wanted to revisit the discussion of incorporating ICA Aroma with SPM 12 processed data.

I understand that there is a grid size difference with SPM 12 and ICA Aroma (which uses FSL grid size).

I am not 100% sure how to correct this/adjust for this, particularly if one wishes to stay in SPM12 space for subsequent steps. Is this possible to do?

Also, I am not 100% sure what SPM 12 output I should feed into ICA Aroma. For example the warping parameters in SPM 12 are contained in y and I_y labeled nifti files. Then the realignment parameters are contained in an rp.text file....can ICA Aroma read this format?

I would appreciate any guidance!

Emily

@mangstad
Copy link

If it's the same grid size issue we were having, then this pull request will fix it:
#32

It's been there for a year and a half with no comment and no other fix implemented.

Basically, AROMA checks voxel size, if it's not 2mm it does a resampling to the correct voxel size and grid it needs. But if the data is 2mm but on a different grid size it just crashes. That pull request just expands the voxel size check to also check the grid dimensions.

@maartenmennes
Copy link
Owner

Hello,

yes, there is a grid size difference, but I believe there is also an origin difference between FSL and SPM, therefore it's not a simple as resampling the SPM data to the FSL grid. At least that's what I think is happening, I should get myself some recently processed SPM12 data to verify.

That is also the reason why that pull request has not been ingested yet. Resampling with a different origin could lead to parts of your brain being misaligned with the masks we use to check edge and CSF overlap, this in turn could lead to incorrect component classification.

With SPM data I would go for the following option:

  1. save preprocessed and resampled(!) SPM data (preferably without highpassfiltering but I think that's easy in SPM as the filters are added to the design matrix)

  2. obtain 3dof registration between SPM brain and FSL MNI152 2mm brain (this should theoretically result in an identity matrix with non-zeros in the last column to accommodate potential offset) (flirt -in SPM -ref FSL -omat SPM2FSL.mat -out SPM2FSL -dof 3)

  3. bring SPM preproc data to FSL space by applying obtained registration (flirt -in mypreproc -ref FSLMNI152 -applyxfm -init SPM2FSL.mat -out mypreproc2FSL)

  4. apply AROMA using the command for data that's already in MNI152 space (see the manual), providing the rp.txt file should work as advertised

  5. then go back to SPM for the rest, either keeping your data in MNI152 FSL space, or bringing them back to the SPM grid by doing the reverse of step 2 and 3

Would this make sense?

@mangstad
Copy link

Looks like flirt doesn't allow 3 dof transforms. Trying with -dof 3 results in:
Erroneous dof 3 : using 6 instead

Running this: flirt -in avg152T1.nii -ref MNI152_T1_2mm.nii.gz -omat SPM2FSL.mat -out SPM2FSL -dof 6
Using the MNI152 2mm from FSL and the avg152T1 from SPM results in a 4x4 identity matrix. Though oddly, in this case the avg152T1 seems to be on the same grid as the MNI152 from FSL as well, 91x109x91, so it seems that's not actually the default space it's normalizing into. I'll have to look into it further to confirm.

@maartenmennes
Copy link
Owner

thanks! It would indeed be good to trace the source of the grid difference, super annoying...

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

3 participants