Skip to content
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

Use length threshold parameter consistently #46

Open
jhlegarreta opened this issue Nov 26, 2019 · 2 comments
Open

Use length threshold parameter consistently #46

jhlegarreta opened this issue Nov 26, 2019 · 2 comments
Assignees

Comments

@jhlegarreta
Copy link

jhlegarreta commented Nov 26, 2019

Description

tract_querier apparently expects tractograms to be devoid of "invalid" streamlines, such as those from an unfiltered tractogram that consist of a single point.

I could filter my tractogram before feeding it to tract_querier, but the tool offers ways to do the filtering itself if I got it right, However, their behavior may offer room for improvement (if I am not missing anything).

Even if the TractographySpatialIndexing class accepts a threshold parameter meaning a length threshold, it looks like this parameter is not taken into account when calling the compute_tract_bounding_boxes method, and in the above situation the following error is displayed:

ValueError: Tracts in the tractography must have at least 2 points
tract #11718 has less than two points. You can use the tract_math tool
to prune short tracts and solve this problem.

from tract_querier/tract_label_indices.py:154

Expected behavior

The error is self-explaining and helpful. However, I would have expected to use the threshold parameter for all methods required by that class.

Actual behavior

The threshold parameter of the TractographySpatialIndexing class is not used for all methods called by that class where the parameter could be useful.

That may also explain an unexpected behavior I experience trying to get the CST from a whole brain tractogram that has "single-point streamlines". Although supposedly I filter these using tract_querier's tract_math tools (see issue #47), and the process goes on until completion, the output tractogram contains streamlines whose endpoints are not in the CST. In fact, it looks like a whole-brain tractogram (less dense than the input, but still). It looks as if the query was not executed correctly, may be due to some assumption in the code broken by the described inconsistency/incomplete filtering.

Steps to Reproduce

Use an input unfiltered tractogram having "single-point streamlines". Although I have created a separate script using tract_querier I'd dare to say that the behavior can be easily reproduced using the tract_querier/scripts/tract_querier script with an appropriate parcellation corresponding to a tractogram that contain "single-point streamlines".

Reproducibility

%100

Versions

master

Environment

Ubuntu 16.04 LTS, Python 3.6.5

nibabel==2.5.1
numpy==1.17.3
scipy==1.3.2
six==1.13.0
tract-querier==0.1

Additional Information

@demianw thanks for this nice tool !

@demianw
Copy link
Owner

demianw commented Dec 8, 2019

This use-case operates under the assumption that any tractography algorithm producing a single-point tract is buggy. A single point usually means that the initial seed was set in a place that it didn't track anything. Usually tractography algorithms have a minimum length parameter which should filter these out.

However, I'll see if I can fix this in the upcoming week such that single-point tracts are automatically ignored with a warning.

@demianw demianw self-assigned this Dec 8, 2019
@jhlegarreta
Copy link
Author

This use-case operates under the assumption that any tractography algorithm producing a single-point tract is buggy. A single point usually means that the initial seed was set in a place that it didn't track anything. Usually tractography algorithms have a minimum length parameter which should filter these out.

That is correct. However, I'd dare to say that there are still methods that allow for that behavior, or may be legacy files that we find around containing such "tracks". That being said, filtering such points with a third-party tool prior to feeding the tractogram to tract_querier allows the tool to run as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants