How to import DSI Studio trk.gz files

Hello,

Just checking in to see if anyone is working on a way to import tracts generated in DSI studio (.trk.gz) into 3d Slicer. I’ve tried converting to vtk via TrackVis, but the orientation was off and I could not figure out how to fix it. If there is not a way to get .trk files into slicer, does anyone have a straight forward way to make this conversion that allow for adjusting the orientation?

Thanks in advance for your help.

Will

Usually when meshes appear with unexpected orientation it is due to difference in coordinate system (LPS/RAS). If you are loading a mesh file (.vtk, .ply, .stl, … file ) and the coordinate system is not specified in the file header then Slicer assumes DICOM convention (LPS), but you can choose RAS after you select the file (in “Add data” window click on “Show options” in the top-right corner).

These topics may also help:

Let us know how it works.

Be sure to install SlicerDMRI and open your vtk files as FiberBundles nodes. VTK files do not declare their space, so Slicer reads them in LPS, FiberBundles are always RAS (since they may contain tensors-per-vertex that are in RAS we didn’t change the convention when Slicer changed to LPS).

Thank you all for your response. Unfortunately, still no luck.

I have the DMRI module installed and tried opening as a model (RAS and LPS) and fiber bundle (which defaults to LPS).

I think I have figured out a few things though. It doesn’t look like an orientation problem but a spacing problem. In the attached picture you can see the same track in 3 different locations. All tracts came from dsi studio then were converted to .vtk in TrackVis. The green tract on the left is LPC and the yellow on the right is RAS. For both the yellow tracts I added a FLAIR series to dsi studio and exported tracts “in slice (FLAIR) space”. Of note the FLAIR and DTI were acquired in the same session (so implicitly co-regesistered). Although that clearly didn’t help.

I have reviewed all the dsi studio threads and the closest thing I have have been able to find is some code from the guys at nibable https://nipy.org/nibabel/devel/biaps/biap_0005.html

However, my coding skills are modest at best and I can’t figure out how to implement what they’re proposing.

Here is the same tract (created in dsi studio) being displayed in TrackVis:

So, it seems there is a problem with saving as vtk file. Perhaps, as was mentioned, the lack of header information in vtk files is the problem. I’m just not sure what to do about it.

Any additional thoughts are greatly appreciated. I really want to get the tracts into 3dslicer because, for all other image modalities, I really appreciate the flexibility and rendering options. The ability to integrate tracts from dsi studio is last piece of the “puzzle” I’ve been working on :slight_smile:

It’s a good question and one we would like to see solved. Like most groups the SlicerDMRI effort has focused mostly on making sure we save/reload our own data correctly and I think the vtk format and our coordinate systems are pretty well documented. Perhaps you can get similar documentation about what DSI Studio assumptions are then the link would be clear.

Alternatively there are very good tractography solutions in SlicerDMRI (e.g. UKF Tractography) and if you have the seeds you could try that. Is there something special about the DSI Studio tracts that SlicerDMRI doesn’t support?

Thanks for your response. Here is what DSI studio says about saving tracts:
“DSI Studio saves tracks in the native diffusion voxel space rotated to “LPS”. The coordinates are voxel coordinates started from (0,0,0) at the most left/anterior/bottom point of the image volume. The orientation is (+right,+posterior, +top). For example, (1,2,3) = [the left most 1st voxel, the most anterior second voxel, the bottom 3rd voxel].” http://dsi-studio.labsolver.org/Manual/Fiber-Tracking

However this is all saved a trk file. Specifics regarding trk file are spelled out here: http://www.trackvis.org/docs/?subsect=fileformat . Maybe TrackVis is doing something weird to the data when it converts from trk to vtk.

I guess it would be nice if 3dslicer could import trk files. Are there any plans for this in the future?

After some more digging I found this tutorial (https://dipy.org/documentation/1.4.1./examples_built/streamline_formats/#example-streamline-formats) on Nipy, which may be helpful for others with similar issue. It looks like they might have some code to transform vtk to trk in whatever anatomical scan space you add. I haven’t had time yet to test but will report back if it works.

I like DSI studio because of the option for generalized Q sampling reconstruction, which seems to produce good results even with noisy clinical data and seems to track pretty well through edematous tissue, built in features for eddy distortion correction, template-based seeding approach (that warps the template to patients native space so all tracking occurs in native space), and ability to export trk file. Also, it has pretty good documentation and discussion board. I’m also just more familiar with it than other software. However, maybe I will give the tracking analysis in slicer a try.

It’s probably not in our critical path, so no. There have been some discussions recently among various groups about a new standard for tractography and if that takes off I could imaging that would be a good target for integration.

Sorry to chime in here. I would be interested in Slicer being able to read TRK, and potentially TCK, files. I may be willing to invest some time into this if maintainers could provide some initial pointers and thoughts, and maybe an estimate of how hard they consider this would be, to start having a look at how this could be made available. Thanks.

If there are packages that can read these files it should be feasible to follow the same approach used in this code:

For sure there are, easiest would be DIPY for me.

Thanks Steve. Will have a look as time permits. As far as I understand we can do an import dipy in Slicer without issues.

I haven’t tried recently, but I think so, yes, unless there are some dependency conflicts. There is great potential synergy so it’s good that you are investigating this.

Glad to see I wasn’t the only one who thought this might be useful :slight_smile:

jhlegarreta, any luck getting trk files into 3Dslicer easily?

jhlegarreta, any luck getting trk files into 3Dslicer easily?

Although I do believe that supporting .trk and .tck files is a much needed feature, I have not been able to have a look at how this could be supported seamlessly. I am really sorry.