LoGeR: a reimplementation of long-context geometric reconstruction

A reimplementation, and the notice says so

The first line of the README is the one to read before anything else: this is a reimplementation of LoGeR, and complete code and models will be released upon approval. That framing changes how you should treat the repository. It is not the reference implementation from the paper's authors, it is a third party rebuild, and the original is still pending. The project is titled LoGeR: Long-Context Geometric Reconstruction with Hybrid Memory, with the paper on arXiv under the identifier 2603.03269, a project webpage, and a list of authors including Junyi Zhang, Charles Herrmann, Junhwa Hur, Chen Sun, Ming-Hsuan Yang, Forrester Cole, Trevor Darrell and Deqing Sun. The repository itself is compact, with a ckpts/ directory, a data/ directory, the loger/ package, demo_run.sh, demo_viser.py, an eval/ directory and requirements.txt. The homepage is the LoGeR project page, and the licence is not stated, which for a codebase you might build on is a real consideration.

Long streams, chunked processing, hybrid memory

The method itself is described in one sentence, which is enough to understand the shape of the problem. LoGeR processes long video streams in chunks with a hybrid memory design, and the stated purpose is to improve large-scale geometric reconstruction quality and consistency. The problem with long streams is that any method carrying all context has to keep growing its memory as the sequence extends, so chunking is the obvious structure and the hybrid memory is how the implementation keeps information across chunk boundaries without holding everything. The two claims in the README, quality and consistency, point at two different failure modes. Consistency is about the reconstruction not drifting or contradicting itself between chunks, and quality is about the detail recovered within a chunk, which is where a chunked pipeline usually loses information at the seams. The README does not describe the memory internals, so the implementation details are in the code and in the paper rather than in the documentation here.

The environment is pinned hard, including cmake

Installation is a conda environment with unusually specific pins. The clone and environment creation are given as one block:

git clone https://github.com/junyi42/LoGeR
cd LoGeR
conda create -n loger python=3.11 cmake=3.14.0
conda activate loger
pip install -r requirements.txt

The cmake pin is the detail worth noting, since a build dependency at a fixed patch version usually means a native extension is compiled from source and the exact toolchain matters. The requirements file then fixes the deep learning stack in place, with torch 2.6.0 and torchvision 0.21.0 as the first two entries, followed by numpy 1.26.4, pillow, opencv-python, plyfile, huggingface_hub, safetensors, natsort and einops. The second group is the tooling stack, with gradio and viser for interfaces, trimesh, matplotlib, scipy and roma for geometry and math, and accelerate for training. Pinning torch and numpy exactly rather than with a caret means you are reproducing a known working combination, which is helpful for reproducibility and unhelpful if you need to share a GPU environment with other work.

Two checkpoints, two fixed paths

The model weights are hosted on Hugging Face under the Junyi42 account, and the README is explicit about where they have to end up, because the code looks for these paths rather than searching for them. The layout is ckpts/LoGeR/latest.pt and ckpts/LoGeR_star/latest.pt, and the download commands are given with wget:

wget -O ckpts/LoGeR/latest.pt "https://huggingface.co/Junyi42/LoGeR/resolve/main/LoGeR/latest.pt?download=true"
wget -O ckpts/LoGeR_star/latest.pt "https://huggingface.co/Junyi42/LoGeR/resolve/main/LoGeR_star/latest.pt?download=true"

The existence of two checkpoints, one plain and one with a star suffix, suggests the reimplementation ships more than one variant of the model, and the fact that the repository also contains a ckpts/ directory means the directory structure for them is prepared. Getting this wrong is the most likely first failure, since a missing file at a hardcoded path produces an error that looks like a model problem rather than a setup problem. The README does not document the difference between the two checkpoints, so you will have to look at the loaders in the loger/ package to see which one the demo expects.

The demo and the evaluation are two separate entry points

Running the project is delegated rather than documented in the README. For demo usage the README points at demo_run.sh, so the invocation is a shell script you read rather than a command line you copy, and the repository also carries demo_viser.py, which is the visualisation entry point that pairs with the viser dependency in the requirements file. For evaluation the README points at eval/eval.md, a markdown file that holds the evaluation instructions, which is the right place to look for the data expectations and the metrics. The data/ directory in the repository root is where input sequences are expected. This split is worth internalising, because it means the two workflows, trying the method on your own video and reproducing the paper numbers, are deliberately separated, and the second one is the workflow where the data format, the split and the metric definitions all have to match the paper rather than your own convenience.

Built on Pi3 and LaCT, with borrowed evaluation and visualisation code

The acknowledgments section is unusually informative about the engineering. The code is based on Pi3 and LaCT, the camera pose estimation evaluation script is based on TTT3R and the VBR SLAM benchmark, and the visualisation code is based on Viser from the nerfstudio project. That tells you what you are actually getting. The method, the long-context reconstruction with hybrid memory, is the contribution, and it is layered on top of an existing geometry and pose estimation foundation rather than reimplementing that foundation. The same is true of the evaluation harness, which reuses an established benchmark, and the visualisation, which reuses a viewer that many graphics projects share. For an evaluator this is good news in one sense and a caveat in another: the comparison is against a common harness rather than a bespoke one, but you are relying on other projects' assumptions about data conventions. On the maintenance side, the last push was on 2026-04-27, there are no GitHub releases, and the project states that it will keep changing as the original release proceeds.

Editorial conclusion

Adopt this LoGeR repository if you want to evaluate the long-context geometric reconstruction method on long video sequences now, and you are comfortable with a codebase that declares itself a reimplementation while the original remains unreleased. Do not adopt it as a dependency, since there are no releases, the licence is not stated, and the README promises that complete code and models will be released upon approval, which means this snapshot may change shape. Verify first that the checkpoint paths match what the demo script expects, since the weights must sit at ckpts/LoGeR/latest.pt and ckpts/LoGeR_star/latest.pt, and that your environment can hold the pinned stack of torch 2.6.0 and torchvision 0.21.0 with Python 3.11 before you plan the compute budget for a long sequence.

Frequently asked questions

Official sources

1. Issues
2. Junyi42/LoGeR on GitHub
3. Project website
4. README