[Mrtrix-discussion] RE: Mrtrix-discussion Digest, Vol 33, Issue 9

[Thijs Dhollander]

Hi Gabriel,

I did receive my own text, but I saw in the online archives of the mailing list that the text indeed disappeared over there.  I guess it has to do with the HTML or Rich Text formatting of that text; so here goes a plain text copy of all of it (for completeness, I also included the accompanying attachment again):

-------------------

First off, guessing from your "10000000", I assume computation time and resources (read: disk space for the resulting .tck file) are not an issue; i.e. you just want the best final result possible.

Taking that in mind (especially a lot of computation time), I would personally indeed use the full brain mask for seeding.  I've included another drawing in attachment to illustrate this.  Part of your options for the streamtracking command would now look like:

-mask blue.mif -seed blue.mif -include green1.mif -include green2.mif -stop

In this way, you somehow make the least possible assumptions about where the tracks could be, apart from the requirement that they connect both ROI's (green1.mif and green2.mif) and that they should be contained within the brain (blue.mif).  Now you're virtually unable to overlook anything, i.e. you're not biased by what you might specifically be expecting from the final result.

In theory, nothing that comes out of this is "wrong": all resulting accepted tracks will fullfill your criterium of connecting both ROI's by definition of your options.  Of course, looking at the end result, you might get something similar as to what I've drawn: some dense bundle (the one you where actually interested in) and some spurious tracks, or maybe some other (possibly less dense) bundle.  You might then use this end result to define an exclusion region and do everything all over again, now possibly excluding anything you didn't want to show up in the first place.

It's of course also important to play around with the other parameters (such as the step size, the maximum curvature, the FA or FOD amplitude threshold, etc...): they are, in my opinion, powerfull and less biased ways of defining some properties of your tracks: they are somewhat more "datadriven" than a "brute" cutoff by a mask (although the FA threshold is also basically a mask).  If in the previous example, for instance, you ended up with a lot of spurious tracks in many different regions of the brain, the source of the problem might be found in a too losely constrained FOD amplitude or curvature.

About the number of tracks: I think your only constraints here are again available computation time and resources.  Apart from that, "more is better", because it can only give you a more complete view on the continuum of tracks that are possible, given your defined options.  For instance, if you performed probabilistic tracking in the previous example, you would not have been able to avoid the spurious tracks for sure by lowering your amount of tracks.  Even if you set the maximum number to 1, there exists a chance it would have been one of those spurious tracks.  By generating more tracks, you get a better view on the full distribution of tracks, and are as such better able to interpret the result.  A realistic but still quite robust number I personally prefer for between-region tracking is probably a few thousands (5000 or so); but again, this depends on what you're used to, how large the structure you are looking for actually is, and what your machine and time can handle. ;-)

Finally, also take in mind to set the -maxnum option high enough, if you were to do something similar to the previous example.  It's very likely more than 99% of the tracks are discarded all the time in this case.  By default, -maxnum is 100x -number.  So if you really require the final number to be something specific, you might want to set -maxnum way higher than 100x -number.

Greetings,
Thijs

-------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: optimalbetweentracking.png
Type: image/png
Size: 1921 bytes
Desc: optimalbetweentracking.png
Url : http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20111103/0c3d2a76/optimalbetweentracking.png