fastcore-rs¶

Fast implementations of the algorithms that navis and nat need most: traversal and geometry on rooted trees (i.e. neuron skeletons), plus NBLAST neuron similarity.

The project is a single Rust core with bindings on top:

The bindings are deliberately generalized: they know nothing about navis or nat themselves, so third-party libraries can use them without those rather heavy dependencies. navis-fastcore only requires numpy.

Install¶

pip install navis-fastcore

install.packages(
  "nat.fastcore",
  repos = c("https://schlegelp.r-universe.dev", "https://cloud.r-project.org")
)

[dependencies]
fastcore = { git = "https://github.com/schlegelp/fastcore-rs" }

What's available where¶

Every capability lives in the Rust core; the bindings differ only in what they surface and how they spell it. — means that surface doesn't expose it directly.

Rooted trees (skeletons)¶

Healing fragmented skeletons¶

Meshes¶

Neuron similarity¶

Match extraction¶

Clustering¶

The other thing you do with a score matrix. All three surfaces produce the same merge tree; what differs is the object it arrives in — a SciPy-compatible (n-1, 4) linkage matrix in Rust and Python, an hclust in R.

Spatial transforms¶

Neither CMTK nor Elastix needs to be installed — see CMTK transforms and Elastix transforms. The two differ in one important respect: outside the region it was fitted on, CMTK fails a point (we return NaN) while Elastix returns it unchanged. Each binding follows its own tool. Elastix additionally gains an inverse, which Elastix itself cannot compute.

Both work the same way: a transform object holds only the parse, and direction is chosen per call (invert=, or the _inv method), so one object serves every direction rather than re-reading the file to walk it the other way.

When there is no registration at all — only matched landmarks — the thin-plate spline and moving least squares transforms take over; see Landmark transforms. Neither materialises the n_points x n_landmarks matrix its reference implementation does, so there is no batch size to tune, and moving least squares becomes usable at landmark counts (~3,400) that would otherwise need tens of GB.

Python only¶

navis_fastcore.wrappers.csgraph provides drop-in replacements for some scipy.sparse.csgraph routines (dijkstra, connected_components) that are faster when your graph happens to be a rooted tree — see Scipy wrappers.

A note on input conventions¶

The three surfaces take the same tree in different shapes:

• Rust is index-based: a parent-index vector in which roots are negative.
• Python takes node_ids and parent_ids arrays with arbitrary IDs and maps them to indices for you.
• R takes a precomputed parents index vector (build one with node_indices) plus separate x/y/z vectors.

So what reads geodesic_matrix(node_ids, parent_ids) in Python reads geodesic_distances(parents, ...) in R, with node_indices called first.