brain-life/encode

feConnectomeInit / feConnectomeSetDwi failing

Closed this issue · 2 comments

I am trying to troubleshoot an issue that cropped up recently with brain-life/app-life when feConnectomeInit tries to load the dwi data.

Error using sub2ind (line 73)
Out of range subscript.

Error in dwiGet (line 172)


Error in feConnectomeSetDwi (line 47)


Error in feConnectomeInit (line 56)


Error in life (line 10)

I am feeding dtiInit output (dwi_aligned_trilin.nii.gz) with the following dimension.

hayashis@haswell:~/test/encode 1 mrinfo dwi_aligned_trilin.nii.gz
************************************************
Image:               "dwi_aligned_trilin.nii.gz"
************************************************
  Format:            NIfTI-1.1
  Dimensions:        129 x 169 x 121 x 108
  Voxel size:        1.25 x 1.25 x 1.25 x 1
  Dimension labels:  0. left->right (mm)
                     1. posterior->anterior (mm)
                     2. inferior->superior (mm)
                     3. undefined (?)
  Data type:         signed 16 bit integer (little endian)
  Data layout:       [ +0 +1 +2 +3 ]
  Data scaling:      offset = 0, multiplier = 1
  Comments:          Raw Eddy Corrected
  Transform:                    1           0           0         -80
                                0           1           0        -120
                                0           0           1         -60
                                0           0           0           1

Which matches the dwi.nifit.dim that's loaded

K>> dwi.nifti.dim

ans =

   129   169   121   108

The error occurs on https://github.com/vistalab/vistasoft/blob/master/mrDiffusion/dwi/dwiGet.m#L172 where sub2ind is passed roi with overflowing index.

K>> max(feGet(fe,'roi coords'))

ans =

   117   140   122

notice 122 > 121.

I'd like to know why 'fe.roi.coords' could contain index that's greater than the z-size of the image (121)?

K>> find(fe.roi.coords(:,3)==122)

ans =

      201303
      201372
      201443
      206945
      207006
      207066
      212671
      212734
      212796
      218457
      218521
      224269
      224333
      224397
      224461
      224523
      230151
      230217
      230282
      230802
      236628
      236694
      236761
      242665

Please help me troubleshoot this.

@soichih is this still an issue or solved? Can close?

I think this is still an issue - if we feed track data that's outside the voxel area.. But I think such situation occurs if the image is improperly aligned. I think it will be nice to have the check built in for encode to warn the users of such issue.