Fmriprep fails during nibabel after manual realignment to LPI

[AndrewPapale]

I had to manually reorient an image for this subject where the phase encoding direction was incorrect due to an overly steep obliquity to the bounding box and now fmriprep is failing.

I used the following commands on the BIDS-converted nifti files (both sbref, and BOLD) and also the field maps.

fslorient -deleteorient BOLD.nii
3drefit -orient LPI BOLD.nii

But I am getting this error when trying to run fmriprep like usual:

File "/usr/local/miniconda/lib/python3.7/site-packages/nibabel/fileslice.py", line 681, in read_segments raise ValueError("Whoops, not enough data in file")

Any thoughts? Should I try running dcm2niix on the raw data, transform, and then BIDS convert with clpipe/heudiconv before running fmriprep?

Thank you,
Andrew

[effigies]

This indicates to me that you have a truncated file:

File "/usr/local/miniconda/lib/python3.7/site-packages/nibabel/fileslice.py", line 681, in read_segments
    raise ValueError("Whoops, not enough data in file")

Could you share the header and the total size of the file at each stage? e.g.

fslhd <file>
du -b <file>

[AndrewPapale]

Thank you for your help! I immediately notice that the file is truncated. This occurs during the 3drefit step. Therefore, I’ve included the output of 3drefit at the bottom here.

Before re-orienting:

351817180 sub-219392_task-clockRev_run-01_bold.nii.gz

filename	sub-219392_task-clockRev_run-01_bold.nii.gz

sizeof_hdr	348
data_type	INT16
dim0		4
dim1		64
dim2		64
dim3		45
dim4		1291
dim5		1
dim6		1
dim7		1
vox_units	mm
time_units	s
datatype	4
nbyper		2
bitpix		16
pixdim0		-1.000000
pixdim1		3.125000
pixdim2		3.125000
pixdim3		3.100000
pixdim4		0.600000
pixdim5		0.000000
pixdim6		0.000000
pixdim7		0.000000
vox_offset	352
cal_max		0.000000
cal_min		0.000000
scl_slope	1.000000
scl_inter	0.000000
phase_dim	1
freq_dim	2
slice_dim	3
slice_name	Unknown
slice_code	0
slice_start	0
slice_end	0
slice_duration	0.000000
toffset		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	-3.055952 0.609787 -0.232520 85.392624 
qto_xyz:2	0.590852 2.101537 -2.218193 -39.421875 
qto_xyz:3	0.278702 2.230993 2.153034 -122.796539 
qto_xyz:4	0.000000 0.000000 0.000000 1.000000 
qform_xorient	Right-to-Left
qform_yorient	Inferior-to-Superior
qform_zorient	Anterior-to-Posterior
sform_name	Scanner Anat
sform_code	1
sto_xyz:1	-3.055953 0.609776 -0.232546 85.392624 
sto_xyz:2	0.590863 2.101537 -2.218190 -39.421875 
sto_xyz:3	0.278676 2.230996 2.153034 -122.796539 
sto_xyz:4	0.000000 0.000000 0.000000 1.000000 
sform_xorient	Right-to-Left
sform_yorient	Inferior-to-Superior
sform_zorient	Anterior-to-Posterior
file_type	NIFTI-1+
file_code	1
descrip		TE=27;Time=135429.807;phase=1;mb=5
aux_file	Unaliased_MB5_PE3_SENSE

After reorienting:

8192 sub-219392_task-clockRev_run-01_bold.nii.gz

filename	sub-219392_task-clockRev_run-01_bold.nii.gz

sizeof_hdr	348
data_type	INT16
dim0		4
dim1		64
dim2		64
dim3		45
dim4		1291
dim5		1
dim6		1
dim7		1
vox_units	mm
time_units	s
datatype	4
nbyper		2
bitpix		16
pixdim0		1.000000
pixdim1		3.125000
pixdim2		3.125000
pixdim3		3.100000
pixdim4		0.600000
pixdim5		0.000000
pixdim6		0.000000
pixdim7		0.000000
vox_offset	23600
cal_max		0.000000
cal_min		0.000000
scl_slope	1.000000
scl_inter	0.000000
phase_dim	0
freq_dim	0
slice_dim	3
slice_name	Unknown
slice_code	0
slice_start	0
slice_end	44
slice_duration	0.000000
toffset		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	3.125000 -0.000000 0.000000 -0.000000 
qto_xyz:2	0.000000 3.125000 -0.000000 -0.000000 
qto_xyz:3	0.000000 0.000000 3.100000 -0.000000 
qto_xyz:4	0.000000 0.000000 0.000000 1.000000 
qform_xorient	Left-to-Right
qform_yorient	Posterior-to-Anterior
qform_zorient	Inferior-to-Superior
sform_name	Scanner Anat
sform_code	1
sto_xyz:1	3.125000 -0.000000 -0.000000 -0.000000 
sto_xyz:2	-0.000000 3.125000 -0.000000 -0.000000 
sto_xyz:3	0.000000 0.000000 3.100000 -0.000000 
sto_xyz:4	0.000000 0.000000 0.000000 1.000000 
sform_xorient	Left-to-Right
sform_yorient	Posterior-to-Anterior
sform_zorient	Inferior-to-Superior
file_type	NIFTI-1+
file_code	1
descrip		
aux_file

[dnplserv@viz-n0 data_BIDS]$ 3drefit -orient LPI sub-219392_task-clockRev_run-01_bold.nii.gz 
++ 3drefit: AFNI version=AFNI_18.0.22 (Feb 26 2018) [64-bit]
++ Authored by: RW Cox
*+ WARNING: NO spatial transform (neither qform nor sform), in NIfTI file 'sub-219392_task-clockRev_run-01_bold.nii.gz'
++ Processing AFNI dataset sub-219392_task-clockRev_run-01_bold.nii.gz
 + changing orientation codes
 + loading and re-writing dataset sub-219392_task-clockRev_run-01_bold.nii.gz (./sub-219392_task-clockRev_run-01_bold.nii.gz in NIFTI storage)
++ 3drefit processed 1 datasets

[AndrewPapale]

This problem appears to be resolved by unzipping the file first with gunzip, then doing the conversions.

[effigies]

Hmm. Good catch with the gzip. I’d guess that there is some history here; AFNI has the BRIK/HEAD format, where the header is a separate file and can be modified without touching the data block. And if you’re not adding extensions, the same is true for NIfTI just by overwriting the first 348 bytes, so my guess is this code just writes the header. With gzipped files, you can’t only write the first 348 bytes without modifying the rest of the file, so we’re probably seeing an interaction of application-level code that assumes you can do random writes and I/O level code that will truncate and start a new gzip stream.

[ptaylor]

Hi-

@effigies mentioned brought this issue up on the AFNI github page. I’m a little curious about this dataset, because I have used 3drefit a lot on gzipped NIFTIs (as well as on other files) and not had an issue. Is this problematic volume either public, or sharable (for example if I sent an upload link)?

I also see that that version of AFNI appears to be over 4 years old, so it is possible that an earlier issue about this has been resolved. However, that would still really surprise me, and I would like to investigate this more.

thanks,
pt

[AndrewPapale]

I would be happy to share the file with you.

[rickr]

Just to follow up on this for any external readers, the problem seems to have been with the library libz that was installed and being applied by the NIFTI library. It had nothing to do with the dataset or with AFNI or the NIFTI library, except that libz needs to be an appropriate version for the package.
It is not clear whether an appropriate version will be installed by the system administrators, or perhaps we will try to provide some static linking to libz.a, instead.

• rick

[AndrewPapale]

This issue was fixed when the HPC admin replaced a buggy version of libz 1.2.9 with a more stable version 1.2.11