-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Substantially Fewer Steamlines and Tracts using v0.11/v0.12 compared to v0.8. #831
Comments
One major change in between those versions is that starting version 0.11 we changed tractography defaults from deterministic DTI to probabilistic CSD. In your case, if you were satisfied with version 0.8 outputs, you could try doing this:
If the version 0.8 outputs also missed some bundles, another tactic is to increase number of seeds or to only seed in the ROI, like so:
this is from the optic radiations (OR) example, because the OR is harder to find: https://yeatmanlab.github.io/pyAFQ/auto_examples/plot_optic_radiations.html#sphx-glr-auto-examples-plot-optic-radiations-py Of course, more seeds is more computationally expensive. Edit: if re-running in the same folder, make sure to delete the .trk / .csv files before re-running so pyAFQ knows to recalc these. |
I took your advice, but I am running into the same problem. Even after changing odf_model=DTI (what I used with v0.8), directions="det", and n_seeds=3, I am still missing many of the tracts I was able to define in the earlier version of pyAFQ. Changing n_seeds will find more traces for the same tracts, but it will not find more tracts. |
Are you able to share the data or derivatives? If so I can debug on my end. If not, I think there are a few things to check. 1. Is the mapping correct? You can see this by seeing if ...template_xform.nii.gz mostly lines up with the dwi file (this is the MNI template transformed into subject space). 2. Are the ROIs in the right place? To check this either look at the individual bundle visualization in viz_bundles (even the bundles without streamlines found will show ROIs) or look at rois in the ROIS folder. |
Or maybe the diffusion directions are flipped
…Sent from my iPhone
________________________________
From: John Kruper ***@***.***>
Sent: Friday, May 13, 2022 11:07:47 AM
To: yeatmanlab/pyAFQ ***@***.***>
Cc: Subscribed ***@***.***>
Subject: Re: [yeatmanlab/pyAFQ] Substantially Fewer Steamlines and Tracts using v0.11/v0.12 compared to v0.8. (Issue #831)
Are you able to share the data or derivatives? If so I can debug on my end. If not, I think there are a few things to check. 1. Is the mapping correct? You can see this by seeing if ...template_xform.nii.gz mostly lines up with the dwi file (this is the MNI template transformed into subject space). 2. Are the ROIs in the right place? To check this either look at the individual bundle visualization in viz_bundles (even the bundles without streamlines found will show ROIs) or look at rois in the ROIS folder.
—
Reply to this email directly, view it on GitHub<#831 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AANRRSWK7OQVTQZ6TWUBICDVJZV4HANCNFSM5VZHMPGQ>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
The template_xform.nii.gz overlays nicely with the preprocessed dwi data file. The preprocessed dwi, bvec, and bval files are available here: |
Is it true that you are using the same dwi files with ParticipantAFQ that GroupAFQ found? Edit: One reason I ask this, is that I would not be surprised if GroupAFQ did not choose the preprocessed DWI file if it saw an un-preprocessed one that ends in _dwi.nii.gz |
Very interesting! |
Let's leave this issue open until we understand this better |
Hey @jdias001 : thanks for reporting this! My understanding is that you have stumbled on some kind of unfortunate interaction between the pydesigner preprocessing and DIPY's tractography (but I am not yet ruling out the possibility that pyAFQ is doing something wonky... I'd say we haven't nailed this down yet). Thanks for sharing those processed files. We'll take a look and see what's going on. If I had to guess, I'd say that something about pydesigner's processing is obscuring the directional information in the data, which prevents tractography from proceeding effectively. In the meanwhile, could you also share the raw data for the same subject/session that you shared the processed data for? |
Here is a link to a Dropbox folder containing the raw and preprocessed files: https://www.dropbox.com/scl/fo/zos9ut5r7u404rdemw8jv/h?dl=0&rlkey=mte5it1t2izzeb27ip3ipbapy |
Great. Thank you! I'll try to diagnose this and get back to you. |
I don't know if this matters at all, but the processed data is RL flipped relative to the preprocessed data. The b-vectors are near-identical. The processed data also looks like it's been smoothed a bit. Here's the first b=0 volume (unprocessed followed by processed): And the subtraction between the images (after flipping back so they're both in the same RL orientation): |
OK. I think that I found the issue. It's probably the RL flip, together with the no flipping of the b-vecs. Here are the tensor ellipsoids from the corpus callosum with the raw data: And with the pydesigner-processed data: As @jyeatman correctly suggested above, the b-vectors in the processed data are oriented in the wrong directions relative to the data, making it impossible to track with these data. (if you're curious how I made these images are created, it's based on this DIPY example: https://dipy.org/documentation/1.5.0/examples_built/reconst_dti/#example-reconst-dti) |
@arokem you are absolutely correct - PyDesigner flips the image into RAS orientation without flipping the b-vecs. We discovered this recently while attempting tractography with PyDesigner outputs. Needless to say, a fix is on the way. |
Awesome! Glad to hear. @jdias001 : I'll go ahead and close this issue, but please feel free to reopen if this does not address all of your concerns. |
The output tractograms I am getting with version 0.12 are very different from those I had in version 0.8. In particular, the number of fibers and tracts identified is substantially less than before and results in very little usable data.
The code I used in v0.8:
The output I get is:
However, using code from v0.12:
(Forgive the additional code for looping individual participant data).
The output I get is:
The visualizations accurately represent the lack of fibers found using v0.12.
It is not obvious to me what parameters may have been changed between versions to cause such a drastic change in the number of fibers tracked. I will note that I ran the stanford_hardi example and replicated the data on the pyAFQ website (AFQ API example).
Some assistance would be greatly appreciated.
The text was updated successfully, but these errors were encountered: