# InVesalius 3: turning CT and MRI slices into surfaces and 3D prints

> InVesalius is a Python desktop application that reconstructs 3D anatomy from a series of 2D DICOM files, with segmentation, editing, measurement, volume rendering and STL export. It runs on Linux, Windows and macOS, but its dependency set is pinned hard and its stable tags stopped in 2022 while nightly builds continue.

**invesalius/invesalius3** — 3D medical imaging reconstruction software

- Repository: https://github.com/invesalius/invesalius3
- Website: https://invesalius.github.io/
- Stars: 811 · Forks: 455
- Language: Python
- License: GPL-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/invesalius-invesalius3

## A desktop tool for CT and MRI slice stacks

InVesalius generates 3D medical imaging reconstructions from a sequence of 2D DICOM files acquired with CT or MRI equipment. That is the entire premise: a scanner produces a stack of slices, and InVesalius turns the stack into geometry you can look at, measure and export.

The application is written in Python and built around wxPython, with VTK doing the 3D work. The entry point is app.py at the top level, and the package itself lives in the invesalius directory. Alongside it sits invesalius_rs, a Rust component, plus an ai directory, a plugins directory and a presets directory.

The audience is mixed and that mix explains the feature list. A radiologist or surgeon wants to isolate a bone or a tumour and print it. An engineer wants the surface mesh for a 3D printing pipeline or for neuronavigation. A teaching lab wants an open tool that runs on a laptop rather than a licensed workstation. The README describes the software as internationalized in English, Portuguese, French, German, Spanish, Catalan, Romanian, Korean, Italian and Czech, and as multi-platform across GNU Linux, Windows and macOS.

It is worth being clear about what this is and is not. It is a desktop application for image reconstruction and visualisation. It is not a clinical diagnostic system, and the README makes no claim about regulatory clearance or about any clinical validation.

## From DICOM import to exported mesh: the pipeline in the README

The feature list in the README reads like a pipeline, and it is worth following in order because each step feeds the next.

Input comes as DICOM, with support for ACR-NEMA versions 1 and 2 and DICOM 3.0 including various encodings of JPEG, both lossless and lossy, and RLE. BMP, PNG, JPEG and TIF files are also supported, which matters when you are working from exported or anonymised images rather than a scanner's native series.

The analysis stage covers the usual 2D manipulations: zoom, pan, rotation and brightness and contrast adjustments. Segmentation then runs on the 2D slices, either with pre-defined threshold ranges according to the tissue of interest or with watershed. Pre-defined ranges are the fast path for bone or contrast filled vessels, and watershed is the tool for structures that touch and cannot be separated by intensity alone.

After segmentation there are edition tools that behave like a paint brush on the slices, a linear and angular measurement tool, and a volume reorientation tool.

The 3D stage creates surfaces, measures the volume of a surface, and offers surface connectivity tools. Surfaces export in binary and ASCII STL, PLY, OBJ, VRML and Inventor formats. Alongside the solid geometry there is high quality volume rendering projection with pre-defined presets and a crop plane, and pictures export as BMP, TIFF, JPG, PostScript and POV-Ray.

The export list is the part with the most obvious downstream use, since STL is what most 3D printing software expects.

## Where the imaging stack comes from: pydicom, gdcm and DICOM servers

The dependency list in pyproject.toml shows how much of the imaging plumbing is handled by established libraries rather than by InVesalius itself. pydicom 2.4.5 handles DICOM parsing, pynetdicom 2.0.2 handles network DICOM communication, and python-gdcm 3.0.24 is the GDCM binding for handling the compressed encodings and the more awkward parts of the format.

The rest of the stack is equally conventional for scientific imaging: numpy 1.26.4, scipy 1.14.0, scikit-image 0.24.0, nibabel 5.2.1 for neuroimaging file formats, h5py 3.11.0, imageio, pillow 10.3.0 and matplotlib 3.9.0. VTK 9.3.0 provides the rendering and the geometry pipeline. lib3mf 2.3.2 is also in the dependency list, pointing at 3MF mesh format handling.

Networked workflow is explicitly part of the picture. The repository contains dcm4chee-compose.yml and orthanc-compose.yml, along with an orthanc.json configuration. dcm4chee and Orthanc are DICOM servers, so the compose files describe running a local imaging archive and pointing InVesalius at it. That is the path for someone who wants to pull studies from a PACS or an institutional archive rather than from a folder of files on disk.

A sample project file, samples/Cranium.inv3, is included, which is the quickest way to see what the application expects to store.

## Getting it running: per platform wikis, a Dockerfile and pinned versions

The README does not carry installation steps itself. It links three wiki pages instead, one each for running InVesalius 3 on Linux, on Mac and on Windows. That is where the platform specific work lives, and on Windows and macOS that work tends to be about native wheels rather than about the application itself.

A Dockerfile is included in the repository, and it is the most explicit recipe available. It builds from ubuntu:20.04, installs a set of system libraries for OpenGL, GTK, GStreamer, image codecs and HDF5, then installs the Python requirements and compiles the extension modules in place.

```dockerfile
FROM ubuntu:20.04

ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update && apt-get install -y locales
```

```dockerfile
WORKDIR /usr/local/app

COPY . .

RUN pip install --upgrade pip

RUN pip install -r requirements.txt

RUN python3 setup.py build_ext --inplace
```

Two details in that file are worth noting. The image is Ubuntu 20.04, which is older than most current distributions, and the build ends by compiling the Cython extensions in place with setup.py build_ext, so a source build needs a compiler toolchain.

The version story is where readers should look carefully. The README badge advertises Python 3.8, while the pyproject.toml file states requires-python = "==3.12.*", so the declared target is a single Python 3.12 patch series. The two statements in the same repository disagree, and the pyproject entry is the one a packaging tool will enforce.

The dependency pins are strict. numpy 1.26.4, scipy 1.14.0, VTK 9.3.0, pillow 10.3.0 and wxpython 4.2.5 are exact versions, and pyproject.toml carries a comment explaining that setuptools is constrained below 68 for wxPython 4.2.2 compatibility because of a copy_file signature issue. Installing InVesalius into an environment you already use for other scientific Python work is therefore likely to mean a separate virtual environment.

## The AI and Rust corners of the tree

Two parts of the repository point at where the project is heading, though the README says little about either.

The ai directory sits next to invesalius and invesalius_rs. The dependency list includes torch>=2.3.1, onnxruntime-gpu 1.23.0 on Windows and Linux, plain onnxruntime on macOS, onnx>=1.17.0 and tinygrad 0.10.2. A machine learning runtime on both training and inference frameworks suggests the segmentation side has learned model support, which is consistent with the segmentation features being the centre of the application. The README does not describe any specific model, its accuracy, or how it would be obtained, so the honest reading is that the machinery for running models is in the dependency tree while the documentation does not yet walk through it.

The Rust component, invesalius_rs, is a separate top level directory. The development dependency group includes maturin>=1.0,<2.0, which is the build tool for Rust based Python extensions, so the Rust code is compiled and bound as a native extension rather than called across a process boundary. That arrangement fits the workload: the performance sensitive parts of volume and surface processing sit in compiled code, while the interface and orchestration stay in Python.

Neither of these is something you need in order to run the application, and neither is documented in the README beyond the directory names and the dependency list.

## Where InVesalius is the wrong tool

The obvious alternative is to skip the application entirely and script the reconstruction with the same libraries InVesalius itself uses: pydicom to read the series, scikit-image and scipy for filtering and thresholding, and VTK to build surfaces and render them. The difference in approach is where the intelligence lives.

A script puts the segmentation decisions in code you write and read. You control every step, you can make the pipeline reproducible, and it drops straight into an automated pipeline. What you give up is the interactive part, and that is substantial here: the paint brush style edition tools on 2D slices, the interactive watershed, the pre-defined threshold ranges per tissue, the linear and angular measurement tool, the volume reorientation tool, the volume rendering presets and the crop plane. Recovering that interactivity in a script is the bulk of the work InVesalius has already done.

On the other hand, InVesalius is the wrong choice when reproducibility matters more than exploration, because the segmentation is the result of manual edits that live in a project file rather than in a script. The .inv3 sample in the repository is the format for that state.

It is also the wrong choice for anyone who needs a published, dated release to build against. The release list contains a nightly build dated 2026-10-20, then v3.1.99998 from 2022-04-14 and v3.1.99997 from 2022-02-02. The version numbers themselves, a patch count in the tens of thousands, suggest the nightly line is used for real work and that the numbered tags are historical markers rather than a support channel. If your institution needs a versioned artifact with a change log, changelog.md is in the repository and the AUTHORS.md file records contributors.

## Licence, localisation and the shape of the project

InVesalius is distributed under GPL-2.0, with the licence text in LICENSE.txt and a separate LICENSE.pt.txt in the repository. Modifying and redistributing the software carries the GPL obligations, and if you embed it in a larger system or distribute a build, those terms travel with it. That is a licensing fact to check against your own plans, not advice.

The internationalisation is real rather than aspirational. A locale directory and a po directory hold the translation catalogues, and the README lists ten languages, which includes several that are rarely seen in imaging software. The packaged builds are therefore expected to be localised rather than English only.

The repository also carries the usual project furniture: a tests directory with pytest 8.3.5 and pytest-mock configured, a .pre-commit-config.yaml, a pyproject.toml with ruff for linting and mypy for typing in the development group, a uv.lock for reproducible environment resolution, an environment.yml for conda users, and an optional-requirements.txt for packages that are not needed in every install. The .gitmodules file means some components are pulled in as submodules, which matters if you clone with a tool that does not fetch them.

The homepage for the project is invesalius.github.io, and the three per platform wiki pages are the only installation documentation the README points to. Anyone evaluating this should budget for reading those pages rather than expecting a single command to produce a working install.

## Conclusion

InVesalius 3 suits a clinician, engineer or teaching lab that needs to turn a CT or MRI series into a printable surface or a 3D rendered volume on a desktop, and it earns its place for people who want threshold and watershed segmentation with 2D editing instead of a custom script. Do not pick it if you need a maintained release channel with tagged versions, because the last tagged builds in the release list are from 2022 and only nightly builds are dated 2026, or if you cannot meet its pinned native dependencies. Before installing, read the wiki page for your platform, confirm your Python version matches the requires-python entry in pyproject.toml rather than the badge in the README, and check the pinned versions of vtk, pydicom and wxpython against your existing environment.

## FAQ

### What does InVesalius do with CT and MRI data?

It generates 3D medical imaging reconstructions from a sequence of 2D DICOM files acquired with CT or MRI equipment. The pipeline covers DICOM import, 2D analysis, segmentation by threshold range or watershed, 2D edition tools, measurement, 3D surface creation and volume rendering.

### Which platforms and Python versions does InVesalius 3 support?

The README describes it as multi-platform across GNU Linux, Windows and macOS and links a wiki page for each platform. The README badge advertises Python 3.8, while pyproject.toml declares requires-python = "==3.12.*", so the two statements in the repository disagree.

### What file formats can InVesalius export?

3D surfaces export as binary and ASCII STL, PLY, OBJ, VRML and Inventor, and pictures export as BMP, TIFF, JPG, PostScript and POV-Ray. The dependency list includes lib3mf, which relates to the 3MF mesh format.

### How does InVesalius read DICOM studies from a server?

The repository includes dcm4chee-compose.yml and orthanc-compose.yml along with an orthanc.json configuration, which describe running a local DICOM archive, and the dependency list includes pynetdicom for network DICOM communication alongside pydicom and python-gdcm.

### Is InVesalius still being maintained?

The repository is not archived and the last push was on 2026-10-22, with a nightly build on the same date. The most recent numbered tags in the release list are v3.1.99998 from 2022-04-14 and v3.1.99997 from 2022-02-02, so the numbered versions are older than the nightly line.

## Sources

- [invesalius/invesalius3 on GitHub](https://github.com/invesalius/invesalius3)
- [License: GPL-2.0](https://github.com/invesalius/invesalius3/blob/master/LICENSE)
- [Project website](https://invesalius.github.io/)
- [README](https://github.com/invesalius/invesalius3/blob/master/README.md)
- [Releases](https://github.com/invesalius/invesalius3/releases)

---

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