Dwidenoise changes strides i8


#1

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


#2

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…?


#3

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


#4

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!


#5

Thanks Donald for clarification.
Cheers,
Hamed