 |
 |
Hi - sorry just catching up with this thread. Cortical surfaces are very helpful to avoid things like streamlines crossing gyral walls and jumping from one gyrus to the next. I tend to use the pial surface as a stopping mask to avoid this. You can imagine that this is more powerful that using a voxel representation to do this kind of thing. On the other hand, for counting connections, surface ROIs are more “stringent”. E.g., in order for a streamline to cross a surface ROI, you need the local orientation field to be pointing towards that (2D) ROI; whereas voxels being 3D can “catch” more streamlines. Of course, this can be both good (more specific) and bad (less sensitive). Cheers Saad On 30 Jun 2014, at 18:40, Katipally, Rohan (NIH/NINDS)[V] <[log in to unmask]<mailto:[log in to unmask]>> wrote: Thank you for your prompt response and link to your visualization code, Martin. I also agree, it would be great to hear one of the FSL developers opinions about volume vs. surface tracking. Regarding using multiple threads, you can in theory parallelize probtrackx2 yourself. For example, if I have N freesurfer surface ROIs, I created N commands (one for each seed to all other seeds) to run simultaneously (instead of serially) on a cluster, and I will concatenate the results afterward. While this saves time, I imagine you can parallelize this even more by creating a batch job with commands for every seed to target combination (N^2 commands). And if you really want, you can split up the 5000 samples into smaller sample counts (e.g. 5 runs of 1000 samples). You can programmatically generate these commands too, but they may bog down your cluster with so many runs for each subject occurring simultaneously, and concatenating everything after can get convoluted. Maybe an FSL developer can chime in if this type of parallelization would even be valid. For example, if the random number generator for sample creation follows the same sequence for each unique probtrackx run, splitting up the 5000 samples into 5 smaller subsets would incorrectly produce 5 identical random samples. Thanks, Rohan ________________________________________ From: Martin Luessi [[log in to unmask]<mailto:[log in to unmask]>] Sent: Monday, June 30, 2014 1:06 PM To: Katipally, Rohan (NIH/NINDS)[V]; [log in to unmask]<mailto:[log in to unmask]> Subject: Re: probtrackx2 missing connections when using FreeSurfer surface seeds/tragets Hi Rohan, On 06/30/14 11:37, Rohan Katipally wrote: Hi Martin, Your posts have been helpful, as I've been doing a similar analysis with freesurfer surface ROIs. So just to confirm with you, have you found that surface ROIs are giving you more robust results than when converting to volume ROIs (as described in http://sburns.org/2014/05/03/cortical-tractography-recipe.html), now that you've figured out the meshspace option? I have not performed any quantitative analyses to confirm that the results are more robust. It seems to me that using the mesh should in theory be better given the way the targets/seeds are defined. I have also found that some cross-hemispheric connections were absent when using volumes. Maybe one of the FSL developers can give more insight into the pros/cons. Furthermore, running probtrackx2 on all these surfaces (even when I run all my seeds in parallel on a cluster) take a long time. Have you tried decimating the surfaces (with mris_decimate) and have you found that it deteriorates results? I was planning on decimating to 1/2 or 1/3 of the original amount of vertices to speed up processing time. Because diffusion space is relatively low-res and tracking occurs in diffusion space, I can't imagine losing too much with even 1/3 of the original amount of vertices. I will probably confirm for myself, but just curious if you've tried it yourself. Yes, it takes quite a long time and is very memory intensive. I have not tried decimating the surfaces and I don't know if it is a good idea. It would be great if probtrackx would use multiple threads to speed up the estimation (so one could use e.g. 4 CPUs / 25GB memory on a cluster node). Finally, if you don't mind me asking, what program did you use to make those visuals of the network? They look great. The plots are done using MNE-Python and thanks (I wrote most of the connectivity plot code): http://martinos.org/mne/stable/mne-python.html Best, Martin Thanks, Rohan -- Martin Luessi, Ph.D. Research Fellow Department of Radiology Athinoula A. Martinos Center for Biomedical Imaging Massachusetts General Hospital Harvard Medical School 149 13th Street Charlestown, MA 02129 Fax: +1 617 726-7422 The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -- Saad Jbabdi University of Oxford, FMRIB Centre JR Hospital, Headington, OX3 9DU, UK (+44)1865-222466 (fax 717) www.ndcn.ox.ac.uk/team/researchers/saad-jbabdi<http://www.ndcn.ox.ac.uk/team/researchers/saad-jbabdi>