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

Feature suggestion: skeletonization of output segmentation #26

Open
LorenzLamm opened this issue Jul 26, 2023 · 3 comments
Open

Feature suggestion: skeletonization of output segmentation #26

LorenzLamm opened this issue Jul 26, 2023 · 3 comments

Comments

@LorenzLamm
Copy link
Collaborator

As discussed in #24 , it might be nice to have an option (or even the default?) to output skeletonized outputs of the membrane segmentations instead of voxel-wise segmentations.

These skeletons would allow for membrane analysis regardless of their thickness, and also allow the user to control the membrane thickness by "growing" them using image dilation.

skeletonization_snap
@alisterburt
Copy link
Member

for my own clarity, the skeletonised output is still a voxel-grid, right? just it has a maximum possible thickness?

@LorenzLamm
Copy link
Collaborator Author

Yes, correct. It's still on a voxel grid and should get as thin as possible while still maintaining the connectivity of the original segmentation.

@rdrighetto
Copy link
Contributor

I just became aware of this feature request, as Wojciech in our lab just suggested the same thing. After reading the discussion in #24, I think it would be totally awesome to have the skeletonization (and further regrowing to an arbitrary thickness) as an option.
However, I would not make this the default behavior. A skeletonized segmentation is not directly related to the experimental data anymore, so I think the input/output causality becomes more difficult for users to understand. Also, often growing all membranes to the same thickness is not what you want, since varying thickness does happen in real data, can depend on the viewing direction, etc.
Still, I know it can be useful in many scenarios for analysis, and for more standardized performance comparison. So I suggest having this feature as an optional postprocessing operation.

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