Skeleton & spur operations

The path is determined by which graph property you're after:

Need the skeleton itself: Skeleton.

Need just the pixels where lines meet: Skeleton — branch points.

Need just the pixels where lines terminate: Skeleton — end points.

Want to remove short noise branches: Skeleton — remove spurs (length threshold).

Want to remove branches that go in a specific direction: Skeleton — remove spurs (by angle).

Want to trim spurs without removing them entirely: Skeleton — shorten spurs.

Want to extend short branches that almost-but-not-quite reach an intersection: Skeleton — extend spurs.

Want each branch as its own measurable object: Skeleton — split.

Most workflows chain several of these: skeleton, then remove short spurs, then split for per-segment measurement.

The skeleton is the right representation when shape topology matters more than shape geometry. For neuronal processes, the relevant questions are total length, branching density, end-point count — all topological. The skeleton answers these directly. The original mask answers them through measurements that have to disentangle line-thickness from line-length, which is harder.

For blob-like objects (cells, nuclei) the skeleton usually doesn't help — the topology is just "this is a blob," and the labeled maskLoading... is the better representation. The skeleton earns its place specifically for line-shaped, branched, or fiber-shaped structures where the centerline carries more information than the area.