qsiprep
qsiprep copied to clipboard
PennLINC
Not sure if PyAFQ is importing MRtrix tractogram
With QSIPrep 0.16.0RC3, I made a 2.5M streamline tractogram with the ACT-HSVS workflow and used that as input to PyAFQ. However, AFQ still produces a tractogram, and it's pretty sparse, around 20,000 streamlines after cleaning. Similarly, the produced tracts are sparse. There are no errors, but also no evidence that PyAFQ is using the dense tractogram I made with MRtrix.
Recon spec below:
{
"name": "pyafq_mrtrix_multishell_msmt_ACT-hsvs_DKI_NODDI",
"space": "T1w",
"atlases": [],
"anatomical": [
"mrtrix_5tt_hsvs"
],
"nodes": [
{
"name": "msmt_csd",
"software": "MRTrix3",
"action": "csd",
"output_suffix": "msmtcsd",
"input": "qsiprep",
"parameters": {
"mtnormalize": true,
"response": {
"algorithm": "dhollander"
},
"fod": {
"algorithm": "msmt_csd",
"max_sh": [
8,
8,
8
]
}
}
},
{
"name": "track_ifod2",
"software": "MRTrix3",
"action": "tractography",
"output_suffix": "ifod2",
"input": "msmt_csd",
"parameters": {
"use_5tt": true,
"method_5tt": "hsvs",
"use_sift2": true,
"tckgen": {
"algorithm": "iFOD2",
"select": 2500000,
"max_length": 200,
"min_length": 4,
"power": 0.33,
"crop_at_gmwmi": true,
"backtrack": true
},
"sift2": {}
}
},
{
"name": "pyAFQ_full",
"software": "pyAFQ",
"action": "pyAFQ_full",
"input": "track_ifod2",
"output_suffix": "PYAFQ_FULL_ET",
"parameters": {
"use_external_tracking": true,
"directions": "prob",
"max_angle": 30.0,
"sphere": "",
"seed_mask": "",
"seed_threshold": 0,
"n_seeds": 1,
"random_seeds": false,
"rng_seed": "",
"stop_mask": "",
"stop_threshold": 0,
"step_size": 0.5,
"min_length": 10,
"max_length": 1000,
"odf_model": "CSD",
"tracker": "local",
"nb_points": false,
"nb_streamlines": false,
"seg_algo": "AFQ",
"reg_algo": "",
"clip_edges": false,
"parallel_segmentation": "{'n_jobs': -1, 'engine': 'joblib', 'backend': 'loky'}",
"progressive": true,
"greater_than": 50,
"rm_small_clusters": 50,
"model_clust_thr": 1.25,
"reduction_thr": 25,
"refine": false,
"pruning_thr": 12,
"b0_threshold": 50,
"prob_threshold": 0,
"roi_dist_tie_break": false,
"dist_to_waypoint": "",
"rng": "",
"return_idx": false,
"presegment_bundle_dict": "",
"presegment_kwargs": "{}",
"filter_by_endpoints": true,
"dist_to_atlas": 4,
"save_intermediates": "",
"n_points": 100,
"clean_rounds": 5,
"distance_threshold": 5,
"length_threshold": 4,
"min_sl": 20,
"stat": "mean",
"min_bval": "",
"max_bval": "",
"filter_b": true,
"robust_tensor_fitting": false,
"csd_response": "",
"csd_sh_order": "",
"csd_lambda_": 1,
"csd_tau": 0.1,
"gtol": 0.01,
"brain_mask_definition": "",
"bundle_info": "",
"reg_template_spec": "mni_T1",
"mapping_definition": "",
"reg_subject_spec": "power_map",
"profile_weights": "gauss",
"scalars": "['dti_fa', 'dti_md']",
"import_tract": "",
"sbv_lims_bundles": "[None, None]",
"volume_opacity_bundles": 0.3,
"n_points_bundles": 40,
"sbv_lims_indiv": "[None, None]",
"volume_opacity_indiv": 0.3,
"n_points_indiv": 40,
"viz_backend_spec": "plotly_no_gif",
"virtual_frame_buffer": false
}
}
]
}
@36000 I have an idea of why this is:
The QSIPrep myafq call is (from the pyafq interface):
myafq = ParticipantAFQ(
dwi_file, bval_file, bvec_file, output_dir,
import_tract=tck_file,
brain_mask_definition=brain_mask_definition,
mapping_definition=itk_map,
**kwargs)
I think the input for import_tract should be a dictionary specifying to look for the trk file in qsirecon outputs, and not the tck_file itself. The problem is that the working directory is not setup like a BIDS directory, so I'm not sure if it would work correctly as is.
What do you think?
PyAFQ docs need to be updated, because it can be a string in the case of participantAFQ . I will debug this further when I get back from OHBM on Monday. Thanks for finding this issue, its not good that it doesn’t throw an error but uses its own tractography. I will add in some checks as well so this doesn’t happen again.
If you look at the trk files in the pyAFQ output directory, is there one with the name "model-XXX_desc-XXX_tractography.trk" ? Or is it just one named "model-XXX_desc-XXX-AFQ_tractography.trk" ?
sub-XXX_space-T1w_desc-preproc_dwi_space-RASMM_model-CSD_desc-prob-AFQ_tractography.trk is the only tractography file made (besides the additional clean version). The size is ~34MB
This means it is using an imported tractography from qsiprep. This means 1 of 2 things is happening: (1) it is somehow using a different or wrong trk produced by qsiprep or (2) pyafq is having trouble for some other reason (could be bug in pyAFQ or data or other wrong imports from qsiprep). I will double check the results on the QSIprep test dataset to make sure everything is working well there. On your end, if you ran export_all you can debug: check mapping: check the file ending in template_xform compared to the b0 and make sure they are well aligned check tractography: load qsiprep tractography into mi-brain and load ROIs from ROIs folder in pyAFQ output to see if the ROIS are well aligned
By the way, thanks for being the guinea pig and helping me debug this. It is nice to see people using this feature.
After double checking the mapping results I think the problem is there. You can see this in your own dataset comparing template_xform to b0. I will let you know when this is fixed. Sorry and thanks for your patience!
Edit: If your mapping looks fine, ie the template_xform and b0 are well-aligned, let me know.
Unfortunately, I was doing the export_all testing in temporary space that got wiped, so I do not have those results on me, but I can try to rerun. Thanks for looking into this!
Hi, I wonder if there is anything update with this issue? In addition, is there any documentation/tips for how to use this pyafq interface within qsiprep? I didn't find description within the qsiprep online documentation (qsiprep.readthedocs.io). Thanks!
I believe this is not an issue anymore. pyAFQ can be run like the other reconstruction pipelines shown here: https://qsiprep.readthedocs.io/en/latest/reconstruction.html . I am going to try to get this issue closed because the initial problem was solved, but if you have anymore questions with qsiprep / pyAFQ you can open another issue and make sure to tag me in it.
I'll close this issue, but I will note that the online readthedocs page for reconstruction does not have the PyAFQ information that is listed in the GitHub docs/reconstruction.rst.