Group average response function

[sina-mansour]

Following on the suggestion by @Lestropie (this commit):

RS: As discussed, would be preferable to have used a group average response function, especially if the ODF images are to be provided to the community as that could result in wider applicability of those data for other projects (e.g. construction of multi-tissue odf template). This would not necessarily have to be an average across the whole UKB: you could obtain DWI data for some manageable subset and compute the average response functions from those, and those would be adequately representative to be used across all subjects.~

[sina-mansour]

Hi Rob,

I'm thinking whether this is something that is currently being practiced in common connectivity mapping pipelines, and more importantly do we expect that this would make a significant difference in the mapped connectomes.

The project mainly aims to generate connectomes and provide connectivity matrices to the community. Hence, the plan was to run the tractography pipeline for every individual separately, store the intermediary files on scratch, then map various connectivity matrices (streamline count, fiber density, spread, length, mean FA, etc.) and provide the connectivity maps for the whole sample (>40K scans). I think if the single subject ODF estimates are commonly practiced and are expected to provide a good enough solution, maybe we could avoid implementing the group average ODF to save the time required for both appropriate implementation and execution.

[Lestropie]

The primary motivation for pre-generating representative response functions would be:

• If you are distributing ODF images that could subsequently be used by others;
• If quantifying FBC and are pessimistic about using the post-hoc AFD correction described here and used here, and would prefer for that metric to be quantified in the more conventional way using common response functions as per FBA.

Given that FBC quantification is only one of a wide assortment of metrics being quantified, it's probably not super important to do it in the most robust way.

The alternative argument is that pre-computing (and manually vetting) response functions from some manageable set of subjects would provide a certain level of robustness against response function estimation issues. If for any reason response function estimation is not quite right, it could corrupt all data derived for that subject, whereas if you precompute and check them for a subset of subjects you can verify that the response functions and good before proceeding with spherical deconvolution.

[caioseguin]

I tend towards not pre-computing the group response function.

As both of you pointed out, we are aiming to provide a wide range of connectivity measures to the community, and FBC would only be one of them. Given that we can still compute FBC if we skip this step, even though the estimation won't be ideal, it will be good enough to add another useful measure to the mix at a cheap computational (and implementional) cost.

I don't think we were planning on providing ODF images (but I'm not opposed to the idea if others are keen).

[Lestropie]

@caioseguin: The logic needs to be reversed. If you want to provide ODF images, then the potential utility of such images to the wider community would be greatly diminished if we were to not use common response functions. So I'd suggest answering that question and working backwards.

[sina-mansour]

Given that at this point we don't plan to release the ODF images, I'll use the individualized ODF estimates to save time and reduce the overall complexity of the pipeline.