[BUG] ICA-AROMA - Mask and image must be the same size #870
Comments
oesteban
changed the title
|
After reading maartenmennes/ICA-AROMA#16 I'm surprised this is not happening more often. @jdkent have you run into this before? Potential solution would be to reslice the ICA components to desired resolution/bounding box prior to passing them to AROMA. |
|
I haven't ran into this problem yet, but after reading the issue I'm surprised I haven't. |
|
I push this forward until we get further info from maartenmennes/ICA-AROMA#16 (pinging @maartenmennes) or we find out the proper mask ourselves. |
|
This is not happening more often as typically people stay in native space and provide the transformations to AROMA. That way AROMA can put the melodic_IC file into the FSL supplied - read grid size - MNI152 2mm space which is 91x109x91 in size. as indicated in maartenmennes/ICA-AROMA/issues/16 it was a deliberate choice to bring the components to standard space, rather than bringing the masks to native space. So yes, in this case grid size is unfortunately something to keep in mind... We should implement some proper checking and error messaging in AROMA though. |
|
I was wondering why this is not happening more often in context of FMRIPREP
because we a) feed normalized data to aroma and b) keep the original grid
and resolution of the bold data.
The only way I could see people avoiding this problem in the past was
setting output grid to 2mm space which is 91x109x91.
Could aroma consider reslicing the masks to input data (for example using
nilearn reslice_to_img)? Maybe this could be enabled by a special flag if
you are afraid it could lead to misuse.
Best,
Chris
On Feb 13, 2018 11:33 PM, "Maarten Mennes" <notifications@github.com> wrote:
This is not happening more often as typically people stay in native space
and provide the transformations to AROMA. That way AROMA can put the
melodic_IC file into the FSL supplied - read grid size - MNI152 2mm space
which is 91x109x91 in size.
as indicated in maartenmennes/ICA-AROMA#16
<maartenmennes/ICA-AROMA#16> it was a deliberate
choice to bring the components to standard space, rather than bringing the
masks to native space. So yes, in this case grid size is unfortunately
something to keep in mind... We should implement some proper checking and
error messaging in AROMA though.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#870 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOkp6qO943DaQBS_-oWTEDTUfRn2oZLks5tUoxBgaJpZM4QzjOC>
.
|
|
In the above case AROMA works only if the |
This PR is an attempt to finally close nipreps#870, by ensuring that ICA-AROMA is run in the MNI152Lin space. To do so, the corresponding workflow has been modified, including an internal BOLD resampling workflow. When the user specifies ``MNI152Lin`` as template space, this workflow will be duplicated. One possible optimization to consider in the future is identifying that situation, and avoid the outer resampling when AROMA is selected. However, for a first take I assumed this duplication is not too costly. Other improvements included with this PR are: * [x] Update ICA-AROMA to the latest 0.4.4 release. * [x] Remove the check of ``--use-aroma`` and template. * [x] Update documentation accordingly. * [x] Update naming of non-aggresively denoised images to the new space
From https://neurostars.org/t/runtime-error-invalid-literal-for-int-with-base-10-mask-and-image-must-be-the-same-size-during-ica-aroma-fmriprep-1-0-0-rc8/985?u=oesteban
The text was updated successfully, but these errors were encountered: