I pre-processed my DTI data using afni and fatcat and output a trk data.
I met a problem to read in the trk data.
It seems that the “vox_to_ras” field is 0 in the trk output by 3dtrackID, which means “the matrix is not recorded” (http://www.trackvis.org/docs/?subsect=fileformat).
I would appreciate it if you can kindly check whether you had set the field correctly in the code of 3dTrackID.
The trk format is necessary for me as I want to use “tract_querier” tool to extract white matter structure. The “tract_querier” only accept the “trk” and “vtk” format (see https://github.com/demianw/tract_querier).
And I also use matlab to read in trk format to do some processing on the fiber level.
Thanks very much!
The description of vox_to_ras in the TRK header definition is:
“4x4 matrix for voxel to RAS (crs to xyz) transformation. If vox_to_ras is 0, it means the matrix is not recorded. This field is added from version 2.”
In 3dTrackID, the vox_to_ras 4x4 matrix is initialized to all zeros, which is a valid value, and then it is changed nowhere in the code.
While this aspect of the code is extremely old and predates the SUMA viewing, it might be possible to pull the matrix information from an input DWI set and stored there.
Do you have an example of a DWI file and an associated vox_to_ras matrix? Different softwares use different signs/systems for orientation directions.
Thanks very much!
Besides of the “vox_to_ras” field, the “n_count” field is also wrong.
I guess that the trk from 3dTrackID might specified wrong information in some field or just because some field were missed and made all in wrong order.
If possible, I suggest producing a correct header file for trk output.
If not, we have to turn to other suite that can produce a right trk data because we are not expert in the underlying detail of computing.
We hope to use mature tools instead of our offline custom tricks to fix the header error, which might made out results not reproducible.
Emotionally, I want to stick with afni and factcat.
So Please help if it does not make too much pains:)
Thanks very much again!
I am sorry for raising this topic again. I know you might not be interested in the old trk.
However, I can not abandon it for some historical reasons in the laboratory
I had met a difficulty in opening .trk data from 3dTrackID using matlab. The problem was solved by simply run “spline_filter”, another command in the diffusion toolkit, on the trk output from 3dTrackID. And the new .trk data can be accessed correctly.
One interesting thing is the “voxel_order” field.
All my DTI images were in the order of RAI-(or LPS+). And I assume that the trk after tracking on those DTI images should be in the order of RAI-(or LPS+).
The field “voxel_order” read from the trk output was “RAI”. (I expect this should be “LPS” according to the trackvis tradition)
And when I open the trk file in trackvis, the tracks looks fine but the FA volume where the tracks was calculated from was totally upside-down, anterior-posterior fliped, and might also left-right flipped.
I also use the dti_tracker, a tracking tool in the diffusion toolkit, to do tracking on FA and tensor images from fatcat. The voxel_order is correct. The trackvis display the information as “LPS->LPS”. The FA volume also in right orientation in the trackvis. The matlab also read the information correctly as “LPS”
I feel that the “voxel_order” information set in the trk from 3dTrackID might be in the afni fashion. However, the trackvis use an opposite way to define order.
What’s your opinion? If this is true, please help fix this issue. If not, please give me a feedback so I can optimize my pipeline.
I know I can fix this problem by tracking using DTK. However, the 3dTrackID gave me the best tracking results. I hope to solve the most of thing within afni+fatcat suite.
Thanks very much!
Indeed, I haven’t been able to get to this yet. In large part, because it would involve several other softwares that I am not familiar with. So, if you have done the hard work and know the changes that should be made, then that should speed things up.
Are you saying that the only change needed is that the voxel_order header field needs to use the opposite of AFNI’s voxel order definition? That is, if
3dinfo -orient DSET
returns “RAI” or “IPL”, you want voxel_order to be “LPS” or “SAR”, respectively?
Is that the only change necessary for compatability, then?
This is a reasonable hypothesis from my observation.
If the voxel order was in “RAI” according to 3dinfo, the “voxel_order” field in the header stored in the .trk output should be “LPS”.
I had not try the order of “IPL”.
And I am not sure whether it will affect the coordinates stored in .trk data.
If not, I think simply fixed the “voxel_order” stored in .trk data by using the opposite of 3dinfo output will help.
I had tried to use diffusion toolkit (DTK) to do tracking and avoid the problem. However, the DTK performs poorly on a recent dataset from a Philips MRI scanner. The 3dTrackID gave me very good results. That’s why I want to construct my pipeline on afni+totose+fatcat as much as possible.
Thanks very much!
I have added a new option to 3dTrackID called “-trk_opp_orient”:
-trk_opp_orient :If outputting *.trk files, you can choose to oppositize
the voxel_order parameter for the TRK file (only).
Thus, when inputting AFNI files with orient RAI, the
*.trk file would have voxel_order LPS; this is so that
files can be viewed in some other software, such as DTK.
Please let me know if that works. You might also want to check on resampled data that has other orientations than just RAI (in AFNI-speak).
It is available in the most recent binaries, so you can update your AFNI version to get it. Please let me know if that sorts things out for you using TRK output in DTK.