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

Resulting points are not ordered #10

Open
truenicoco opened this issue Mar 9, 2021 · 3 comments
Open

Resulting points are not ordered #10

truenicoco opened this issue Mar 9, 2021 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@truenicoco
Copy link

truenicoco commented Mar 9, 2021

First, thanks for sharing your code, it's great.

Now my issue: are SWC points supposed to be ordered? Using my data they definitely aren't, and node_ids do not start at 1. Besides that, results look great so I am wondering what I am doing wrong.

image

This warning: Total face area increased from last iteration. Contraction stopped prematurely after 30 iterations at epsilon 9.6e-06. is displayed during the contraction phase but the contracted mesh looks OK anyway. Any idea?

@schlegelp
Copy link
Collaborator

Now my issue: are SWC points supposed to be ordered? Using my data they definitely aren't, and node_ids do not start at 1.

Correct on both accounts: the SWC format demands ordered node IDs. skeletor does currently not enforce that - although the underlying code would actually already allow that. I need to expose this option but in the meantime see this block in case you want to do the reordering yourself.

Total face area increased from last iteration. Contraction stopped prematurely after 30 iterations at epsilon 9.6e-06.

The mesh contraction has several stop conditions. Most are exposed to the user (e.g. epsilon or iter_lim) but the one you encountered is hardcoded. It basically means that the contraction "overshot" - i.e. the last step actually led to an average expansion instead of a contraction - and the function stops there and returns the result from the last safe round of contraction. That typically happens when the weights are set too high and each iteration applies a huge contraction (higher chance of overshooting). In your case however, the mesh has already been successfully contracted to about 0.1% of the original volume when that happens.

@schlegelp schlegelp added the enhancement New feature or request label Mar 10, 2021
@schlegelp schlegelp self-assigned this Mar 10, 2021
@truenicoco
Copy link
Author

Thanks for your answer. I realized a bit late that the output is branched despite my input being very tubular. I have managed to get the output I want by reconstructing the graph from the swc output (not the graph output directly since I was interested in the postprocessing steps that used swc). I computed the longest paths, reconnected them based on distance and I think my centerlines are now OK. BTW, I had to use this:

    try:
        swc = skeletor.postprocessing.recenter_vertices(swc, mesh, copy=False)
    except ValueError:  # happens when there is no need to recenter vertices
        pass

because recenter_vertices does not gracefully handle the case where no vertex is outside the mesh.

@schlegelp
Copy link
Collaborator

Just a note that with skeleton 1.0.0 nodes IDs in the SWC tables are now correctly ordered.

Also: as part of the next release, recenter_vertices will handle cases where no vertex is outside the mesh.

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

No branches or pull requests

2 participants