-
Notifications
You must be signed in to change notification settings - Fork 27
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
FSL FUGUE - Image Exception : #3 :: Attempted to divide images/ROIs of different sizes #33
Comments
Could you share some data to replicate this? |
Thank you very much. I´ve sent you an email with the link to the download of the data. |
Hi @tragus1 can you verify that this issue persists in the most recent release of fMRIPrep (1.3.0.post2)? |
I found this thread while searching for a similar error from some of our subjects. I would understand if this is a field map issue because we have some other problems with Philips fieldmaps. The question is: how do we know what is the source of the problem, and what could be a solution? Here is the crash log:
|
Hi @dorianps, could you confirm whether the dimensions of the magnitude file match those of the phase difference? |
The dimensions are the same. |
@oesteban : I looked at the files further. Even though the dimensions of the original magnitude and phase difference files match, the two input files to the fugue command that threw the error have "different" sizes. I put that in quotes because the difference is in orientation, they do have the same size along the anatomical axes. See below c3d output: func_preproc_ses_07_task_restingstate_run_01_wf/sdc_estimate_wf/phdiff_wf/fmap_postproc_wf/demean/sub-12345_ses-07_run-03_phasediff_rads_unwrapped_recentered_filt_demean.nii.gz -info and func_preproc_ses_07_task_restingstate_run_01_wf/sdc_estimate_wf/phdiff_wf/magnitude_wf/bet/sub-12345_ses-07_run-03_magnitude1_avg_corrected_brain_mask.nii.gz -info |
@oesteban We are still stuck with this problem. Any suggestion of how to figure out what might be the problem? Note, this happens with fmriprep 1.5.X, we have processed the rest of the data with that version and are hoping not to need 20.0.X just for 3 subjects. Thank you for helping out. |
To be clear, the original fieldmaps have a common orientation, but they've been changed by the time they get to demean/bet? Or we're failing to normalize to correct orientations? |
The original fieldmap mag/phassediff files have identical orientations/sizes. These are the c3d outputs for those files: c3d sub-R12345/ses-07/fmap/sub-R12345_ses-07_run-03_phasediff.nii.gz -info c3d sub-R12345/ses-07/fmap/sub-R12345_ses-07_run-03_magnitude1.nii.gz -info c3d sub-R12345/ses-07/fmap/sub-R12345_ses-07_run-03_magnitude2.nii.gz -info The two input files have different orientation as I said in the previous post. brainmask is LPI, which is also the orientation of the T1: c3d sub-R12345/ses-07/anat/sub-R12345_ses-07_run-01_T1w.nii.gz -info I don't know how the brainmask is being generated -- whether using the magnitude fieldmap or the T1, but thought the T1 being LPI might be related. |
Hmm. That could be the source. It would be good to validate/normalize input orientations at the entrance to the workflow, to avoid potential mismatches. It looks like FUGUE is orientation-agnostic (otherwise it would be normalizing internally), so it probably makes sense to normalize to RAS or perhaps the BOLD orientation. I won't have time to look into this more deeply until next week at the earliest, in case anybody else does. |
Thanks @effigies for looking into this when you can. |
@effigies just pinging this thread one more time, hoping we can find a fix. With most people working from home, things may not flaw as before, but I am hoping on my end to close this work once the last 3 subjects are processed with fmriprep. Thanks again. |
Thanks for the ping. I haven't had a chance to look into this, but it is still on my list. I'm down to half time due to childcare responsibilities. |
@dorianps Is there any chance that you have a pair of subjects (one passing, one failing) that you could share to help reproduce the issue? |
Sorry @effigies , for some strange reason I am not receiving emails from this thread. Our data are strictly guarded with legal agreements, we can't share them without a DUA. Is there something else we can try (headers, check of temp data, etc.). I think @ins0mniac2 checked a few things on the temporary data without success. |
Checking on the status of this issue. Best I can tell, I'm getting the same error:
|
Thanks for bumping this. The big holdup is finding a suitable test dataset (and finding the time). The Midnight Scan Club dataset has phasediffs, so I'm going to make a pared down version of one of their subjects with data rotated into your orientations. You have LPI for T1w and AIL for your fieldmaps. Edit: Nevermind. I was able to reproduce without modifying the BOLD orientation. Expand for initial orientations...
|
Thanks @effigies . So you were able to reproduce the error on your test data ? |
Yup:
One difference is that the brainmask appears to be in RAS, rather than LPI, so I'm not sure what's different there. Hopefully we can come up with a solution that will make it robust to any such quirks. |
Nevermind. Reorienting to RAS is not needed to resolve this issue and is likely to generate new issues itself. See #98. |
I was only able to get the fsl pipeline working if everything was in the standard FSL orientation (LAS+). |
@mattcieslak In the sense that you had to manually reorient the images before runnig the pipeline, or the pipeline had to be written to reorient its inputs? In either case, I would be wary of that, as we have been reorienting the magnitude images to RAS+ but not the phasediff. As RAS+ and LAS+ will have the same dimensions and voxel sizes, we would not see the error in this issue, but I think you'll be masking an LAS image with an RAS brain mask and getting bad results, because of the |
Ah, I was thinking of the topup pipeline in qsiprep. The phasediff shouldn't need this reorientation |
Okay. We should make sure, though, that if the TOPUP pipeline is potentially permuting or flipping axes of input images, that |
@tragus1 @dorianps This should be resolved in fMRIPrep 1.5.10 and 20.0.6. Please let us know if it fails. Thanks very much for your patience, and also your persistence in prodding us to resolve this issue. It was quite a subtle bug that all previous versions of fMRIPrep were subject to. I would highly recommend re-running your earlier subjects, though you can safely reuse the working directories. |
Appreciate your effort @effigies . Thanks much! |
@effigies Thank you for fixing this. I will see to rerun the 3 subjects that had this issue. P.s. I am assuming this is the only thing changing 1.5.9 -> 1.5.10, so it is safe to drop my old singularity container and keep only the last one with the processed data. |
Yes. This is the only change: nipreps/fmriprep@1.5.9...1.5.10 |
Just checking on this - I noticed in the release notes for fmriprep 20.0.6 it says that there is a critical bug in earlier versions for phasediff fieldmaps. Is this the issue that is referenced? And the release note also says that there may be subtle errors in SDC for earlier versions. Has this been confirmed or is it only a possibility? We aren't sure if we should re-run all our phasediff data |
@mattcieslak Yes. |
Just to confirm: if the fieldmap data is in LAS+ orientation, an RAS+ mask gets applied without being flipped, causing the displacements to be potentially misshapen? |
Yes. If the fieldmap is in any orientation, an RAS+ mask gets applied without being reoriented. In LAS+ it's likely to be somewhat subtle. |
Ah, that's a tricky one. Was there an announcement to fMRIPrep users about this? I imagine a lot of users will want to re-run their phasediff studies. Thanks for the quick replies! |
It was in the release notes and there is a mechanism in fmriprep that will warn users of older versions, but we don't have a mailing list where we make these outlines. |
The text was updated successfully, but these errors were encountered: