# InfiniDepth: arbitrary-resolution monocular depth that also exports 3D Gaussians

> InfiniDepth is a CVPR 2026 paper released as code and checkpoints, and the interesting thing about it is that one model serves three jobs: relative depth from a single image, novel-view 3D Gaussian splatting from that same image, and metric depth when a depth sensor is also available. The project is a research release with training code, a Gradio demo and a Hugging Face Space, not a packaged library.

**zju3dv/InfiniDepth** — [CVPR 2026] InfiniDepth: Arbitrary-Resolution and Fine-Grained Depth Estimation with Neural Implicit Fields

- Repository: https://github.com/zju3dv/InfiniDepth
- Website: https://zju3dv.github.io/InfiniDepth/
- Stars: 1,096 · Forks: 46
- Language: Python
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/zju3dv-infinidepth

## Three capabilities from one model family

InfiniDepth is described as arbitrary-resolution and fine-grained depth estimation with neural implicit fields, and it was accepted to CVPR 2026. The homepage is the project page, the paper is on arXiv, and there is a Hugging Face Space demo, a Hugging Face dataset, and a WeChat contact in the header.

The useful thing about the project is the table of what it can do, because it is not one task but three, and they share a backbone.

Monocular and arbitrary-resolution depth estimation takes an RGB image and produces an arbitrary-resolution depth map. Monocular view synthesis takes an RGB image and produces 3D Gaussian Splatting, a 3DGS representation. And depth sensor augmentation, described as monocular metric depth estimation, takes an RGB image plus a depth sensor and produces metric depth plus 3D Gaussian Splatting.

The third row is the one that distinguishes this from a plain monocular depth model. A monocular model can only guess at scale, because a single image does not tell you how big anything is. Give it a depth sensor reading and the scale becomes recoverable, which turns relative depth into metric depth, and that is a meaningful difference when the output is going into a 3D Gaussian export, because the Gaussians are placed in world coordinates.

So the design is one depth backbone with two heads and two modes. The relative case needs only the RGB image, and the metric case adds the sensor.

The authors are a large group from the ZJU3DV lab and collaborators, with Hao Yu, Haotong Lin, Jiawei Wang, Jiaxin Li, Yida Wang, Xueyang Zhang, Yue Wang, Xiaowei Zhou, Ruizhen Hu and Sida Peng named, and the primary language in the repository metadata is Python. The licence is a custom one that GitHub could not classify, with the terms in a LICENSE file, so for a research release with model weights that is worth checking before you use it commercially. The repository is not archived, and the last push was on 2026-09-15.

There is exactly one release tag, v1.0.0 on 2026-03-24, titled as the official release of the code and models, which tells you the versioning here is a paper release rather than a maintained package line.

## The release timeline, and what is actually in the repository

The News section is a dated sequence of three entries, and it explains the state of the code better than any readme paragraph would.

In February 2026 InfiniDepth was accepted to CVPR 2026, with code coming soon. In March 2026 the inference code became available, covering both the RGB only and the depth sensor augmentation variants. And in April 2026 the training and evaluation code became available, again for both variants.

So the order was paper, then inference, then training. That is the shape of a research release, and it is worth knowing because the inference code is what almost everyone needs and it was the second thing out.

The repository listing shows the structure that follows from that. There are inference_depth.py, inference_gs.py and inference_multi_view_depth.py as separate entry points for the three capabilities, plus main.py and app.py. The InfiniDepth/ directory holds the model code, training/ holds the training code, and example_scripts/ holds the runnable examples. There is INSTALL.md for manual installation and DATA.md for the datasets, and a launch_scripts/ directory. example_data/ has the sample inputs and outputs, and example_huggingface/ is there for the Space.

The two documentation files are the first things to read and the README does not summarise either of them. INSTALL.md is what you need before anything runs, because the environment for a project like this is not a pip install line. DATA.md tells you where the training and evaluation data comes from, and the presence of a Hugging Face dataset link in the header, a game_4k_data set, is the pointer to at least one of the sources.

The requirements.txt is unusually long and unusually well commented, and reading it tells you the shape of the project better than the feature table does. It is grouped by purpose, with comments as section headers: PyTorch and related packages, Transformers and AI models, data processing and scientific computing, computer vision and graphics, 3D, metrics and evaluation, training frameworks, logging and monitoring, utilities, a simple skymask entry with onnxruntime, and then the application layer with gradio, huggingface_hub, plotly, spaces and trimesh.

Two details in there are worth calling out. The PyTorch section is entirely commented out, with an extra index URL pointing at the cu128 wheel channel, which means the torch install is left to you and presumably needs a specific CUDA build. And the Waymo dataset section pins protobuf==3.20.2, which is a hard pin on an old protobuf, presumably because the Waymo open dataset reader expects it, and it notes an optional local dependency to install manually for Waymo parsing.

## The inference interface, and the three example scripts per task

The quick command index is the most practical part of the documentation, and it maps five goals to five shell scripts.

For relative depth from a single RGB image, the recommended command is bash example_scripts/infer_depth/courtyard_infinidepth.sh. For 3D Gaussian from a single RGB image it is bash example_scripts/infer_gs/courtyard_infinidepth_gs.sh. For metric depth from an RGB image plus a depth sensor it is bash example_scripts/infer_depth/eth3d_infinidepth_depthsensor.sh, and for 3D Gaussian from an RGB image plus a depth sensor it is bash example_scripts/infer_gs/eth3d_infinidepth_depthsensor_gs.sh. There is a fifth for multi-view and video depth with a global point cloud, bash example_scripts/infer_depth/waymo_multi_view_infinidepth.sh.

The scripts are wrappers around the Python entry points with the arguments already set, and the README shows the underlying command for the first one:

```bash
python inference_depth.py \
  --input_image_path=example_data/image/courtyard.jpg \
  --model_type=InfiniDepth \
  --depth_model_path=checkpoints/depth/infinidepth.ckpt \
  --output_resolution_mode=upsample \
  --upsample_ratio=2
```

The options table for that script is where the arbitrary-resolution claim becomes concrete. --output_resolution_mode chooses upsample, original or specific. --upsample_ratio is used when the mode is upsample, and --output_size takes an explicit H,W pair when the mode is specific. So the output resolution is a parameter rather than a property of the model, and the default behaviour of the example is to double the input resolution.

The camera intrinsics options are worth noting because they matter for the point cloud export. --fx_org, --fy_org, --cx_org and --cy_org take the camera intrinsics in the original image resolution. Without the right intrinsics, a depth map is still a depth map but the point cloud it produces will be in the wrong shape.

And --save_pcd controls whether a point cloud is exported alongside the depth map. The outputs go to example_data/pred_depth/ for the colorized depth map and example_data/pred_pcd/ for the exported point cloud.

The 3D Gaussian script adds its own checkpoint and writes different outputs:

```bash
python inference_gs.py \
  --input_image_path=example_data/image/courtyard.jpg \
  --model_type=InfiniDepth \
  --depth_model_path=checkpoints/depth/infinidepth.ckpt \
  --gs_model_path=checkpoints/gs/infinidepth_gs.ckpt
```

which produces example_data/pred_gs/InfiniDepth_courtyard_gaussians.ply and example_data/pred_gs/InfiniDepth_courtyard_novel_orbit.mp4, the latter being the novel-view video. If --render_size is omitted, the novel-view video is rendered at the original input image resolution, which is another place the arbitrary-resolution design shows up: the video is not locked to some fixed output size either.

## The checkpoints, and why the depth model alone is not enough

The checkpoint list for each task is where the system design is exposed, and it is more interesting than it first looks.

For relative depth from a single RGB image, there are two required checkpoints. The first is checkpoints/depth/infinidepth.ckpt, the depth model itself. The second is checkpoints/moge-2-vitl-normal/model.pt, and the README's comment is that it recovers metric scale for point cloud export.

That second requirement is the key to understanding the whole thing. A monocular depth network predicts relative depth, the ordering of surfaces, not their distance. The model gives you a depth map whose scale is arbitrary. To place points in 3D you need to know the scale, and the second checkpoint is a separate scale-recovery model that supplies it.

So the relative depth output and the point cloud output are not the same product, even though they come from the same run. The depth map is relative. The point cloud is metric, because the scale checkpoint was applied. And that also explains the third capability: if you already have a depth sensor, you have the scale directly, which is what depth sensor augmentation is for.

The 3D Gaussian task has the same pair plus one more. It needs the depth checkpoint, the Gaussian checkpoint at checkpoints/gs/infinidepth_gs.ckpt, and the same metric-scale checkpoint, again with the comment that it recovers metric scale for the 3D Gaussian export. The consistent presence of the MoGe-2 checkpoint in both tasks that produce 3D output is the pattern.

And there is an optional checkpoint, checkpoints/sky/skyseg.onnx, for additional sky filtering, and it is described as optional in both cases. The onnxruntime dependency in requirements.txt is the runtime for that model, and the comment groups it under a simple skymask heading.

Sky filtering is a real requirement for depth estimation rather than a refinement, and the reason is that the sky is unbounded. A depth network asked to estimate the distance to the sky has to invent a number, and a wrong invented number becomes a large flat artefact in the depth map, which then becomes a large flat artefact in the point cloud. So the sky has to be excluded or masked, and this project does that with a separate segmentation model rather than hoping the depth network handles it.

The demo section confirms the same structure in a user interface. The Gradio Space entrypoint at app.py takes an RGB image as required input and a depth map as optional, has a task switch for Depth or 3DGS, and a model switch for InfiniDepth or InfiniDepth_DepthSensor. The note is that InfiniDepth_DepthSensor requires a depth map input and RGB-only inference should use InfiniDepth, and the supported depth upload formats are .png, .npy, .npz, .h5, .hdf5 and .exr. You can run it locally with python app.py, or use the hosted Hugging Face Space first to see whether the results are worth setting up locally.

## Conclusion

InfiniDepth fits a computer vision researcher or a graphics engineer who needs depth from a single image at whatever resolution the image happens to be, and who wants a 3D Gaussian export rather than only a depth map, and who is comfortable setting up a research environment with model checkpoints. It is the wrong tool if you want a stable library with a versioned API, since the repository is a paper release with a single v1.0.0 tag, and it is the wrong choice if you need to train at scale without reading the training code first. Before using it, read INSTALL.md and DATA.md, download the checkpoints named in the README rather than assuming a single model covers all three tasks, and note that the point cloud and 3D Gaussian exports both need the separate metric-scale checkpoint rather than the depth checkpoint alone.

## FAQ

### What can InfiniDepth do with a single image?

It supports monocular and arbitrary-resolution depth estimation producing an arbitrary-resolution depth map, and monocular view synthesis producing 3D Gaussian Splatting, both from a single RGB image. With a depth sensor as well, it produces metric depth plus 3D Gaussian Splatting.

### How do I run InfiniDepth depth inference locally?

Use the script bash example_scripts/infer_depth/courtyard_infinidepth.sh, or call python inference_depth.py with --input_image_path, --model_type, --depth_model_path and an --output_resolution_mode of upsample, original or specific. The README refers to INSTALL.md for manual installation.

### Which checkpoints does InfiniDepth need for a point cloud export?

The depth checkpoint at checkpoints/depth/infinidepth.ckpt plus checkpoints/moge-2-vitl-normal/model.pt, which recovers metric scale for the point cloud export. The 3D Gaussian task additionally needs checkpoints/gs/infinidepth_gs.ckpt, and checkpoints/sky/skyseg.onnx is an optional checkpoint for additional sky filtering.

### Is there a hosted demo of InfiniDepth?

Yes, there is a Hugging Face Space, and the repository also includes a Gradio Space entrypoint at app.py which you can run locally with python app.py. The demo takes an RGB image as required input and a depth map as optional, with switches for the Depth and 3DGS tasks and for the InfiniDepth and InfiniDepth_DepthSensor models.

## Sources

- [Issues](https://github.com/zju3dv/InfiniDepth/issues)
- [Project website](https://zju3dv.github.io/InfiniDepth/)
- [README](https://github.com/zju3dv/InfiniDepth/blob/main/README.md)
- [Releases](https://github.com/zju3dv/InfiniDepth/releases)
- [zju3dv/InfiniDepth on GitHub](https://github.com/zju3dv/InfiniDepth)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zju3dv-infinidepth