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

Local bifurcation angle computation fails when a section has only one point #1078

Open
ssssarah opened this issue Aug 11, 2023 · 6 comments
Open

Comments

@ssssarah
Copy link

https://github.com/BlueBrain/NeuroM/blob/master/neurom/features/bifurcation.py#L57

For the following bifurcation point:

bif_point [Section(id=30, type=2, n_points=1)<parent: Section(id=29), nchildren: 0>, Section(id=31, type=2, n_points=1)<parent: Section(id=29), nchildren: 2>]

local_bifurcation_angle fails because there is only one point.

See .swc file from https://bbp.epfl.ch/nexus/web/bbp/mouselight/resources/https%3A%2F%2Fbbp.epfl.ch%2Fneurosciencegraph%2Fdata%2Fneuronmorphologies%2F1661d3d0-87b3-4978-89f6-99a601b1b706

@crisely09
Copy link

crisely09 commented Aug 11, 2023

Apart from the code to account for sections with one single point, @lidakanari we would also like to know if having only one point in the section after bifurcation is "acceptable" in a morphology, in terms of quality of the recostruction.
Thank you.

@adrien-berchet
Copy link
Member

Hello,
Did you run MCAR on this morphology (at least the Curate workflow) before running NeuroM on it?
As far as I know, sections with only one point are not valid since a section must contain at least one segment and a segment is defined by two points (see https://morphio.readthedocs.io/en/latest/specification.html#segment).

@crisely09
Copy link

Hi @adrien-berchet ,
Thank you for your answer, that is what I was fearing, that the morphologies may have "issues" as they come from external databases.
We will run the MCAR on them, thanks for the documentation.

@adrien-berchet
Copy link
Member

You're welcome.
And basically you should consider that all morphologies should go through MCAR before being imported (except if you explicitly want to keep the original version with its potential errors).

I let you close this issue if you don't have any other question.

@crisely09
Copy link

@adrien-berchet maybe the function should catch this error and inform the user that the morphology is not correct?
If you think this is reasonable that would be a nice thing to have, if not, we can close the ticket.

@adrien-berchet
Copy link
Member

I think all functions should be able to consider that the morphology is valid. Nevertheless, we may add a general try/except block to give some hints to the user when the computation fails (usually because of an invalid morphology).

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

No branches or pull requests

3 participants