Hey everyone, I am using some pregenerated .trk files for some tractography analysis, and need to be able to interconvert the data and metadata from LPS to LAS to RAS, etc. for different packages that require one form or another. It seems like there should be a simple way to do this, but I haven’t figured one out yet. Any help anyone could offer would be greatly appreciated! Thanks,
-Cooper M.
Hello @cprmellema ,
Yes, I also spent a lot of time, probably a few weeks trying to figure out the orientation of the NIFTI files. Finally, I will write a simple way to change the orientation here.
fslhd (in FSL) will give you all the header information of the NIFTI file. So, you can check q-form and s-form and [X Y Z] orientation is [R/L, A/P, S/I].
fslorient , you can change your orientation to whatever configuration you like.
fslreorient2std, you can reorient your NIFTI data to the standard format. You can check the documentation to know the meaning of the standard format.
fslswapdim, you can change the order of your NIFTI data.
mrtransform (in MRtrix3), you can change the orientation and order of your NIFTI data.
There are many tools. You can use the most convenient one.
I hope this will help you in your research. Please let me if you have further queries.
Best wishes,
Suren
While I appreciate the information on NIFTI file conversion, I was specifically interested in manipulating the .trk tractography filetype, not NIFTI files.
The TRK format has become popular as it can bundle streamlines into properties and scalars. However, it is an odd streamline format as it is dependent on the orientation and spacing of the underlying voxelwise volume
In addition, I believe that TrackVis assumes that the spacing is shifted by half a voxel in each dimension (e.g. voxel corner vs voxel center).
Due to this complexity, I would strongly suggest converting to a simpler format unless you need the unique properties or use software that does not support any other format. In particular, I would suggest converting data to the MRtrix TCK format
With that format, the vertex X,Y,Z coordinates map directly to the NIfTI world coordinates. You do not need to worry about LAS, RAS, IPL, voxel size, etc.
I would use the Python script trk2tck
Alternatively, if you prefer Graphical interfaces, use the Surfice Tracks menu to add and save different Track formats
I would caution you to validate your results: many tools have misinterpreted the TRK format and the voxel offset (the Surfice solution was validated with TrackVis, but in my experience not all tools are TrackVis compliant).
If you really want to update a .trk from LPS to LAS to RAS, you could run trk2tck and subsequently run tck2trk on the resulting image providing a NIfTI reference anatomical image with the desired orientation and voxel spacing (assuming your original TRK file includes only a single property/scalar; if not you would need to modify tck2trk to be a trk2trk converter):
You may find these discussions relevant:
Hi,
I am still a little confused about the half a voxel shift part in the trk format. The information about the format in TrackVis website, here, does not tell much about the shift.
What I am particularly curious about is, does the shift depend on the information in “voxel_order”? At least in the nibabel conversion, the shift is made always in the same direction, regardless of the voxel order.
Dear @Chris_Rorden, it would be great if you comment on this since you confirmed the conversion done in surfice with TrackVis. Does surfice do the same shift as in nibabel? If so, what is the significance of the voxel_order information in the trk format, e.g., only for visualization purposes?
Thank you very much,
-Baran
@Baran the issue with the TRK format is that the specification never described the voxel shift, and I believe that different tools have implemented it differently. Even some versions of the class-leading DSI-studio created TRK files that were not displayed correctly with other tools. I would suggest using a tractography format that explicitly stores the raw spatial position to avoid complications. The tff_convert_tractogram script will convert between several of these formats (’.tck’, ‘.trk’, ‘.fib’, ‘.vtk’, ‘.trx’ and ‘dpy’). What made TRK popular for many years was its unique ability to store properties and scalars. These features are part of the new, simpler TRX format. Therefore, in this day and age I would recommend using the TRX format.
I am really not sure how nibabel handles TRK. The surfice code with the voxel shift is here. As an aside, a new release of Surfice is imminent that will support TRX.
I am looking forward to switching to TRX too. This will solve a lot of problems. But I think the transition will still take some time. Internally, we use .vtk since there are many visualization tools that support this format. But when it comes to sharing software, e.g., purifibre, we also want to support other formats too, like .trk.
My understanding is that surfice also does the shift the same way as in nibabel. To be consistent at least with these software, I think we will make the same assumption for the shift as well.
This was very useful information. Thank you very much.
MANAGED BY INCF