dwifslpreproc does not recognize bvec information

1

Hello, everyone

We are having some troubles in the pre-processing step of the analysis. The dwifslpreproc command is not working as expected. There is one internal step where the gradient (bvec) information is lost:

dwifslpreproc dwi_denoise.mif dwi_denoise_eddy.mif -rpe_pair -se_epi b0_pairs.mif -pe_dir PA -align_seepi -topup_options ' ' -eddy_options '  --repol --data_is_shelled --slm=linear --niter=5' -eddy_mask b0_dwi_brain_mask.mif -eddyqc_all /flywheel/v0/output/eddyqc -scratch /flywheel/v0/output/tmp -quiet -force
[...]
dwifslpreproc: [ERROR] mrconvert dwi_pad2.mif -import_pe_table dwi_manual_pe_scheme.txt eddy_in.nii -strides -1,+2,+3,+4 -export_grad_fsl bvecs bvals -export_pe_eddy eddy_config.txt eddy_indices.txt (dwifslpreproc:915)
[...]
dwifslpreproc: mrconvert: [ERROR] no gradient information found within image "eddy_in.nii"

Our input data (listed as follows) acquired by using the 3T Siemens PrismaFit scanner.
T1.nii.gz
brainmask.nii.gz
P-A (dwi.nii.gz bval bvec)
A-P (dwi.nii.gz bval bvec)

This P-A data is composed of 60 gradient directions and 9 zero directions.
This A-P data is composed of 6 zero directions.
in zero direction, b value indicates completely 0, and b vector indicates completely (0, 0, 0).

NOTES:

  • the data acquired by using the same sequences in Siemens Verio have been preprocessed without errors.
  • a similar sequence with different gradient tables used in the same session in both the Verio and Prisma worked well (P-A data is composed of 100 gradient directions and 5 zero directions, A-P data is composed of 6 zero directions, in zero direction, b value indicates completely 0, and b vector indicates completely (0, 0, 0))
  • The error is systematic in all 5 subjects (2 sessions for each)
  • We used heudiconv 1.1.0 (for PrismaFIT data) and 1.0.1 (for Verio data) for conversion
  • PrismaFit was using software version XA and was saving flat dicoms with advanced dicom format. We had to wait until heudiconv was updated because of a problem with nibabel, but as far as we know, dcm2niix version was not changed.

Workaround:

  • If we manually change all (0, 0, 0) to (-0.5, -0.5, 0.707107), then pre-processing works well.
  • We checked the file formats and dicom headers and there doesn’t seem to be any other differences.

Do you have any idea what can be different so that only this specific sequence in this scanner only makes dwifslpreproc fail? What could be checked next?

1 Like