Geodesic Distance (LRW)
How far apart are two latents, really?
- latent_from
- latent_to
- metric
- distance
Ever wondered how "far" two latents are from each other? Euclid would say subtract them and take the norm. Geodesic Distance is here to tell you that's a lie - or at least, that it's only true if latent space is flat, which it isn't. This node walks the actual curved path between two latent points along your decoder's metric and returns the geodesic distance. It's a single FLOAT out, and it's the pack's most honest research-y node: it doesn't change any pixels, it just gives you a number you can use.
Why you'd reach for it
The realistic use case is measuring. Two classic ones: quantifying how far apart a style-transfer source and target really are before you bother transporting a vector between them, and comparing latent distances across seeds or prompts when you're trying to understand why one interpolation is smooth and another blows up. A big geodesic distance between two points is a decent warning that a straight-line interpolation is going to slice through unstable territory. It's also just a fun toy - after you've built a metric with LRW_VAEDecoderBridge or LRW_PullbackMetric, plug two VAEEncode latents in and see how the number changes as you move the second image further from the first.
How it works
Internally it flattens both latents and hands them to lrw.geodesic.GeodesicSolver.geodesic_distance(), which integrates a geodesic along the metric you provided. It averages over the batch and returns a single float.
The inputs:
latent_from,latent_to- two latents, same shape, usually from VAEEncode.metric- aMETRICfrom the VAE Decoder Bridge or Pullback Metric. This is non-negotiable; the node has no metric-free mode.n_steps(default 20) - the integration resolution. More steps = more accurate and slower. If you're just comparing relative distances, leave it alone; if the number seems jumpy between runs, bump it.
Output is one FLOAT named distance. Wire it into a text display node or just watch it in the node output panel.
The WAN connection
If you're doing WAN2.2 First-Last Frame work, don't go hunting for this node's WAN equivalent - the pack already has one: LRW_WanCurvatureGuide computes a normalized latent-distance/curvature stat specifically for WAN latents and even recommends how many keyframes to use. That node is the practical, VRAM-safe version of this idea. This node is the proper image-model one, and it needs the real pullback metric, which WAN can't cheaply provide. Different tools, same instinct.
Install
Search comfyui-lrw-nodes in ComfyUI Manager, or:
cd ComfyUI/custom_nodes
git clone https://github.com/lajjadred/comfyui-lrw-nodes
cd comfyui-lrw-nodes
pip install -r requirements.txt
Restart ComfyUI. The real dependency is latent-riemannian-world >= 0.3.0 plus torch >= 2.4. Early builds had a registration/import bug that showed nodes as broken until a git pull and full restart; only keep one copy of the pack in custom_nodes. License is BSL-1.1.
One honest expectation-setting note: nobody is going to be able to tell you a "good" distance value, because the scale depends entirely on your VAE and latent size. Treat it as a relative signal - smaller than your other pair, bigger than that one - not an absolute truth.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| latent_from | LATENT | — | |
| latent_to | LATENT | — | |
| metric | METRIC | — | |
| n_steps | INT | 205–200 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| distance | FLOAT | — |