Clean tract based on fiber postion

Dear Mrtrix experts,

I tracked between seed and target regions and I would like to remove outliers from the tract of interest. I would like to remove the fibers whose position deviates more than X standard deviations from the core of the fiber tract, as done in Yeatman et al., 2012*.

My initial thought was to read the positions using read_mrtrix_tracks.m in matlab and clean the data from there, but I realized that I cannot import the cleaned data back to a .tck format in order to continue working in mrtrix. Do you have any suggestion?

Thank you very much for your help!

  • Yeatman, J. D., Dougherty, R. F., Myall, N. J., Wandell, B. A., & Feldman, H. M. (2012). Tract profiles of white matter properties: automating fiber-tract quantification. PloS one, 7(11), e49790.

Hi Anege,
You can use Vistasoft’s fgWrite function. Just make sure you use the latest version, the one that uses the the dtiExportFibersMrtrix function.
Hope this helps. Let me know if this worked out for you.

For the function to work I seem to need to remove the params field from the fg structure.

There is the write_mrtrix_tracks.m Matlab function – have you tried it? If it doesn’t work, we’d need to fix it!

Thank you for the suggestions!

I didn’t know about the existence of write_mrtrix_tracks.m… Using it, I am able to export the tck and visualize it properly in mrview, but I am no longer able to load them in fibernavigator. Fibernavigator quits unexpectedly.

I checked with HexFiend and there is a slight difference between the tck file behaving properly and the one misbehaving:
The file behaving properly separates fibers with bytes: 00 00 C0 7F 00 00 C0 7F 00 00 C0 7F
The file misbehaving separates fibers with bytes: 00 00 C0 FF 00 00 C0 FF 00 00 C0 FF

Manual editing with HexFiend solved the issue.

I don’t know whether this has to do with matlab or with the code in write_mrtrix_tracks.m. I tried to dig in a little in the code of write_mrtrix_tracks.m, but I’m not sure whether any small modification would fix this…

Thank you for your work!

Wow, that’s some impressive detective work! :mag:

It looks like a bug in FiberNavigator, unfortunately… There’s many ways to represent a NaN, according to the IEEE floating-point standard:

A NaN (Not a Number) can be represented with any of the many bit patterns that satisfy the definition of a NaN. The hex value of the NaNshown in TABLE 2-3 is just one of the many bit patterns that can be used to represent a NaN.

MatLab obviously uses one particular (and valid) representation, while in C++, we end up with another, equally valid representation. There are functions to check for NaNs that get will get it right (and this is what we use in our code, which is why it accepts these data). So my guess is that FIberNavigator is relying on a hard-coded value and checking for a bitwise match, rather than using the recommended isnan() function. I reckon it might be worth alerting them to this issue.

In the meantime, I think you might be able to modify the MatLab code to give it your own version of a NaN. First off, you’ll need to define your new NaN:


and then write those instead, by replacing this line with:

fwrite (f, [ mynan mynan mynan ], 'uint32');

That might get around the issue for you… :crossed_fingers:

Impressive detective work indeed.
No need to alert the FiberNavigator team (i.e., me) as I happen to be roaming around the MRtrix forum from time to time :nerd_face:

I just went and looked at our portion of code that loads MRtrix .tck files:

//Read points (x,y,z) until x2 equals NaN (0x0000C07F), meaning end of the tract.
        while( !( cbf.b[0] == 0x00 && cbf.b[1] == 0x00 && cbf.b[2] == 0xC0 && cbf.b[3] == 0x7F ) )
        { ...

So yeah, this was written back in (2011?) and admittedly never updated for something more robust.
@anege: Could you tell me which version of FiberNavigator you are currently using? (I should update that github with a more robust version - found a minor bug in the tract-space loading recently…)

Many thanks,

1 Like

Thank you very much for the feedback!




fwrite (f, [ mynan mynan mynan ], ‘uint32’);

worked fine! :slight_smile: These changes solved the issue and I am able to load the track properly in Fibernavigator.

@chamberm the Fibernavigator version I am using is the one released on october 2015 (Mac OS).

Thank you both again!