Hi Community,
When I have been working on the structure connetome, the choice of the assignment_radial_search value confused me, is 2 mm the optimized one? It says that this option will perform a radial search from each streamline endpoint to locate the nearest node. That is to say, if one track was assigned to a certain node under the 2 mm search radius, this node was definite the nearest node for this track for any search radius that are more than 2 mm. But I checked my data and found some tracks were assigned to another nodes under 3 mm search radius (jumped to the nearby node for most cases).
I wonder why could this happen? Or is there any mistakes in my understanding?
Thanks a lot
Chenxi
Hi there,
One way of thinking about the radial search (more conceptually rather than how it’s implemented) is: for each streamline endpoint, the nearest non-zero voxel is selected; but then subsequently to that, if the centre of the selected voxel is more than 2mm away from the streamline endpoint, then the parcel is de-selected and the streamline endpoint remains unassigned.
So yes:
if one track was assigned to a certain node under the 2 mm search radius, this node was definite the nearest node for this track for any search radius that are more than 2 mm.
Even in the case where there is more than one parcel within the 2mm search radius, it is always the value in the nearest non-zero voxel that is selected - as long as the distance is less than 2mm. Note that this voxel selection takes into account the sub-voxel position of the streamline endpoint, by quantifying the distance between the voxel centre in scanner space and the streamline endpoint.
is 2 mm the optimized one?
I’m not sure how one would go about ‘optimizing’ that threshold. By raising it, you begin to get unwanted assignments, e.g. streamlines travelling down the spinal column being assigned to a cerebellar hemisphere, streamlines terminating in unlabelled small nuclei being assigned to the nearest (but unrelated) labelled grey matter. By lowering it, there is a danger of failing to assign streamlines correctly due to mis-registration, or how spatially extended the GM parcels are relative to the 5TT segmentation. So even if you could somehow find an ‘optimal’ threshold, it may not be applicable to all data. That 2mm value seemed to give a good compromise when I wrote the code. At some point I may re-investigate an alternative, more robust mechanism for doing these streamlines assignments.
But I checked my data and found some tracks were assigned to another nodes under 3 mm search radius (jumped to the nearby node for most cases).
If a streamline is being assigned to a node that is more than 2mm away, or to one parcel when there is in fact a voxel labelled with an alternative parcel that is closer to the streamline endpoint, then this would suggest that the code is not doing as it should. However if what you’re describing is that by increasing the threshold from 2mm to 3mm, streamlines that were initially not assigned to any parcel are now assigned to a nearby parcel, then this is precisely what the behaviour should be: increasing that search distance allows the voxel corresponding to the nearest node to be further away from the streamline endpoint.
Cheers
Rob
1 Like
What I’m reading in this, is that a track was successfully assigned to a certain parcel using the 2mm search radius, but was assigned to another parcel after increasing the search radius to 3mm; which then typically happened to be a parcel that was “nearby” (I suppose adjacent) the former parcel. That would indeed not make sense (i.e. be a bug in the code), as when the track is assigned to a parcel using any specific search radius, it indeed means that is the definite (sole) closest parcel (for any larger search radius).
@ChenxiZhao , can you confirm that this is in fact what you meant in your original question? (or that we’re misinterpreting your question)
Thanks for your replies.
What I’m reading in this, is that a track was successfully assigned to a certain parcel using the 2mm search radius, but was assigned to another parcel after increasing the search radius to 3mm; which then typically happened to be a parcel that was “nearby” (I suppose adjacent) the former parcel. That would indeed not make sense (i.e. be a bug in the code), as when the track is assigned to a parcel using any specific search radius, it indeed means that is the definite (sole) closest parcel (for any larger search radius).
This is exactly what I want to ask. When I use tracks with 5000 or 1W streamlines, this problem did not occur. But when I use the track with 1M (1,000,000) streamlines, I found 33 streamlines have been assigned to different parcels under different search radius. Here I extract these 33 streamlines and uploaded it along with the pacellated FA image and the node assignments files. https://drive.google.com/open?id=0BxVNRwnEeGVhaXZJdzVseVo5TlU
Best regards!
Thanks for the clarification; and thanks for providing such specific data! That should make finding the issue much easier. 
I’ll have a dig around and let you know what I find.
OK, thanks to your data I found a little glitch in the radial search assignment code. It could result in the incorrect assignment in cases where there were two different nodes that the streamline could plausibly be assigned to, but both were only just within the maximum permissible distance. So that’s why the frequency of errors was very small. It would also only assign to nodes that were directly adjacent, and only in cases where the assignment was relatively ambiguous anyway. The problem has now been fixed; the code should even run a little faster faster now. Thanks again for the very informative report!
I rerun this code and it works well now, thanks for your efforts!