Repository navigation
Replies: 4 comments 2 replies
|
Hi Tal - thanks for sharing these results. That does seem like a rather dramatic difference. Early on in the development of pyAFQ we made similar comparisons, and found repeatability to be pretty good (see https://pmc.ncbi.nlm.nih.gov/articles/PMC8785971/), so this is surprising. My hunch is that this has to do with the process of generating the streamlines. That is, differences in the tractography settings used in each of these pipelines. One way to confirm this hunch would be to take the whole-brain tractography generated in mAFQ (with mrtrix?) and use that as input to the following steps in the pyAFQ. Would you mind trying that (as documented here: https://tractometry.org/pyAFQ/howto/converter.html#tractography-from-other-pipelines)? |
|
Thanks for testing the tractography differences. I am indeed surprised that this had little impact, but maybe that's encouraging. At least it means pyAFQ is more reliable than I thought. As for your new results - this seems like a big effect for a small tweak, but I am not sure that I understand what I am looking at. At what point in the processing is this interpolation taking place? |
|
Thank you both for your suggestions! I experimented with different bundle-cleaning parameters and was able to obtain cleaner, anatomically plausible bundles (see attached example). However, the FA values remained systematically higher than those obtained with mAFQ. I also compared two approaches to diffusion tensor fitting, one using MRtrix3 and the other using pyAFQ. Both produced very similar FA values, suggesting that tensor fitting and FA map generation are unlikely to be the main sources of the discrepancy. One detail worth mentioning is that I intentionally used clip_edges=False, as I found that this setting produced better bundle segmentation results than clip_edges=True. I then performed the clipping and FA sampling between the anatomical ROIs in a separate script. However, even the FA profiles generated directly by the attached pyAFQ script (without clipping) show values that are considerably higher than what we typically observe in our lab. This brings me back to the possibility that I may be overlooking something in my pyAFQ configuration or analysis workflow. I've attached the script I'm currently using. If you have a chance to take a look, I would really appreciate it if you could let me know whether anything stands out as potentially problematic or unusual. Thank you again for your time and help! Best, |



Uh oh!
There was an error while loading. Please reload this page.
Hi,
Our lab is in the final stages of transitioning from mAFQ to pyAFQ (3.0), and we are currently validating the new pipeline using an existing dataset previously analyzed with mAFQ to assess the comparability of the results.
The original DWI resolution is approximately 2.6–2.7 mm isotropic. During our initial tests, pyAFQ had difficulty reliably segmenting some bundles, particularly the Optic Radiation. I therefore upsampled the preprocessed DWI data to 2 mm, which substantially improved the stability of the segmentation. For the comparison with our previous MATLAB results, I tried to keep the downstream processing as similar as possible between the two pipelines. In particular, we used the same whole-brain tractography approach and matched the AFQ cleaning parameters as closely as possible.
However, we are seeing fairly large and systematic differences between the MATLAB AFQ and pyAFQ results:
As an example, I am attaching results for the Arcuate, including a single-subject example illustrating the difference in the number of retained streamlines, as well as the group-level difference in FA between the two pipelines.

I realize that this is not a perfectly controlled comparison, particularly because the preprocessing/registration pipelines differ, and I would not necessarily expect mAFQ and pyAFQ to produce identical results. However, the consistency and magnitude of the differences made us wonder where they might be coming from.
Have you encountered similar differences when comparing mAFQ and pyAFQ? And do you have any recommendations for how we could minimize them, or better isolate their source, so that we can fully understand the implications of transitioning from mAFQ to pyAFQ?
Any advice on which part of the pipeline you would consider the most likely source of these differences would be greatly appreciated.
Thank you very much for your time and help, and have a great weekend!
Best,
Tal Ohevia
All reactions