Hi Ehsan,

No worries. I was actually very interested in your dataset because I haven't actually run the FT scripts with anisotropic voxel dimensions. I wrote the scripts  to accommodate this but it was great to see that it didn't go on the fritz!

Orientations are the worst! I've spent a long time trying to figure them out. The first thing I did was check the nifti header since I was curious about the voxel dimensions and image size. This also has an affine matrix which is a vox_to_ras transformation which you can often look at to tell the orientation. Since your's was a diagonal matrix with the diagonal elements being positive it means the image volume is already in ras (it only needs scaling and translation to get to ras in mm space). For the gradient table, it's purely a shot in the dark without more context... I tried LAS first since that's what spm things seem to use, then I tried RAS because that's what you're image is in, and then I tried LPS, which is how they are stored in the dicoms (confusing, right?!). After you have the odf_optimization complete you can just change these for the tractography so it doesn't take long, and it's not hard to tell when it's not correct on this level. Subtler changes occur with the rotations of the image volume, ie if the image has been rotated by some other program you also have to rotate the gradient tables. Since your nifti hdr.mat was diagonal this implies either another program has put it that way or the Image_Orientation_Patient field in your dicom header is [1 0 0 0 1 0], which you can potentially check with Matlab's dicominfo function. I really wish all of this was streamlined somehow within DKE but we stopped short of trying to do this, since e have collaborators with Siemen's, GE, and Philips scanners and depending on the software version used to build the dicoms the gradient info can be in completely different places within the file so it's been hard to make a general approach. I'm not sure how other programs tackle this...

I know what you mean. The file size issue is very interesting. The .fib file is actually built dynamically as it goes to try to avoid this issue, but I am suspicious that something is cutting it off. I think the problem is arising because I use double precision floating point format to save all of the info in the .fib file, which is likely excessive. In the 'high' resolution option each voxel has 1281 vertices used to render the ODFs in DSI Studio and since there were over 800,000 voxels in your dataset that leads to about a billion data points. This still shouldn't require so much memory to store but it is a lot of data. I will keep looking into this and see if DSI Studio will work with a different format. I have made changes to the FT module and am hoping to do the same for DKE to make it faster so hopefully we will have another version soon.

The odf_optimization script does save a data structure called odf_coeff which can be used to render the ODFs in matlab but it requires some scripting and matlab's visualization tools can't really handle rendering an entire image slice of these. I sometimes like using matlab for publications though because it gives me more control over some of the surface lighting and coloring options  which can help make things look nice. DSI Studio is still the best at this though; it's implemented in VTK, I believe which is way more suitable for this type of rendering... with everything as it is now, you may have to be creative. Both DKE and DSI Studio work in image space meaning they don't really care about the coordinate space defined by hdr.mat so you can just truncate your image and process a subset of your data?

The way the DKE FT module is built performs the odf optimization to get the orientation estimates first and then the tractography after. I believe your problem to be in the odf_optimization step so I think whatever options you've used for the tractography should be fine unless you're seeding like 10 million points!

Best,

Russell