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?
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).
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.
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
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?
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.
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.
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.