DWIConvert NIFTI to NRRD issue

Hi all,

I am using DWIConvert to convert NIFTIs to NRRDs so that I can use DTIPrep’s artifact detection and denoising tools. I then plan to convert these NRRDs back to NIFTI so that I can use FSL’s eddy and then FSL’s TBSS analysis. However, after running DTIPrep preprocessing, converting back to NIFTI, and running FSL eddy, I’m seeing strange results. Eddy outputs a file called data.nii.gz.eddy_restricted_movement_rms in which there are estimates for movement (1) relative to the first volume (the b0) and (2) between each consecutive volumes. I use this movement estimation file to identify subjects with excess movement in the scanner to remove them from analysis.

Here is the puzzling output that I get, where the first column indicates type-(1) values and the second column indicates type-(2) values (bold emphasis mine):

0 0
0.0004349732621 0.0004349732621
0.1293237744 0.1290371457
0.0770145743 0.0787793649
0.1380966347 0.1334343518
0.120617891 0.0671182883
0.2690339005 0.164081166
0.3256238628 0.07334808195
0.1346585371 0.1988556541
0.1346585371 0
0.1346585371 0
0.1346585371 0
0.1346585371 0
0.1364517787 0.06969197052
0.2810317103 0.1871601272
0.2053992891 0.1139292096
0.1838997283 0.04258127975
0.1850058225 0.03042424084
0.1640395851 0.04978561965
0.1441797516 0.03871081352
0.1411901608 0.08651112032
0.05642180761 0.09891716264
0.1132709746 0.1019541404
0.198486599 0.2614182835
0.2152392961 0.02585408788
0.2636229757 0.05646168819
0.2057839289 0.111750168
0.2018872141 0.06196124255
0.3124672885 0.1476290345
0.3520931575 0.07196218901
0.2838850662 0.09389126276
0.3076169748 0.04724860972
0.3053632287 0.0193159719

According to this, there is absolutely zero movement between a consecutive 4 volumes, which seems unlikely, if not impossible. I get similar strange looking output for many other subjects processed using DTIPrep tools and then FSL eddy. Importantly, I get normal-looking movement estimation when I do not use DWIConvert or DTIPrep’s tools.

To identify the problem, I’ve tried only using DWIConvert from NIFTI to NRRD and then again from NRRD to NIFTI without using any of DTIPrep’s preprocessing tools. In theory, there should be no change in the NIFTI after converting to and from NRRD. However, after running FSL eddy again on this back-and-forth-converted dataset, I still get strange eddy movement estimation in that it indicates absolutely zero movement between certain volumes. So, it seems the issue is due to DWIConvert, a Slicer tool, and not due to DTIPrep’s preprocessing tools.

Does anyone have any insight into what may be causing the problem? Converting from NIFTI to NRRD back to NIFTI using DWIConvert seems to change the alignment of volumes. But I’m not quite sure.

I’ve gone through extensive troubleshooting thanks to help from Martin Styner over at the DTIPrep forums, but we haven’t been able to solve the issue. Here’s the attempted troubleshooting in more detail.

Here’s what I’m calling in the command line to go from NIFTI --> NRRD:
DWIConvert --inputVolume raw_dwi.nii.gz -o dwi.nrrd --conversionMode FSLToNrrd --inputBValues bvals_col --inputBVectors bvecs_col

And from NRRD --> NIFTI:
DWIConvert --inputVolume dwi.nrrd --conversionMode NrrdToFSL --outputVolume raw_dwi_QCed.nii --outputBVectors bvecs_col_QCed --outputBValues bvals_col_QCed

Thank you very much in advance!

Hi Ryan,
What version of DWIConvert are you using? I did some round-trip tests a few days ago using the latest version of DWIConvert, stand-alone (command-line, not through Slicer), and got reasonable results. @hjmjohnson and others have made a number of improvements to DWIConvert and ITK nifti support recently. So I would suggest trying the latest version, if you are not already using it.

Other things to look at are: compare raw image voxel values after the round-trip through DWIConvert, and check for difference in bvec files.

Hey Isaiah, thanks for your help!

I’m using DWIConvert 1.2.4. Perhaps that’s the issue, because the bvecs/bvals are the same before and after conversion. Also, the intensity values are identical before and after conversion as well. I’ll try out updating Slicer and let you know how that goes.

If they are identical when doing just the nii → nrrd → nii trip via DWIConvert, then the only other difference I can think of is the orientations. You can check those with fslorient -getsform (or -getqform).