Dwidenoise changes strides i8

Dear experts

I have a small question.
I noticed changes in the image strides, data type and multipliers after applying dwidenoise and I was wondering whether this is an expected behavior and whether it affects downstream processing steps.

before dwidenoise

mrinfo dwi.mif -all
************************************************
Image:               "dwi.mif"
************************************************
  Dimensions:        96 x 96 x 50 x 102
  Voxel size:        2.5 x 2.5 x 2.5 x ?
  Data strides:      [ -1 -2 3 4 ]
  Format:            MRtrix
  Data type:         unsigned 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 6.36313
  Transform:               0.9996    -0.01444       0.023      -112.6
                           0.0145      0.9999   -0.002643      -101.9
                         -0.02296    0.002976      0.9997      -6.997
  EchoTime:          0.074
  PhaseEncodingDirection: j
  TotalReadoutTime:  0.0173
  command_history:   mrconvert "102d/DICOM/" "preproc1/dwi.mif" "-import_pe_table" "../dwi_manual_pe_scheme1.txt"  (version=3.0_RC2-123-gfce21191)
  comments:          SMNS .... [MR] DKI_101d_2800_50sl_1p
                     study: ......
                     DOB: ...
                     DOS: ....
  dw_scheme:         -0.70710676908493042,-0.70710676908493042,-3.048761521018406e-10,0.5
  [102 entries]      5.2940413164392908e-10,-0.7071068286895752,0.70710676908493042,0.5
                     0.69242489337921143,0.65877288579940796,-0.29422095417976379,700
                     -0.067345991730690002,-0.97783488035202026,-0.19825096428394318,2800
                     0.77779304981231689,-0.50009399652481079,-0.38071504235267639,1200
                    ...............

after dwidenoise

mrinfo dwi_deno.mif -all
************************************************
Image:               "dwi_deno.mif"
************************************************
  Dimensions:        96 x 96 x 50 x 102
  Voxel size:        2.5 x 2.5 x 2.5 x ?
  Data strides:      [ -2 -3 4 1 ]
  Format:            MRtrix
  Data type:         32 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:               0.9996    -0.01444       0.023      -112.6
                           0.0145      0.9999   -0.002643      -101.9
                         -0.02296    0.002976      0.9997      -6.997
  EchoTime:          0.074
  PhaseEncodingDirection: j
  TotalReadoutTime:  0.0173
  command_history:   mrconvert "102d/DICOM/" "preproc1/dwi.mif" "-import_pe_table" "../dwi_manual_pe_scheme1.txt" (version=3.0_RC2-123-gfce21191)
                     dwidenoise "dwi.mif" "dwi_deno.mif" "-noise" "noise.mif" "-extent" "7,7,7" (version=3.0_RC2-123-gfce21191)
 comments:          SMNS .... [MR] DKI_101d_2800_50sl_1p
                     study: ......
                     DOB: ...
                     DOS: ....
  dw_scheme:         -0.70710676908493042,-0.70710676908493042,-3.048761521018406e-10,0.5
  [102 entries]      5.2940413164392908e-10,-0.7071068286895752,0.70710676908493042,0.5
                     0.69242489337921143,0.65877288579940796,-0.29422095417976379,700
                     -0.067345991730690002,-0.97783488035202026,-0.19825096428394318,2800
                     0.77779304981231689,-0.50009399652481079,-0.38071504235267639,1200
                     ...............

Cheers,
Hamed

No, this is nothing to worry about:

  • The datatype changes to floating point to avoid rounding errors.

  • The multipliers in the input come directly from the DICOM headers, and are taken into account when reading the input data. But there’s no rationale for them with a floating point datatype, so we set them to 0,1 (no scaling) for the output.

  • The strides are set such that the data are stored in volume-contiguous order, which is likely to be better suited to downstream applications like voxel-wise processing (e.g. through dwi2fod) or tractography (through tckgen).

Hope this clarifies things a bit…?

Thanks Donald.

Since there is a mismatch between the strides of dwis after denoise and the ones of rev image, I just wanted to make sure that this won’t cause a wrong outcome using dwiprepro?

Cheers,
Hamed

No, we’ve made quite sure that the data are then passed to topup and eddy in the right format. If you do encounter any issues, let us know!

Thanks Donald for clarification.
Cheers,
Hamed