Inconsistent strides between input dwi and output of dwi2response voxels.mif image

snp2003 · April 25, 2020, 12:16am

Dear experts,

When I run dwi2response and generate output voxels image, I see that stride of this voxels.mif image is different than input dwi image. However, wmfod image from ss3t_csd_beta1 and dec.mif images from tensor2metric which I run after dwi2response shows same strides as input dwi image. Should I be concerned about this?

Prior to performing dwi2response, I converted FSL’s epi_reg corrected nifti image to MRtrix’s mif, with "mrconvert data2_to_fs_T1.nii.gz data2_to_fs_T1.mif -fslgrad bvecs_denoised_rot.txt bvals_denoised.txt -datatype float32 -stride 0,0,0,1" command, to correspond to a volume-contiguous layout for better memory storage. “mrinfo” of input dwi image (data4.mif), output voxels image (response_voxels.mif), wmfod.mif, and dec.mif images are shown below.

************************************************
Image name:          "data4.mif"
************************************************
  Dimensions:        256 x 256 x 256 x 55
  Voxel size:        1 x 1 x 1 x 1
  Data strides:      [ -2 4 -3 1 ]
  Format:            MRtrix
  Data type:         32 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0          -0      -129.6
                               -0           1          -0      -98.28
                               -0           0           1      -140.2
  command_history:   mrconvert EPI_REG/data2_to_fs_T1.nii.gz data2_to_fs_T1.mif -fslgrad EPI_REG/bvecs_denoised_rot.txt EPI_REG/bvals_denoised.txt -datatype float32 -stride '0,0,0,1'  (version=3.0.0)
                     /usr/local/mrtrix3/bin/dwifslpreproc data2_to_fs_T1.mif data3.mif -rpe_none -pe_dir j- -export_grad_fsl bvecs.txt bvals.txt -info -nthreads 35  (version=3.0.0)
                     /usr/local/mrtrix3/bin/dwibiascorrect ants -fslgrad bvecs.txt bvals.txt data3.mif data4.mif -nthreads 35  (version=3.0.0)
  comments:          6.0.1
  dw_scheme:         0.0,0.0,0.0,0.0
  [55 entries]       0.0,0.0,0.0,0.0
                     ...
                     -0.08066200967,0.9966021195,0.016669002,1000.0
                     0.4229682249,0.7652964069,-0.485200258,1000.0
  mrtrix_version:    3.0.0

************************************************
Image name:          "response_voxels.mif"
************************************************
  Dimensions:        256 x 256 x 256 x 3
  Voxel size:        1 x 1 x 1 x ?
  Data strides:      [ -1 4 -3 2 ]
  Format:            MRtrix
  Data type:         bitwise
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0          -0      -129.6
                               -0           1          -0      -98.28
                               -0           0           1      -140.2
  command_history:   mrconvert EPI_REG/data2_to_fs_T1.nii.gz data2_to_fs_T1.mif -fslgrad EPI_REG/bvecs_denoised_rot.txt EPI_REG/bvals_denoised.txt -datatype float32 -stride '0,0,0,1'  (version=3.0.0)
                     /usr/local/mrtrix3/bin/dwifslpreproc data2_to_fs_T1.mif data3.mif -rpe_none -pe_dir j- -export_grad_fsl bvecs.txt bvals.txt -info -nthreads 35  (version=3.0.0)
                     /usr/local/mrtrix3/bin/dwibiascorrect ants -fslgrad bvecs.txt bvals.txt data3.mif data4.mif -nthreads 35  (version=3.0.0)
                     /usr/local/mrtrix3/bin/dwi2response dhollander data4.mif response-wm.txt response-gm.txt response-csf.txt -voxels response_voxels.mif -mask dwi_mask.mif -nthreads 35  (version=3.0.0)
  comments:          6.0.1
  dw_scheme:         0.0,0.0,0.0,0.0
  [55 entries]       0.0,0.0,0.0,0.0
                     ...
                     -0.08066200967,0.9966021195,0.016669002,1000.0
                     0.4229682249,0.7652964069,-0.485200258,1000.0
  mrtrix_version:    3.0.0

************************************************
Image name:          "wmfod.mif"
************************************************
  Dimensions:        256 x 256 x 256 x 45
  Voxel size:        1 x 1 x 1 x 1
  Data strides:      [ -2 4 -3 1 ]
  Format:            MRtrix
  Data type:         32 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0          -0      -129.6
                               -0           1          -0      -98.28
                               -0           0           1      -140.2
  SS3T-CSD_bzero_pct: 10.0
  SS3T-CSD_niter:    3
  SS3T-CSD_sdm_csf:  3.13137128023
  SS3T-CSD_sdm_gm:   0.867203544417
  SS3T-CSD_sdm_sfwm: 0.663489650931
  command_history:   mrconvert EPI_REG/data2_to_fs_T1.nii.gz data2_to_fs_T1.mif -fslgrad EPI_REG/bvecs_denoised_rot.txt EPI_REG/bvals_denoised.txt -datatype float32 -stride '0,0,0,1'  (version=3.0.0)
                     /usr/local/mrtrix3/bin/dwifslpreproc data2_to_fs_T1.mif data3.mif -rpe_none -pe_dir j- -export_grad_fsl bvecs.txt bvals.txt -info -nthreads 35  (version=3.0.0)
                     /usr/local/mrtrix3/bin/dwibiascorrect ants -fslgrad bvecs.txt bvals.txt data3.mif data4.mif -nthreads 35  (version=3.0.0)
                     /usr/local/MRtrix3Tissue/bin/ss3t_csd_beta1 data4.mif response-wm.txt wmfod.mif response-gm.txt gm.mif response-csf.txt csf.mif -mask dwi_mask.mif -nthreads 35  (version=3Tissue_v5.2.8-2-gc82903bb)"
  comments:          6.0.1
  mrtrix_version:    3Tissue_v5.2.8-2-gc82903bb
  prior_dw_scheme:   0.0,0.0,0.0,0.0
  [55 entries]       0.0,0.0,0.0,0.0
                     ...
                     -0.08066200967,0.9966021195,0.016669002,1000.0
                     0.4229682249,0.7652964069,-0.485200258,1000.0

************************************************
Image name:          "dec.mif"
************************************************
  Dimensions:        256 x 256 x 256 x 3
  Voxel size:        1 x 1 x 1 x 1
  Data strides:      [ -2 4 -3 1 ]
  Format:            MRtrix
  Data type:         32 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0          -0      -129.6
                               -0           1          -0      -98.28
                               -0           0           1      -140.2
  command_history:   mrconvert EPI_REG/data2_to_fs_T1.nii.gz data2_to_fs_T1.mif -fslgrad EPI_REG/bvecs_denoised_rot.txt EPI_REG/bvals_denoised.txt -datatype float32 -stride '0,0,0,1'  (version=3.0.0)
                     /usr/local/mrtrix3/bin/dwifslpreproc data2_to_fs_T1.mif data3.mif -rpe_none -pe_dir j- -export_grad_fsl bvecs.txt bvals.txt -info -nthreads 35  (version=3.0.0)
                     /usr/local/mrtrix3/bin/dwibiascorrect ants -fslgrad bvecs.txt bvals.txt data3.mif data4.mif -nthreads 35  (version=3.0.0)
                     dwi2tensor data4.mif tensor.mif -nthreads 35  (version=3.0.0)
                     tensor2metric tensor.mif -vec dec.mif -mask dwi_mask.mif -nthreads 35  (version=3.0.0)
  comments:          6.0.1
  mrtrix_version:    3.0.0
  prior_dw_scheme:   0,0,0,0
  [55 entries]       0,0,0,0
                     ...
                     -0.08066200967,0.9966021195,0.016669002,1000
                     0.4229682249,0.7652964069,-0.485200258,1000

Thank you,
Sneha

ThijsDhollander · April 25, 2020, 5:23am

Hi Sneha,

I hope you’re doing well!

Generally, there’s no need to worry about strides of different images; they’re independent of what the image represents or e.g. where it is in 3D space and how it’s oriented. The best example of this is actually your own example where you manipulate the strides: this doesn’t affect the image, but only how things are stored on disk; which can itself be useful for certain kinds of quick access of the data, depending on the application. I’ll quickly walk through your post to reassure at each point there’s nothing to worry about your observations.

Yep, that’s perfectly fine. The voxels image is a very light binary image; it’s strides don’t really matter (performance wise) for anything you’d realistically do with that image. The only thing you’ll likely do with that voxels image, is open it up in the viewer to inspect e.g. for quality assessment purposes (checking that the selected voxels are sensible, if in doubt).

Well, for the WM FOD image, that’s actually also not guaranteed. You might’ve just coincidentally have had the original DWI data’s strides in a certain way so they’ve matched with that output. ss3t_csd_beta1 internally also at some point converts the strides of the largest file it works with to -stride 0,0,0,1. tensor2metric is entirely separate from anything to do with the response functions. Also, no steps whatsoever use the voxels.mif image you got from dwi2response, but even if they did, the strides of it would similarly not matter for anything that’s done subsequently.

So well, no. You’re all good!

Yep, while not strictly necessary, I think that’s very good practice. You score a few “wins” here all at once: data is nicely in .mif format which supports most header features down the track, the gradient directions and b-values get imported and stored in that header so you never have to worry about them again afterwards, and indeed by taking the opportunity to reorder the strides, you might just get a bit of extra performance down the track depending on the kinds of processing you’re going to apply to the data. Several people run into issues in other steps, that could have sometimes been avoided by performing this kind of neat conversion up front.

That looks all good to me! From the wmfod.mif header, I can even learn that your response functions seem to be in good condition (insofar that can be learned from the header of course). It’s a good indication that dwi2response dhollander will have worked well earlier in the pipeline; so those voxels.mif should’ve been good as well, I reckon.

By the way, did you know you don’t have to resort to a DTI model and FA map for a DEC image? You can get one that goes much better with the higher order information in the WM FOD itself via:

fod2dec wmfod.mif decfod.mif -mask dwi_mask.mif

This is a so-called FOD-based DEC map. See the help of fod2dec for more information and sources if you want to read up on this!

Cheers & take care,
Thijs

snp2003 · April 27, 2020, 3:50pm

Thank you Thijs and I hope all is well!

Walking through each of these points reassured me that I am not going off-track with my processing, and thank you for pointing me to fod2dec. I did have a brief look at it earlier but shied away from using it. With your suggestion I can definitely upgrade this processing step. Considering that I have used ss3t csd, would it be ideal to run mtnormalise for robust bias field correction after ss3t_csd_beta1 and prior to fod2dec step?

Thank you,
Sneha

ThijsDhollander · April 27, 2020, 11:59pm

No worries, all good!

Excellent!

Yep, that’s a great idea as well! For most purposes, you can safely run mtnormalise always right after SS3T-CSD. Not only do you get robust bias field correction (which is useful for any visualisation, including the output from fod2dec), but the global intensity normalisation will be useful if you perform e.g. tractography or any other analyses relying on the amplitude of the FODs. mtnormalise can act a bit as the great equaliser, making sure the amplitudes of your data can be relied upon to show a certain typical range of magnitudes. So it’s essentially a no-brainer.

All the best,
Thijs

snp2003 · April 28, 2020, 2:33pm

Perfect, thank you and stay safe!