Hello,
I am planning to compute a correlation (across different subjects) between summed SIFT2 weights for a certain pathway and some other behavioral measure. I noticed it was mentioned in another thread (Computing & comparing SIFT2-connectomes) that it might be valuable to multiply the SIFT2 weights by the weighting coefficent, mu.
Should I do this? I used the subject-average WM response function for CSD and ran mtnormalize before running tractography and SIFT2.
Thanks for your help!
John
Note: Looking at a random subsample, the mu values don’t appear to differ very much across subjects. I’d just like to use the best possible metric for each subject.
Hi John,
While I would advocate from a physical standpoint that each subject’s connectome should be multiplied by mu (assuming AFD pre-processing is satisfied), I still haven’t published the article explaining exactly why this is the case (I’m working on it, I promise…). So in your position, you need to consider whether or not to do this given the potential for reviewer critique, especially if you do not fully understand precisely why this scaling should be applied, and would therefore have difficulty in justifying / explaining it if raised.
Cheers
Rob
Isn’t this completely trivial and implied in how SIFT(2) filtered streamline(s) (weights) relate to the FOD? You just need a fixed unit of “streamline-something” (proportionality times streamline count (times weight)) among all subjects that you wish to compare. That’s it… We already did that directly/inherently back in @dchristiaens global tractography work by having the segments contribute a fixed amount of signal (response function), and people were already doing that before in global tractography essentially as well…
So to be honest, I wouldn’t be worried about this, at all. If you just explain that the sum of your streamline weights needs to be proportional to units of FD in the same way for each subject, then well, that explains it all. I’m often quite a critical reviewer (harsh even, but hoping to still be perceived as fair 
), but if you’d state just something like that one sentence, and it’s clear to me what you’ve exactly done, then I wouldn’t have any problems with this as a technical reviewer. On the contrary even: it’d become clear to me that you know what you are doing, which is always a good property of any first author. 
Just for reference in case people want to relate these things to each other: in tckglobal, this is essentially the -weight option.
Thanks @rsmith and @ThijsDhollander. I actually find the reasoning behind mulitplying by the mu coefficient fairly intuitive. I just wanted to make sure that it wasn’t already done somewhere else in the SIFT2 function (so that I would then be doing it twice).
Hmm, good point. I can see how this could be confusing. It may just make sense to have that coefficient directly factored in with the weights, so the sum of streamline weights is simply directly proportional (with a fixed factor) to units of FD. The only issue that could arise is of course in case of a (very very) massive number of streamlines, where the weights may then become very small (and lose precision on the sum of them?). But setting the “fixed” factor to a clever internal constant of appropriate size should typically deal with this, I reckon.
I can only guess, but I suppose @rsmith may have wanted to keep things consistent with SIFT1, where this is of course not possible; or a bit inefficient (to store the same, non-unit, weight for all streamlines again for each individual streamline), and a single number is better suited for this. Another solution would be to store this directly somewhere in the track file (but we’ve got no current definition for such a thing), and take it into account automatically when building a connectome. There’s no good reason to not use it when building connectomes, indeed; and you always need it to be factored in if they’re to be compared quantitatively among each other.
Or maybe just some added documentation may already fix things… but I’d keep it simple indeed: it is quite simple and intuitive, as you say, so over-complicating it may confuse people more rather than give them a direct insight.
My sense is that some documentation might be sufficient. Currently, I don’t think this is mentioned in any of the guides or explained in the tcksift2 help. Or, it might be valuable to let tck2connectome (or other functions that take weights as inputs) to have an option to input mu, which would then produce a mu-multiplied output.
It seems this should at least be in the guide(s), as it should be part of most, if not all, connectome analyses.
That’s a nice idea indeed. Even (or even more so) when using SIFT1, and going on to build a connectome, this may make things much more convenient.