3D Slicer: a desktop platform for medical image computing built on VTK and ITK

A short README in front of a very large repository

The README does very little, and it is worth reading what it actually says before assuming more. It identifies Slicer, also called 3D Slicer, as a free open source software package for visualization and image analysis, and states that it is natively designed to be available on multiple platforms including Windows, Linux and macOS. Then it points at slicer.org for documentation and tutorials, and at discourse.slicer.org for community announcements and support, and it refers you to `License.txt` for the terms covering use and contributing.

The badges are more informative than the prose. There is a citation badge with a DOI pointing at a 2012 journal article in Medical Image Analysis, which tells you this is a citable piece of research software rather than a script. A Semantic Scholar badge counts citations on that same DOI. The CI badge points at a build workflow and an OpenSSF Scorecard badge is present, so the project is scored on supply chain security practices.

GitHub records 2,636 stars, 787 forks and 638 open issues, and the last push was on 2026-09-24. The repository language is C++.

Reading the topic list as a capability map

The repository topics are the most compact statement of what the software is for, and they group into three layers.

The application layer is `3d-slicer`, `c-plus-plus`, `qt` and `python`, which describes a Qt desktop application with Python scripting. The visualisation layer is `vtk`, `itk` and `kitware`, the two libraries the project is built on and the company that maintains them. The clinical and research layer is where the topic list gets specific: `medical-imaging`, `medical-image-computing`, `computed-tomography`, `image-guided-therapy`, `segmentation`, `registration`, `tractography`, `neuroimaging`, `3d-printing`, plus `nih` and `national-institutes-of-health`, and `tcia-dac` for the imaging archive.

Two of those deserve a note. `image-guided-therapy` and `3d-printing` are the two directions where Slicer is used outside pure analysis, and the README's carousel images point the same way with a COVID lung CT analyzer, a lumpectomy case and an NVIDIA AI segmentation example. `tcia-dac` links the software to the TCIA imaging archive, which is how a lot of published work gets its data.

What the file tree says about the architecture

The tree is the most useful part of the repository for understanding the design:

Applications/
Base/
CMake/
Docs/
Extensions/
Libs/
Modules/
Resources/
Schemas/
SuperBuild/
Testing/
Utilities/

Four directories carry the argument. `Base/` holds the application framework: startup, scene management, module discovery. `Modules/` is the set of built-in capabilities compiled into the binary. `Extensions/` is where separately distributed add-ons live. `Libs/` is the vendored and wrapped third-party code.

The build machinery is unusual and worth understanding before you try to build anything. There is a `CMakeLists.txt`, a `CMake/` directory and a `SuperBuild.cmake` at the root alongside a `SuperBuild/` directory. That is a two-stage superbuild: the outer CMake project fetches and builds dependencies such as VTK and ITK, then builds Slicer against them. It is why the repository has both `.pre-commit-config.yaml` and `.ruff.toml` in the root, since Python tooling runs on parts of the tree even though the application is C++.

`Testing/` with `CTestConfig.cmake` is where the test suite lives, and `Docs/` with `requirements-docs.txt` and `.readthedocs.yaml` is where the documentation is built. The governance files are present too, with `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `GOVERNANCE.md` and `SECURITY.md`, which is the standard set for a project hosted under an institutional umbrella.

Extensions are the product, the core is the framework

The most consequential fact about Slicer is not in the README at all, and it is what the `Extensions/` directory and the topic list between them imply. Segmentation tools, tractography, radiotherapy planning modules and AI-assisted contouring are distributed as extensions rather than built into the application.

That split has real consequences. A user installing a stable build gets a platform plus whatever extensions their workflow needs, and an extension can be updated without waiting for an application release. A developer building an extension targets the MRML scene graph, the module system and the Python interop layer rather than the whole application.

It also explains the shape of the question people ask most often, which is whether a given clinical task is already covered. The answer lives in the extension index on slicer.org, not in this repository, because extensions are published through the extension manager rather than merged here. The README's own carousel is a hint of this: the COVID analyzer, the lumpectomy work and the NVIDIA AI segmentation screenshot are all extension-shaped examples presented on a page that never explains what an extension is.

The two roles of the repository are therefore separate. Core is small, stable and changes slowly. Extensions change weekly and are where the clinical work happens.

Licensing, releases and the gap the README leaves

Two details are easy to misread. The first is licensing. GitHub records no recognised licence identifier for the repository, and the README points to `License.txt` at the root instead of naming a licence. For a package that bundles VTK, ITK and other third-party components, the licensing terms are distributed in a document rather than expressible as a single SPDX tag, and that is why a machine-readable field is empty. Anyone redistributing output or embedding Slicer in a pipeline should read that file rather than assume MIT or Apache.

The second is releases. The only release asset attached to this repository is named `docs-resources`, published on 2020-05-19, and its description says it holds binary files used in Slicer documentation. That is not an application build. It tells you the build artefacts are not distributed as GitHub releases from this repository, which is consistent with a project that publishes installers through its own download infrastructure at slicer.org.

So the README is short because the project expects you to leave for the website. For a reader evaluating the project, that is workable but thin: the repository settles the architecture, the governance and the build system, while the install instructions, the extension catalogue and the user documentation all live off the repository page.

Editorial conclusion

3D Slicer works because it draws a hard line between the platform and the science. The core is a small set of MRML scene-graph and module-loadering mechanics in C++, and everything a clinical user actually wants, lung CT analysis, AI-assisted segmentation, lumpectomy planning, is an extension installed on top. That architecture is why the repository looks like a shell and why the extension index on slicer.org is the directory worth reading. What the README settles is minimal, mainly that the application is free, multi-platform and points at slicer.org and the Discourse forum, and the one release asset attached to the repository is a documentation image archive rather than a build. Start by installing a stable build from slicer.org, then read the extension manager's catalogue to see whether the clinical question you have is already solved before writing anything.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Slicer/Slicer on GitHub