[Mrtrix-discussion] AFD-weighted connectivity

[Roine Timo]

Hi Rob,

Thanks for the quick fix and a comprehensive answer! It made it very clear what is the benefit of the afdconnectivity in comparison to basic FOD amplitude weighting. I will use the tcknodeextract and afdconnectivity in my analyses (~10M streamlines), but in addition try to compare to the SIFTed streamlines, although I only have less than 1M after SIFT.

Cheers,
Timo


________________________________
Lähettäjä: Robert Smith [robert.smith at florey.edu.au]
Lähetetty: 29. toukokuuta 2014 4:44
Vastaanottaja: Roine Timo
Kopio: mrtrix-discussion at public.nitrc.org
Aihe: Re: [Mrtrix-discussion] AFD-weighted connectivity

Hi Timo,

We have discussed this internally a couple of times. Although the track mapping code is capable of sampling the FOD amplitude along each streamline for the purpose of generating a TWI, I haven't implemented something similar for the connectome code. This is somewhat deliberate; we were concerned that if we made such an option available, then people would assume that this is a valid alternative to AFD / SIFT, which it most certainly would not be.
When you look at what AFD / SIFT are quantifying at the fixel / connectivity level, then consider what you would actually be quantifying by taking the e.g. mean FOD amplitude along each streamline followed by the e.g. mean value across streamlines connecting a pair of nodes, the latter is not equivalent.
For instance, in this particular case (i.e. mean FOD amplitude along streamline, mean value across streamlines for each edge) what you would actually get is approximately proportional to the mean partial volume fraction of the pathway of interest, averaged across the volume of the pathway of interest (average weighted by streamline count & includes any bundle interfaces where the partial volume fraction decreases), potentially also confounded by streamline / FOD orientation dispersion if you sample the FOD amplitude along the streamline tangent rather than doing FOD segmentation & fixel assignments.
This can be implemented if there is enough demand for it, but it's not something that we would necessarily advocate doing, and much care would need to be taken in the interpretation of any significant results.

The afdconnectivity command is provided as what we believe to be a better alternative for quantifying connection density between regions where SIFT is not applicable. By using the streamlines to define a fixel mask rather than having each streamline make an equal contribution to the edge, the effect of non-biological regional fluctuations in streamlines density is somewhat mitigated; by taking the integral of segmented FOD lobes rather than the tangential FOD amplitude, effects of fibre dispersion are mitigated; and by summing these integrals and dividing by the mean streamline length, you get an approximation of the cross-sectional area of the connecting pathway; a 'poor-man's SIFT' if you will. Probably the main confound with this approach is 'partial volume' with other connections within the fixels defined by the mask.

Regarding tcknodeextract, turns out a bug snuck into the code while we were optimising the tractography file handling code a few months back. It only affects tcknodeextract, hence why it hasn't been spotted until now.
(By default, we use a buffered tractography file writing class to maximise efficiency in writing to HDD; but because tcknodeextract can potentially generate a huge number of output .tck files at once and could therefore require more than the system's available memory, it uses a slower un-buffered class; the bug was causing it to write infinity over and over again instead of the track data, hence why your matrices were empty :-/ .)
I've pushed the fix to the repository, so you can re-download or pull the changes using Git.

P.S. If only there were a method that could provide a biologically-meaningful measure of regional connectivity that doesn't require the removal of streamlines... ;-P

Rob


--

Robert Smith, Ph.D
Research Officer, Imaging Division

The Florey Institute of Neuroscience and Mental Health
Melbourne Brain Centre - Austin Campus
245 Burgundy Street
Heidelberg Vic 3084
Ph: +61 3 9035 7128
Fax: +61 3 9035 7301
www.florey.edu.au<http://www.florey.edu.au/>


On Wed, May 28, 2014 at 5:54 PM, Roine Timo <timo.roine at uantwerpen.be<mailto:timo.roine at uantwerpen.be>> wrote:
Hello,

Thanks for the great software and the recent prerelease of the new functionalities!

I am doing structural connectivity analyses and plan to also use AFD as the network weight (among other measures). However, I noticed that the tract-level (i.e. fixel-, not voxel-wise) AFD is not implemented in the tck2connectome-function yet. Are there any plans to include AFD-weighting to tck2connectome?

An alternative, but much more complicated approach, is to use tcknodeextract to extract streamlines between all pairs of labels and then use afdconnectivity and output the AFD-values into a text file. However, it seems that tcknodeextract does not work properly. It saves the tck-files and everything looks correct (e.g. some file-sizes are larger than others, so the number of streamlines varies), but when loading the files (e.g. matlab or mrview), no streamlines exist in the files (the data-field has empty matrices for each streamline). I tested this also with a very simple parcellation image and multiple different whole brain tck-files, without effect. Any idea what could be causing this? I managed to circumvent the problem partly by using tckedit instead, but the result will be different, as any part of the tract may now pass through the parcellated region, not just the end-point (i.e. a pass-through behavior instead).

Thanks in advance!

Kind regards,
Timo

P.S. I know that the SIFTed tract-count may be a better measure for the connectivity, but due to a huge amount of data (about 380 datasets), I would prefer to keep all of the tracts instead.

--
Timo Roine
timo.roine at uantwerpen.be<mailto:timo.roine at uantwerpen.be>
iMinds-Vision Lab
University of Antwerp, Belgium




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.nitrc.org/pipermail/mrtrix-discussion/attachments/20140529/4fec050d/attachment.html>