SceneRF: single-image 3D reconstruction trained without depth labels

The labelling problem SceneRF is built around

Supervised monocular 3D reconstruction needs ground-truth depth or geometry to compare against. For outdoor driving scenes that means LiDAR sweeps or voxel annotations, and both are expensive to collect and to keep aligned with camera frames. SceneRF's stated contribution, per the repository title and the ICCV 2023 venue, is to train without that supervision: the method is described as self-supervised monocular 3D scene reconstruction with radiance fields. The target reader is a researcher who has camera sequences and wants geometry out of them, not a team shipping a perception feature. The README addresses exactly that reader. It documents dataset preparation for KITTI and Bundlefusion, a training entry point per dataset, and separate evaluation procedures for novel depth synthesis, novel view synthesis and scene reconstruction. It does not document an inference API, a model zoo, or a deployment path. The absence of those sections is informative: this is code released so that a paper's numbers can be reproduced and extended.

What the training scripts and flags tell you about the pipeline

The mechanism is visible in the command line rather than in prose. The KITTI training script is invoked as scenerf/scripts/train_kitti.py and takes --n_gaussians=4 and --n_pts_per_gaussian=8. Those two flags describe a primitive-based scene representation: the radiance field is not a single dense MLP query but a set of Gaussians, each carrying a fixed number of sample points. The Bundlefusion script, scenerf/scripts/train_bundlefusion.py, exposes a different set of knobs, --n_rays=2048 and --lr=2e-5, so ray sampling and learning rate are tuned per dataset instead of shared. Both scripts take --bs, --n_gpus, --enable_log, --root, --logdir and --max_epochs, and the KITTI invocation adds --exp_prefix. Data locations arrive through environment variables rather than config files: KITTI_PREPROCESS, KITTI_ROOT and KITTI_LOG for KITTI, BF_ROOT and BF_LOG for Bundlefusion. That is the whole configuration surface shown in the README. Anyone expecting a YAML config tree with documented defaults will not find one here, and the flags above are the only ones the material confirms.

Installation is a pinned 2021 stack, not a current one

The conda path is explicit about versions. The environment is created with python=3.7, and PyTorch is installed as pytorch==1.7.1, torchvision==0.8.2, torchaudio==0.7.2 and cudatoolkit=10.2 from the pytorch channel. The README states the code was implemented with Python 3.7, PyTorch 1.7.1 and CUDA 10.2. After pip install -r requirements.txt there are two steps that exist because the dependency graph does not resolve cleanly on its own: conda install -c bioconda tbb=2020.2, and pip install torchmetrics==0.6.0 described as a downgrade. The package is then installed in editable mode with pip install -e ./ from inside scenerf/. A Dockerfile is provided instead: docker build -t scene-rf . followed by docker run -it scene-rf, with the README noting that -rm deletes the container afterwards and --gpus all exposes GPUs. Two of those install steps come from outside the PyTorch ecosystem, one from bioconda, and the torchmetrics pin is a downgrade rather than a constraint. Treat the conda recipe as a snapshot to be reproduced, not a dependency set to be modernised casually.

Dataset volume is the real entry cost

Before any training run, KITTI requires four downloads from the odometry site: calibration files, the colour archive listed at 65 GB, ground truth poses, and Velodyne laser data at 80 GB. Scene reconstruction evaluation adds a separate set from SemanticKITTI: the voxel data at 700 MB and all extracted data for the training set at 3.3 GB. The README then asks you to create a preprocess folder, export KITTI_PREPROCESS and KITTI_ROOT, and run training with --preprocess_root=$KITTI_PREPROCESS --root=$KITTI_ROOT --logdir=$KITTI_LOG. So there is a preprocessing stage between download and training whose internals are not described in the material available here. The Bundlefusion route is lighter: eight scenes from the Bundlefusion site, unzipped to a directory you choose, with BF_ROOT exported and the path example given as /gpfsdswork/dataset/bundlefusion. If you want to judge whether the method works before committing roughly 145 GB of KITTI archives to disk, Bundlefusion is the cheaper first contact.

Four V100-32G GPUs is the documented training budget

The README specifies training with 4 v100-32g GPUs at batch_size of 4, one item per GPU, and the KITTI command sets --max_epochs=50. That is a hard resource statement, not a suggestion. A single 24 GB consumer card cannot run the documented configuration, and nothing in the material describes gradient accumulation, a reduced-batch recipe, or a single-GPU variant. Memory is not the only cost: the KITTI route needs the 65 GB colour archive and the 80 GB Velodyne archive resident or staged, plus a preprocess folder, plus a log directory. The scripts take --n_gpus, so the flag exists, but the only configuration the README endorses is the four-GPU one. If your cluster queue is measured in single-GPU allocations, budget for the fact that you are adapting the recipe rather than following it, and expect the effective batch size to change the optimisation behaviour in ways the repository does not document.

Evaluation is split by task, and the pretrained path is the shortcut

The evaluation section is organised around three distinct outputs rather than one metric: novel depths synthesis, novel views synthesis, and scene reconstruction, each with a KITTI subsection and a Bundlefusion subsection, plus a pretrained model entry per dataset and a separate mesh extraction and visualization section. That structure matters for anyone deciding how to spend time. Running a pretrained model against the documented metrics is a far smaller commitment than the 50-epoch, four-GPU training run, and it is the only way to confirm your environment is correct before you invest in training. The mesh extraction and visualization instructions were added in a March 2022 news entry, which suggests they were a later addition to the release rather than part of the original evaluation harness. The material does not list the pretrained weights' licence or hosting terms, so treat that as something to check at the source before you build anything on top of them.

Where SceneRF is the wrong tool, and what to use instead

SceneRF is the wrong tool for online inference. It reconstructs a scene from a single image through a radiance field, and the training and evaluation scripts are built around offline runs on multi-GPU nodes with large dataset trees mounted. There is no documented export path to a mobile or embedded runtime, and no documented latency figure. A team that needs depth per frame on a vehicle should be looking at a supervised or self-supervised monocular depth network with a single forward pass and a known export route to ONNX or TensorRT, not at a radiance-field reconstruction pipeline. The difference in approach is the point: a depth network regresses a depth map directly from an image, whereas SceneRF fits a volumetric scene representation that is then queried for depths, views and meshes. That indirection is what buys the multi-task evaluation in the README, and it is also what makes the four-V100 requirement and the dataset volume reasonable for the method's intended use. If your output is a mesh or a novel view, the indirection pays. If your output is a depth buffer at frame rate, it does not.

Maintenance status and what the licence does not cover

The repository is not archived, the default branch is main, and the last push recorded is 2026-03-25, which in this case is a news entry pointing at a later paper, OccAny, from the same group rather than a code change. The only release is 1.0, dated 2023-08-25, and the README's own news list shows the Bundlefusion code arriving on 24/08/2023 and the ICCV acceptance on 14/07/2023. Read that as a research artifact that is kept visible and occasionally annotated, not a library with a release cadence. The licence is Apache-2.0, which is permissive for the code in this repository. It does not extend to the KITTI Odometry, SemanticKITTI or Bundlefusion datasets, which carry their own terms set by their publishers, and the material here does not state the terms attached to the pretrained models the evaluation section references. The practical maintenance cost is the pinned stack: Python 3.7 reached end of life, and the torchmetrics downgrade and the bioconda tbb pin mean a fresh environment is likely to need the exact commands in the README rather than a resolver's judgement.

Editorial conclusion

Adopt SceneRF if you are reproducing or extending the ICCV 2023 method and can supply the KITTI Odometry colour and Velodyne archives plus the SemanticKITTI voxel and training-set extractions, or the eight Bundlefusion scenes, and can schedule four V100-32G GPUs for the 50-epoch KITTI run. Do not adopt it as a product dependency: Python 3.7, PyTorch 1.7.1, CUDA 10.2 and the torchmetrics==0.6.0 downgrade are not a stack you want in a service, and the Apache-2.0 grant covers Inria's code only, not the datasets or any pretrained weights the README links. Verify first that your GPU memory matches the documented batch of 4 with one item per GPU, that you can reproduce a pretrained-model number from the evaluation section, and that your use of KITTI and SemanticKITTI fits their own terms, since nothing in this repository grants you those rights.

Official sources

1. astra-vision/SceneRF on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases