Hi all,
I conducted the preprocess of my fMRI data using fmriprep 0.3.2.
Although every step seems to work well without any errors, the dimensions of resulting preprosessed fMRI data (sub-*_bold_space-MNI152NLin2009cAsym_preproc.nii.gz) mismatched each other. In my case, there are two types of dimensions 65x77x65 and 65x78x65. When I analysed the same data using fmriprep 0.2.0, all preprocessed images had same dimensions (65x77x65).
How can I solve this issue?
Sincerely,
Yuki
Do you mean there is a mismatch across subjects?
Could you check what is the resolution and dimensionality of the input data for cases that produce 65x77x65 and 65x78x65 output files respectively?
You can also run BIDS Validator on your input data - it should pick up any inconsistencies in FOV and resolution across subjects.
I’m sorry to disturb you again.
A mismatch happens across subjects.
All input func and anat (T1) images have 64,64,39 dimensions (3x3x3 resolution) and 256,256,170 dimensions (1x1x1 resolution), respectively. Of course, I checked my own data using BIDS Validator before the analysis. Although it did not report any inconsistencies in dimensions and resolution of input images, the number of func volumes are different each other because of the task characteristics. However, the resulting mismatch seems not to depend on the number of volumes.
This is weird. Would you be able to share one subject that gives you 65x77x65 output and one that gives you 65x78x65 output?
Alternatively, could you report the outputs of fslhd or nib-ls or other tool for inspecting headers for the input _bold files make FMRIPREP output inconsistent output dimensions?
Thank you very much.
This is the information of input func images that will lead to different dimensions each other.
func
data_type FLOAT32
dim0 4
dim1 64
dim2 64
dim3 39
dim4 884
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 16
nbyper 4
bitpix 32
pixdim0 0.000000
pixdim1 3.000000
pixdim2 3.000000
pixdim3 3.000000
pixdim4 2.000000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.0000
cal_min 0.0000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 0.000000
time_offset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 -2.999992 -0.004186 0.005285 94.434212
qto_xyz:2 -0.004769 2.979873 -0.346891 -91.965942
qto_xyz:3 0.004766 0.346899 2.979872 -37.606453
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -2.999992 -0.004189 0.005236 94.434212
sto_xyz:2 -0.004766 2.979873 -0.346891 -91.965942
sto_xyz:3 0.004717 0.346899 2.979872 -37.606453
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Posterior-to-Anterior
sform_zorient Inferior-to-Superior
file_type NIFTI-1+
file_code 1
descrip FSL5.0
aux_file imgComments
sizeof_hdr 348
data_type FLOAT32
dim0 4
dim1 64
dim2 64
dim3 39
dim4 884
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 16
nbyper 4
bitpix 32
pixdim0 0.000000
pixdim1 3.000000
pixdim2 3.000000
pixdim3 3.000000
pixdim4 2.000000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.0000
cal_min 0.0000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 0.000000
time_offset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 -2.998093 -0.101029 -0.035066 98.790871
qto_xyz:2 -0.101533 2.997967 0.043454 -98.669281
qto_xyz:3 -0.033579 -0.044614 2.999480 -15.440605
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -2.998093 -0.101029 -0.035080 98.790871
sto_xyz:2 -0.101533 2.997966 0.043454 -98.669281
sto_xyz:3 -0.033593 -0.044614 2.999480 -15.440605
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Posterior-to-Anterior
sform_zorient Inferior-to-Superior
file_type NIFTI-1+
file_code 1
descrip FSL5.0
aux_file imgComments
Hmm - everything looks good - I still have no idea why you are getting different dimensions. If you rerun the subject with unexpected size do you get the same results?
I have not tried. I’ll check it.
I reanalyzed one subject with unexpected size and got the completely same results (unexpected dimensions again). Therefore, this is not due to some uncertain factors.
I have analyzed the same data set in SPM many times, but I have not experienced this kind of mismatch. In SPM, the dimensions are clearly defined. In fmriprep, how are the dimensions of outputs defined?
I’m sorry I have not mentioned clearly, I analyzed my data with --no-freesurfer option. I’m not sure this is related with the resulting dimensions.
In FMRIPREP we are using the voxelsizes of the original data to define the size of the output volume (to avoid producing too big files). Here’s the relevant piece of code: https://github.com/poldracklab/fmriprep/blob/master/fmriprep/workflows/epi.py#L758
I wonder if slice time correction has something to do with this. Does your input dataset include slice timing information? If so it might be worth running the workflow with --ignore slicetiming.
Would you be able to deface the that subjects T1 and share its data at chrisgor@stanford.edu?
I see.
Thank you for your suggestion. Although I tried --ignore slicetiming option in one subject with unexpected size, the output was completely same.
I cannot share my data with you because of ethical rule in my country, even the case of defaced data. I’m really sorry for inconvenience.
I’m not sure with this mismatches, but I think I can reslice outputs and use in group analysis anyway.
I found a dataset witch which I was able to replicate this problem. Here’s a proposed fix: https://github.com/poldracklab/fmriprep/pull/513