Tckgen default image realignment to RAS coordinate - How do I stop this?

sabco · November 10, 2019, 12:21am

Hi,

I came across this issue when I was running the same command on the same image between my local machine and HPC cluster at the lab. Basically, I was running tckgen using seed_image and an inclusion mask, and I was getting different results at the end of it.

The difference was that the versions of MRtrix were different, and in the latest version on my HPC cluster, when an image is loaded, it says "Axes and transform of image <> altered to approximate RAS coordinate system"

Looking at the data, this is happening incorrectly. The masks are already oriented properly, so when it gets reoriented the tracts are out of control.

Is there a way I can turn this option off?

Thanks so much.

jdtournier · November 11, 2019, 11:15am

I’m not sure what’s going here – this reorientation has always been performed internally. Can you state exactly what versions of MRtrix3 are running on the two systems?

Also, can you confirm for certain that tckgen alone is the culprit? You’re not running steps prior to tckgen? I’m asking since I can see how dwi2fod could give you the wrong results if you’re providing your own bvecs/bvals, due to this bug.

On that note: if you’re running tensor-based tracking with your own bvecs/bvals, then this would also give rise to inconsistent behaviour due to the bug above, since in that case the interpretation of the bvecs is done within tckgen itself, rather than in dwi2fod.

It would also really help if you could provide screenshots of how the problem manifests, and show the output of mrinfo for all images involved on both systems.

sabco · November 11, 2019, 11:21pm

Dr. Tournier, thank you very much for replying and offering to help.

To clarify the issue I am having, I have run tckgen on the same masks and FOD, using the same command, on two different machines. Machine A is my local machine, using MRtrix 3, on the May 4 2018 release. Machine B is the HPC cluster, running a more updated version of MRtrix 3 released on March 3, 2019. I am trying to identify tracts between the ZI and PVT in HCP subjects. I ran one subject on Machine A, and then wanted to run on Machine B. Even after copy and pasting the FOD and masks from Machine A to Machine B, and running the same command, I got drastically different results.

This is the command I used:
tckgen -info FOD_WM.mif lh_zi_to_pvt_2.tck -seed_image sub-63_lh_zi_dwi.nii.gz -force -include sub-63_lh_pvt_dwi.nii.gz -include sub-63_lh_zi_dwi.nii.gz -seeds 1065000 -select 0

These are the outputs of mrinfo:

MacBook-Pro-172:sub-63 sabir$ mrinfo FOD_WM.mif
************************************************
Image:               "FOD_WM.mif"
************************************************
  Dimensions:        173 x 207 x 173 x 45
  Voxel size:        1.05 x 1.05 x 1.05 x 1
  Data strides:      [ -2 3 4 1 ]
  Format:            MRtrix
  Data type:         32 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0           0       -90.6
                               -0           1           0        -126
                               -0           0           1         -72
  command_history:   mrconvert "sub-63_dwi.nii.gz" "-fslgrad" "sub-63_dwi.bvec" "sub-63_dwi.bval" "sub-63_dwi.mif"  (version=e27b1200)
                     dwi2fod "msmt_csd" "sub-63_dwi.mif" "response_wm.txt" "FOD_WM.mif" "response_gm.txt" "FOD_GM.mif" "response_csf.txt" "FOD_CSF.mif" "-mask" "sub-63_dwi_bet_mask.nii.gz"  (version=e27b1200)
  comments:          FSL5.0
  mrtrix_version:    e27b1200
  prior_dw_scheme:   -0.02906800072,0.9090760224,-0.4156150103,0
  [143 entries]      -0.5324862053,0.05988902309,0.8443173255,979.9992444
                     ...
                     -0.6565713652,-0.4873472711,0.5756793202,984.9989042
                     -0.4038150334,0.4291610355,0.8079320667,2019.999666

MacBook-Pro-172:sub-63 sabir$ mrinfo sub-63_lh_zi_dwi.nii.gz
************************************************
Image:               "sub-63_lh_zi_dwi.nii.gz"
************************************************
  Dimensions:        173 x 207 x 173
  Voxel size:        1.05 x 1.05 x 1.05
  Data strides:      [ -1 2 3 ]
  Format:            NIfTI-1.1 (GZip compressed)
  Data type:         64 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0           0       -90.6
                               -0           1           0        -126
                               -0           0           1         -72
  comments:          5.0.10

MacBook-Pro-172:sub-63 sabir$ mrinfo sub-63_lh_pvt_dwi.nii.gz
************************************************
Image:               "sub-63_lh_pvt_dwi.nii.gz"
************************************************
  Dimensions:        173 x 207 x 173
  Voxel size:        1.05 x 1.05 x 1.05
  Data strides:      [ -1 2 3 ]
  Format:            NIfTI-1.1 (GZip compressed)
  Data type:         64 bit float (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0           0       -90.6
                               -0           1           0        -126
                               -0           0           1         -72
  comments:          5.0.10

The reason I suspected the issue to arise in tckgen is because the FOD (and everything else) was the same. I used the -info flag in tckgen to see what was happening in each step. In Machine A, there was no message that said there was reorientation of the axes, but in Machine B there was.

Machine A -info:

tckgen: [WARNING] existing output files will be overwritten
tckgen: [INFO] opening image "sub-63_lh_pvt_dwi.nii.gz"...
tckgen: [INFO] image "sub-63_lh_pvt_dwi.nii.gz" opened with dimensions 173x207x173, voxel spacing 1.0499999523162842x1.0499999523162842x1.0499999523162842, datatype Float64LE
tckgen: [100%] uncompressing image "sub-63_lh_pvt_dwi.nii.gz"
tckgen: [INFO] opening image "sub-63_lh_zi_dwi.nii.gz"...
tckgen: [INFO] image "sub-63_lh_zi_dwi.nii.gz" opened with dimensions 173x207x173, voxel spacing 1.0499999523162842x1.0499999523162842x1.0499999523162842, datatype Float64LE
tckgen: [100%] uncompressing image "sub-63_lh_zi_dwi.nii.gz"
tckgen: [INFO] opening image "sub-63_lh_pvt_dwi.nii.gz"...
tckgen: [INFO] image "sub-63_lh_pvt_dwi.nii.gz" opened with dimensions 173x207x173, voxel spacing 1.0499999523162842x1.0499999523162842x1.0499999523162842, datatype Float64LE
tckgen: [100%] uncompressing image "sub-63_lh_pvt_dwi.nii.gz"
tckgen: [INFO] opening image "sub-63_lh_zi_dwi.nii.gz"...
tckgen: [INFO] image "sub-63_lh_zi_dwi.nii.gz" opened with dimensions 173x207x173, voxel spacing 1.0499999523162842x1.0499999523162842x1.0499999523162842, datatype Float64LE
tckgen: [100%] uncompressing image "sub-63_lh_zi_dwi.nii.gz"
tckgen: [INFO] opening image "sub-63_lh_zi_dwi.nii.gz"...
tckgen: [INFO] image "sub-63_lh_zi_dwi.nii.gz" opened with dimensions 173x207x173, voxel spacing 1.0499999523162842x1.0499999523162842x1.0499999523162842, datatype Float64LE
tckgen: [100%] uncompressing image "sub-63_lh_zi_dwi.nii.gz"
tckgen: [INFO] opening image "FOD_WM.mif"...
tckgen: [INFO] image "FOD_WM.mif" opened with dimensions 173x207x173x45, voxel spacing 1.05x1.05x1.05x1, datatype Float32LE
tckgen: [INFO] step size = 0.524999976 mm
tckgen: [INFO] maximum deviation angle = 45 deg
tckgen: [INFO] minimum radius of curvature = 1.0499999230973744 mm
tckgen: [INFO] iFOD2 internal step size = 0.174999997 mm
tckgen: [INFO] rejection sampling will use 7 directions with a ratio of 2.15373945 (predicted number of samples per step = 12.9595909)

Machine B -info:

tckgen: [WARNING] existing output files will be overwritten
tckgen: [INFO] opening image "sub-63_lh_pvt_dwi.nii.gz"...
tckgen: [INFO] Axes and transform of image "sub-63_lh_pvt_dwi.nii.gz" altered to approximate RAS coordinate system
tckgen: [INFO] image "sub-63_lh_pvt_dwi.nii.gz" opened with dimensions 173x207x173, voxel spacing 1.0499999523162842x1.0499999523162842x1.0499999523162842, datatype Float64LE
tckgen: uncompressing image "sub-63_lh_pvt_dwi.nii.gz"...  [================================]
tckgen: [INFO] opening image "sub-63_lh_zi_dwi.nii.gz"...
tckgen: [INFO] Axes and transform of image "sub-63_lh_zi_dwi.nii.gz" altered to approximate RAS coordinate system
tckgen: [INFO] image "sub-63_lh_zi_dwi.nii.gz" opened with dimensions 173x207x173, voxel spacing 1.0499999523162842x1.0499999523162842x1.0499999523162842, datatype Float64LE
tckgen: uncompressing image "sub-63_lh_zi_dwi.nii.gz"...  [================================]
tckgen: [INFO] opening image "sub-63_lh_pvt_dwi.nii.gz"...
tckgen: [INFO] Axes and transform of image "sub-63_lh_pvt_dwi.nii.gz" altered to approximate RAS coordinate system
tckgen: [INFO] image "sub-63_lh_pvt_dwi.nii.gz" opened with dimensions 173x207x173, voxel spacing 1.0499999523162842x1.0499999523162842x1.0499999523162842, datatype Float64LE
tckgen: uncompressing image "sub-63_lh_pvt_dwi.nii.gz"...  [================================]
tckgen: [INFO] opening image "sub-63_lh_zi_dwi.nii.gz"...
tckgen: [INFO] Axes and transform of image "sub-63_lh_zi_dwi.nii.gz" altered to approximate RAS coordinate system
tckgen: [INFO] image "sub-63_lh_zi_dwi.nii.gz" opened with dimensions 173x207x173, voxel spacing 1.0499999523162842x1.0499999523162842x1.0499999523162842, datatype Float64LE
tckgen: uncompressing image "sub-63_lh_zi_dwi.nii.gz"...  [================================]
tckgen: [INFO] opening image "sub-63_lh_zi_dwi.nii.gz"...
tckgen: [INFO] Axes and transform of image "sub-63_lh_zi_dwi.nii.gz" altered to approximate RAS coordinate system
tckgen: [INFO] image "sub-63_lh_zi_dwi.nii.gz" opened with dimensions 173x207x173, voxel spacing 1.0499999523162842x1.0499999523162842x1.0499999523162842, datatype Float64LE
tckgen: uncompressing image "sub-63_lh_zi_dwi.nii.gz"...  [================================]
tckgen: [INFO] opening image "FOD_WM.mif"...
tckgen: [INFO] image "FOD_WM.mif" opened with dimensions 173x207x173x45, voxel spacing 1.05x1.05x1.05x1, datatype Float32LE
tckgen: [INFO] step size = 0.524999976 mm
tckgen: [INFO] maximum deviation angle = 45 deg
tckgen: [INFO] minimum radius of curvature = 1.0499999230973744 mm
tckgen: [INFO] iFOD2 internal step size = 0.174999997 mm
tckgen: [INFO] rejection sampling will use 7 directions with a ratio of 2.15373945 (predicted number of samples per step = 12.9595909)

Machine A output tck:

Machine B output tck:

(Visualizing both of these images in MRview, unchecked the “crop to slab” option)

These are the commands i used to generate the FOD.

bet sub-63_dwi.nii.gz sub-63_dwi_bet.nii.gz

mrconvert sub-63_dwi.nii.gz -fslgrad sub-63_dwi.bvec sub-63_dwi.bval sub-63_dwi.mif

dwi2response dhollander sub-63_dwi.mif response_wm.txt response_gm.txt response_csf.txt -mask sub-63_dwi_bet.nii.gz

dwi2fod msmt_csd sub-63_dwi.mif response_wm.txt FOD_WM.mif response_gm.txt FOD_GM.mif response_csf.txt FOD_CSF.mif -mask sub-63_dwi_bet_mask.nii.gz

So, yeah. I’m kind of stuck. If you have any insight on how to resolve this, I would really appreciate it. Thanks again for the help.

-Sabir

mblesac · November 13, 2019, 12:45pm

Hi,

I think the discrepancy you observe here, is because the oldest version you are using is probably from before of the update when the default prameters for tckgen were modified due to a bug. Could you try adding -cutoff 0.1 in the newest version and se if the results are more similar?

Best regards,

Manuel

ThijsDhollander · November 14, 2019, 12:27am

Hi @sabco,

I think @mblesac is indeed on to the explanation. Do give his suggestion a go to see if outputs are more similar; that could help confirm it. That said, however, due to the kinds of things that were changed, you can’t correctly overcome all differences via a manual change to the -cutoff though. If you really rely on both of these environments producing the same (or similar) result without a persistent bias, I think the only safe solution will be to install the same version on both systems.

Cheers,
Thijs

sabco · November 19, 2019, 4:03am

Hi @mblesac and @ThijsDhollander.

I re-ran it using -cutoff 0.1 and -seed_cutoff 0.1 and the results did look more similar! Thanks so much for pointing me to this direction.

You are right, in that the results are not exactly the same, namely the number of streamlines selected is less in the current version, than the previous version. Although, the locations of those streamlines are generally the same.

I will indeed ensure the versions are the same on both machines, I just didn’t realize it until now.

-Sabir

ThijsDhollander · November 19, 2019, 4:46am

Good to hear! This does confirm the issue had to do with the change in versions and the bug fix that happened in between, as @mblesac correctly realised. But indeed, you’d still want to use the same version of the software if results need to be consistent between both processing environments.

Cheers,
Thijs