Misalignment of nifti image and a fiber tract saved as trk

[dagra]

Hi,

i have the following files:

1. CST L on t1.nii.gz. Corticospinal fiber tract overlaid on a t1 image and saved as nifti.
2. CST L.zip. Corticospinal fiber tract saved as trk (inside the zip file).

I can display them correctly on trackvis and freeview (from freesurfer). But when i try to view them in Mitk Diffusion they are not correctly overlaid.

As far as i can tell the trk file is correctly populated and since i can view them on the other 2 applications i think that Mitk Diffusion has a bug.

Any thoughts?

Thanks

[peterneher]

MITK Diffusion expects the fiber coordinates to be in physical space (in mm). Stuff such as offset/origin and voxel size/spacing in the trk header are ignored in MITK Diffusion. Maybe this is the cause of this issue. I will look into it.

[dagra]

First of all, thanks for the immediate response.

To give you some more info, this trk was created and saved using nibabel. During save nibabel converts the fibers to the voxel space (not in the world coordinates) in mm.

By physical space, you mean the voxel space or the world space? I suppose the latter. But, according to nibabel, the fibers must be in voxel space in mm (check here for example). Is that incorrect or my interpretation is wrong?

Also, MITK Diffusion takes into consideration the affine matrix, right? A strange behavior that i noticed, is that if i set the affine of either the nifti or the trk to the Identity matrix, but not both, then they are displayed correctly.

[peterneher]

Sorry for the late reply. I was out of office for a while.

With physical space I mean world space. MITK does not consider the matrix, which is probably the issue here. I hope I will find the time to adapt this in MITK Diffusion. I added an issue in our bugtracker (https://phabricator.mitk.org/T26850). Alternatively you could transform the coordinates into world space "manually", e.g. using python.

[peterneher]

Can you tell me what the transform should look like in your example? In our reader the voxel spacing seems to be 1, the origin 0 and the matrix identity.

[dagra]

The voxel spacing and origin in your reader is in agreement with the trk (but i am not sure that the origin is correctly specified in the trk), but the affine matrix (which has the name vox_to_world in the nibabel/trk and i know it is correctly specified in the trk) is not the identity. Loading and printing with nibabel in python i get the following:

MAGIC NUMBER: TRACK
v.2
dim: [166 196 197]
voxel_sizes: [1.         0.99999994 0.9999964 ]
origin: [0. 0. 0.]
nb_scalars: 0
scalar_names:

nb_properties: 0
property_names:

vox_to_world:
[[ 9.9941826e-01  3.6152336e-03  3.3912133e-02 -8.3972984e+01]
 [-4.5971009e-03  9.9957108e-01  2.8919928e-02 -1.0333485e+02]
 [-3.3793155e-02 -2.9059106e-02  9.9900275e-01 -9.3373940e+01]
 [ 0.0000000e+00  0.0000000e+00  0.0000000e+00  1.0000000e+00]]
voxel_order: RAS
image_orientation_patient: [1. 0. 0. 0. 1. 0.]
pad1: 
pad2: RAS
invert_x: 
invert_y: 
invert_z: 
swap_xy: 
swap_yz: 
swap_zx: 
n_count: 406
hdr_size: 1000

[peterneher]

Ah, I didn't read the matrix. Old trkheader format on my side. Now I found it. But I think there is an additional RAS/LPS issue. I'm on it.

[peterneher]

Looks fine now in the example images you sent me. So it should work in the new nightly installers tomorrow. Can you let me know if this update resolves your issue?

[peterneher]

I only apply the matrix now and account for the RAS/LPS flip. I don't take a potential .5 voxel shift caused by center vs. corner based coordinates into account.

[dagra]

Ok! Nice! I'll check back tomorrow and let you know.

[dagra]

I checked the example images with the nightly installer and it seems ok!

But, since you're on it, i did some more testing with some more examples and it failed in this. In this example, the only difference with the first i gave you is that the voxel sizes are not 1mm, but 1.1mm. I assume that some normalization is required based on the voxel sizes, which was not required in the previous example because the voxel size happened to be in 1mm.

Bellow is the output from nibabel:

MAGIC NUMBER: TRACK
v.2
dim: [152 178 181]
voxel_sizes: [1.0999999 1.0999999 1.0999998]
origin: [0. 0. 0.]
nb_scalars: 0
scalar_names:

nb_properties: 0
property_names:

vox_to_world:
[[ 1.09935999e+00  3.97675671e-03  3.73034738e-02 -8.48062668e+01]
 [-5.05681057e-03  1.09952819e+00  3.18120308e-02 -1.03151985e+02]
 [-3.71724665e-02 -3.19650173e-02  1.09890676e+00 -9.43692627e+01]
 [ 0.00000000e+00  0.00000000e+00  0.00000000e+00  1.00000000e+00]]
voxel_order: RAS
image_orientation_patient: [1. 0. 0. 0. 1. 0.]
pad1: 
pad2: RAS
invert_x: 
invert_y: 
invert_z: 
swap_xy: 
swap_yz: 
swap_zx: 
n_count: 423
hdr_size: 1000

P.S.: I checked that this example is showing correctly in trackvis and freeview.

[peterneher]

I am accounting for the voxel size now by dividing the matrix columns by the size. The result looks good, but there seems to be a tiny shift between the first tractogram you sent me and the second one with voxel size 1.1. Should be in the new installer tomorrow.

[dagra]

Great! I checked the new installer and it seems fine!

Regarding the tiny shift, i can't really see the difference and i tried some more things and it worked ok, so i can't add anything more. Is it possible to be related with the half-voxel shift (related to the center vs the corner of the voxel) and that this difference is enhanced now with this division?

In any case, thanks for the effort! From my point of view, the issue has been resolved.

[peterneher]

Perfect. Thank you for your feedback and your help in testing! Don't hesitate to contact me again if you have any more issues or for giving other feedback.