Mrconvert and dwigradcheck doubts

1

Hi,

I have a couple of doubts about the conversions using mrconvert and the voxelsize

I have some data and after performing eddy current correction (using the eddy_correct script) I found there are some differences in the voxel size of the 4th dimension, this has no sense from my point of view, the images look fine and everything works perfect on the following stages. Do you know why this could be due?

Before: Voxel size: 1 x 1 x 1 x 8.1. After: Voxel size: 1 x 1 x 1 x 1. The rest of the info provided by mrinfo is the same.

And another thing, when I use mrconvert with -fslgrad to convert mi data (mainly preprocessed with fsl) from .nii.gz to .mif should I use any -stride option? or automatically it detects the correct orientation for me? the option -stride 0,0,0,1 is only for storage purposes? or it has some anatomical implications?

Thanks in advance!

Best regards,

Manuel

2

If you look at how the eddy_correct script works under the hood, you’ll find that the first thing it does it to split the input into multiple 3D volumes using fslsplit, and re-combines the realigned volumes afterwards using fslmerge. I expect this process would discard any information about the spacing along the 4th axis (which I assume was originally TR?). But as you say, I also can’t see that having any impact on downstream analyses.

Perhaps a more pertinent question is why would you still be using eddy_correct these days, when eddy has been proved to outperform it by some margin (and my experience of eddy_correct is that it very often messed up otherwise perfectly usable data)…?

No, the -stride option only affects the order in which voxel values are stored as a linear array on file - the MRtrix3 image handling backend ensures anatomical consistency is preserved. The -stride option is only typically required in two use cases:

  1. to ensure compatibility with other 3rd-party tools (we often need to ensure NIfTI are stored LAS for some FSL tools, for instance).

  2. to improve performance for downstream processing (so for instance, if FODs are stored volume-contiguous (the default), tckgen can access the data as-is (via memory-mapping) and maximise performance by ensuring optimal CPU cache usage. But it’s not a requirement - the MRtrix3 image access backend takes care of these issues transparently (for instance, in the tckgen case, the data will be pre-loaded to RAM in the most efficient order if the strides weren’t already optimal).

3

Hi,

Thanks Donald for your quick answer!

Perhaps a more pertinent question is why would you still be using eddy_correct these days, when eddy has been proved to outperform it by some margin (and my experience of eddy_correct is that it very often messed up otherwise perfectly usable data)…?

I know, I have to modify this in the future, but I was processing an old dataset were eddy_correct was been already used.

All this issue starts because I wanted to check the dwigradcheck, and I found some results that I didn’t know how to interpret. For example:

Mean length Axis flipped Axis permutations Axis basis
27.23 none (0, 1, 2) scanner
25.92 none (0, 1, 2) image

What means the axis bases? what should be the correct one? I asume that for MRtrix is the scanner, but I have some subjects that show higher values for the image axis… This is quite confusing for me.

Regards,

Manuel

4

I haven’t used that script myself - I’ll leave that one for @bjeurissen… :stuck_out_tongue_winking_eye:

5

dwigradcheck is performing whole brain fiber tracking and looking at the average streamline length under various interpretations of the gradient table as stored in the header. If the gradient directions were interpreted and stored within the header correctly, “none (0, 1, 2) scanner” should result in the longest average track length as this indicates no axis flipping, no axis permutations and assuming gradient direction coordinate frame was in scanner space (which is what is assumed throughout MRtrix). If anything other comes up as first, this might be an indication that something when wrong when putting the gradient directions in the header. However, there are reasons why “none (0, 1, 2) image” could come up as first occasionally, even with perfectly converted gradient directions:

  • the scanner and image basis could simply be oriented exactly the same. In this case, any difference in mean length just comes down to the random seed point placement used by tckgen, meaning that each time you run it, different seed points will be used and another interpretation might come up first.
  • the scanner and image basis could be not identically oriented but very close. Given the limited accuracy of the approach and the random seeding strategy of tckgen, this could still mean that “none (0, 1, 2) image” occasionally comes up as first. On these cases you could consider rerunning the command with a higher -number (e.g. 100000). Or rerunning it with the default number, but checking if the order is consistent across runs. That said, even with high numbers, it could be that the differences in coordinate frame are so minor that the method can not pinpoint the optimal solution. However, in that case there is probably no harm in choosing the permuted version.

Could you show the output of one of the subjects that “fails” along with an mrinfo dump of the input file?

1 Like
6

Hi @bjeurissen,

Thanks for your help. I have a subject that the results of running the script with the default parameters are:

 Mean length     Axis flipped    Axis permutations    Axis basis
26.90         none                (0, 1, 2)           image
26.87         none                (0, 1, 2)           scanner
17.07         none                (2, 1, 0)           scanner
16.51            1                (2, 1, 0)           scanner
16.45            0                (0, 1, 2)           scanner
16.32            1                (2, 1, 0)           image
16.28         none                (2, 1, 0)           image
16.26            0                (0, 1, 2)           image
15.84            2                (0, 1, 2)           scanner
15.78            2                (0, 1, 2)           image
15.43            1                (0, 1, 2)           scanner
15.24            0                (0, 2, 1)           scanner
15.21            1                (0, 1, 2)           image
15.20            0                (0, 2, 1)           image
14.85         none                (0, 2, 1)           image
14.76         none                (0, 2, 1)           scanner
14.55            2                (1, 0, 2)           scanner
14.54         none                (1, 0, 2)           scanner
14.50         none                (1, 0, 2)           image
14.47            2                (1, 0, 2)           image
13.84            0                (2, 1, 0)           image
13.78            2                (2, 1, 0)           scanner
13.60            2                (2, 1, 0)           image
13.57            1                (0, 2, 1)           image
13.54            0                (2, 1, 0)           scanner
13.40            1                (0, 2, 1)           scanner
13.27         none                (2, 0, 1)           image
13.14            2                (0, 2, 1)           scanner
13.06            1                (2, 0, 1)           image
13.05            2                (1, 2, 0)           image
13.05            2                (0, 2, 1)           image
12.99            1                (2, 0, 1)           scanner
12.97         none                (1, 2, 0)           scanner
12.91         none                (2, 0, 1)           scanner
12.89            1                (1, 0, 2)           image
12.88            1                (1, 0, 2)           scanner
12.87            1                (1, 2, 0)           image
12.86            2                (2, 0, 1)           scanner
12.85            0                (1, 2, 0)           scanner
12.81            2                (2, 0, 1)           image
12.80            0                (1, 2, 0)           image
12.75            0                (2, 0, 1)           image
12.74            0                (1, 0, 2)           scanner
12.71            1                (1, 2, 0)           scanner
12.70            0                (2, 0, 1)           scanner
12.51            2                (1, 2, 0)           scanner
12.43            0                (1, 0, 2)           image
12.27         none                (1, 2, 0)           image

I run it with -number 100000 and I get the following results:

Mean length     Axis flipped    Axis permutations    Axis basis
26.98         none                (0, 1, 2)           image
26.97         none                (0, 1, 2)           scanner
16.85            1                (2, 1, 0)           image
16.81         none                (2, 1, 0)           scanner
16.66         none                (2, 1, 0)           image
16.65            1                (2, 1, 0)           scanner
16.41            0                (0, 1, 2)           image
16.29            0                (0, 1, 2)           scanner
15.69            2                (0, 1, 2)           image
15.65            2                (0, 1, 2)           scanner
15.38            0                (0, 2, 1)           scanner
15.32            1                (0, 1, 2)           image
15.32            1                (0, 1, 2)           scanner
15.30            0                (0, 2, 1)           image
14.99         none                (0, 2, 1)           scanner
14.88         none                (0, 2, 1)           image
14.67         none                (1, 0, 2)           image
14.66            2                (1, 0, 2)           scanner
14.61         none                (1, 0, 2)           scanner
14.61            2                (1, 0, 2)           image
13.85            0                (2, 1, 0)           scanner
13.82            2                (2, 1, 0)           scanner
13.82            0                (2, 1, 0)           image
13.79            2                (2, 1, 0)           image
13.58            1                (0, 2, 1)           image
13.47            1                (0, 2, 1)           scanner
13.21            2                (0, 2, 1)           scanner
13.13            2                (0, 2, 1)           image
13.11            1                (2, 0, 1)           scanner
13.05         none                (2, 0, 1)           image
12.97            1                (1, 0, 2)           image
12.96            2                (1, 2, 0)           image
12.96         none                (1, 2, 0)           scanner
12.93            0                (1, 0, 2)           scanner
12.86            0                (2, 0, 1)           image
12.86            2                (2, 0, 1)           image
12.82         none                (2, 0, 1)           scanner
12.81            2                (2, 0, 1)           scanner
12.80            0                (2, 0, 1)           scanner
12.79            1                (1, 2, 0)           scanner
12.79            1                (2, 0, 1)           image
12.79            0                (1, 2, 0)           scanner
12.75            0                (1, 2, 0)           image
12.73            0                (1, 0, 2)           image
12.72            1                (1, 2, 0)           image
12.69            1                (1, 0, 2)           scanner
12.64            2                (1, 2, 0)           scanner
12.58         none                (1, 2, 0)           image

The output of mrinfo is:

************************************************
Image:               "MH_6127-EPIcorr.mif"
************************************************
  Dimensions:        256 x 256 x 112 x 75
  Voxel size:        1 x 1 x 1 x 0
  Data strides:      [ -1 2 3 4 ]
  Format:            MRtrix
  Data type:         64 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1          -0           0        -122
                                0           1          -0      -153.4
                               -0           0           1      -66.48
  command_history:   mrconvert "MH_6127-EPIcorr.nii.gz" "MH_6127-EPIcorr.mif" "-fslgrad" "MH_6127_bvecs" "bvals" "-force"  (version=3.0_RC2-2-gca446aad)
  comments:          FSL5.0
  dw_scheme:         0,0,0,0
  [75 entries]       0,0,0,0
                     ...
                     -0.7599512603,-0.3617626594,0.5400024165,750
                     -0.8437268347,0.3027933791,0.4432253017,750
  mrtrix_version:    3.0_RC2-2-gca446aad

From my understanding, I think that the axis basis from the image and the scanner should be different in the inversion of the first axis. After seeing this results I would say that in this case, both origins are the same. Am I correct? Thanks in advance.

Regards,

Manuel

7

Hi,

I did the experiment again and now mean length for the scanner axis is higher, I think this supports the idea that both origins are the same.

Regards,

Manuel

8

As the 3x3 part of the transform matrix is the identity matrix, the orientations of the image and scanner coordinate systems are identical (the strides are irrelevant to this respect), so basically the first two results are actually from the same case. The values are just slightly different because of the random seeding.

9

All this issue starts because I wanted to check the dwigradcheck, and I found some results that I didn’t know how to interpret.

OK, probably need to alter the title of this thread; the issue has nothing to do with mrconvert :laughing:

Mean length Axis flipped Axis permutations Axis basis
27.23 none (0, 1, 2) scanner
25.92 none (0, 1, 2) image

Currently, dwigradcheck simply loops through all combinations of axis flips, axis permutations, and axis basis (i.e. whether the flips & permutations occur in scanner space or image space). Because it’s looping through all possibilities, the case where the gradient table is unaltered occurs twice: Once with no axis flips or permutations in scanner space, and once with no axis flips or permutations in image space. The numerical difference between the two is simply the variance intrinsic to the stochastic nature of the tracking experiment.

Note that this is the case regardless of whether or not the header transformation is an identity matrix. The script currently does not currently consider the possibility that the gradient table may be interpreted as scanner space even though the numerical values are in fact appropriate for image space, or vice-versa. The “axis basis” only specifies which space is used for the axis flips & permutations.

10

Hello @rsmith nd @bjeurissen,

Thanks for the help and clarifications.

As Robert suggested I updated the name of the post, so if someone has similar doubts with dwigradcheck, now it should be easy to find.

Regards,

Manuel

1 Like