I’ve preprocessed my data with qsiprep and am no trying to do my tractography using it as an input to pyAFQ. So far, I’v been using pyAFQ via the command line and a dedicated config.toml file containing my settings.
Now, it seems that by default pyAFQ does something strange: If I do not specify anything for bundle_info in the config file, it seems to attempt to track all possible bundles it has in its library which seem to be in conflinct. I then get some warnings about overlapping ROIs during running pyAFQ and output bundles only for (most parts of) the corpus callosum. Other bundles are empty.
My question now is: What do I pass in the config.toml to limite the bundles to, for example the “default18_bd” (which I assume are the 18 default major bundles included in pyAFQ)? I tried bundle_info = "default18_bd" but this leads to a crash saying that the dictionary I passed is not a dictionary or empty.
Does anybody know how to use one of the default dictionaries using the config.toml?
Not a direct answer to your question but you can use Qsirecon and edit the pyafq_tractometry recon spec to add the default bundle name to the bundle_info section.
Hi @t_p : thanks for using pyAFQ, and thanks for your question.
First, for the overall logic: Indeed, per default pyAFQ tries to find an extended set of tracts, which includes 8 different sub-segments of the corpus callosum (as defined in this paper). However, this way of defining callosal tracts – while it covers more of the corpus callosum – differs from the classic definition of the forceps major and minor, so the software warns the user that only one of these definitions (the more granular, which we tend to prefer) will be used.
If you are still interested in using the 18-bundle version (which has forceps minor and forceps major) you can put in the following line in your config file, which should do what you want:
bundle_info = "default18_bd()"
Note that the parentheses, which need to be there to call the function, which otherwise raises the error you saw.
Hope that clarifies what you were seeing, but please do let me know if you have any remaining questions.
Thanks for the explanation, that makes perfect sense. I managed to limit the tracking to the 18-bundle version using your code. Also, I noticed that I had introduced a mistake by somehow (?) setting the threshold for the probability maps to “3” which resulted in empty outputs for many bundles. I reverted to the default 0 and now everything seems to be working. So, the problem wasn’t caused by the overlap in the default ROIs.