TotalSegmentator: 117-Class CT and MR Segmentation from the Command Line

The gap TotalSegmentator fills between generic segmentation libraries and organ-specific tools

Most segmentation code in medical imaging is trained for one organ or one protocol. You get a liver model, a lung model, a spine model, and you wire them together yourself, handling resampling, orientation and label reconciliation at each step. TotalSegmentator takes the opposite route: one command produces masks for the major anatomical structures of a whole-body CT or MR scan, with a consistent label set. The README states it was trained on a wide range of scanners, institutions and protocols, and that a large part of the training data is public: 1228 CT subjects and 616 MR subjects, linked from the repository.

The audience is therefore narrow but well defined. Researchers who need anatomical priors for a downstream pipeline, radiomics work that requires organ masks before feature extraction, and engineers building internal tooling around DICOM archives. It is not aimed at a clinician who wants a diagnosis. The README is explicit that the tool is not a medical device and is not intended for clinical usage, while noting it is used as a component inside several FDA-approved products. That sentence is the honest summary of its position: a building block, not a product.

How the nnUNet-based pipeline turns a Nifti or DICOM folder into labelled masks

The architecture is not a single network. The repository exposes a task system, and the README describes the default task as `total` with 117 classes for CT and `total_mr` with 50 classes for MR. Task names ending in `_mr` operate on MR images; everything else is CT. Alongside the defaults there are focused tasks such as `lung_vessels`, `body`, `vertebrae_mr`, `cerebral_bleed`, `hip_implant`, `pleural_pericard_effusion`, `head_glands_cavities`, `head_muscles`, `headneck_bones_vessels`, `headneck_muscles` and `liver_vessels`. Each task carries its own weights and its own citation requirement, which is why the README lists a paper next to several entries.

Input handling is deliberately permissive. A Nifti file, or a folder or zip file containing all DICOM slices of one patient, is accepted. That means the tool does not force you to convert DICOM to Nifti yourself before you start; the conversion path is inside the package. On the output side you get a directory of segmentations rather than a single multi-label volume, which is what the `-o segmentations` example implies.

Two runtime levers appear in the usage notes. On CPU, `--fast` uses lower resolution and `--roi_subset` restricts the region of interest, both described as ways to greatly improve runtime. On an M-series Mac, `--device mps` is given for speedup. The existence of those flags tells you something about the default: full-resolution, all-class inference is the expensive path, and the cheap path trades accuracy for time.

Installing TotalSegmentator and running a first CT segmentation

The README lists Python >= 3.10 and PyTorch >= 2.0.0 as dependencies, and installation is a single pip command. Note that `setup.py` in the repository still declares `python_requires='>=3.9'`, so the packaging metadata and the README disagree on the minimum interpreter. Treat 3.10 as the supported floor.

pip install TotalSegmentator

After installation, the entry point is the `TotalSegmentator` command. The README's first example runs the default CT task against a Nifti volume and writes masks into a directory:

TotalSegmentator -i ct.nii.gz -o segmentations

For MR input the task has to be named explicitly, because the default is CT:

TotalSegmentator -i mri.nii.gz -o segmentations --task total_mr

If you are on a machine without a usable GPU, the README's advice is to add `--fast` or `--roi_subset`, and on an M-series Mac to select the MPS backend:

TotalSegmentator -i ct.nii.gz -o segmentations --fast --device mps

One optional extra: `--preview` requires the fury package, installed with `pip install fury`. FURY versions below 2 additionally need xvfb on Linux, which the project's Dockerfile installs via `apt-get`. If you only want masks and not rendered previews, skip fury entirely and keep the dependency surface small.

Where TotalSegmentator is the wrong tool

The clearest limitation is stated by the authors, not discovered by users: this is not a medical device and is not intended for clinical usage. If your workflow needs a regulated output, TotalSegmentator is a component inside such a system only when someone else has certified the whole. Reading a mask as a diagnostic result is a misuse the README warns against.

The second limitation is task coverage. The 117 classes of `total` are a fixed list. If the structure you care about is not in the selected task, there is no generic "segment anything" mode; you move to a subtask, and if no subtask covers it, the tool does not help. The class list is documented in the repository and in `resources/class_details.md`, so the check is cheap and should happen before installation, not after.

The third is the CPU path. The README offers `--fast` and `--roi_subset` as runtime remedies on CPU, which is an admission that the default configuration is not comfortable without a GPU. Lower resolution and a restricted region of interest both change what the model sees, and the README does not quantify the accuracy cost. If your study depends on small structures, the fast path is the wrong path, and you should budget for GPU hardware instead.

Finally, a practical packaging detail: the Dockerfile pins `numpy<2.0.0` and installs torch from the cu121 index, and it downloads pretrained weights at build time. That build is heavy and network-dependent, which matters if you are trying to reproduce an environment offline.

TotalSegmentator compared with MONAI and task-specific nnUNet models

The common alternative in this space is MONAI, a general framework for medical imaging deep learning. The difference in approach is the level of abstraction. MONAI gives you transforms, network blocks, losses and training loops, and expects you to bring a dataset and a training recipe. TotalSegmentator gives you pretrained weights and a command. If your goal is to train a model on your own labelled data, MONAI is the more direct route. If your goal is to obtain organ masks today without labelling anything, TotalSegmentator removes the training step entirely.

A second alternative is running nnUNet directly with a published model. TotalSegmentator is, by its own README, heavily based on nnUNet, and the README asks users to cite nnUNet alongside the TotalSegmentator papers. Going to nnUNet directly buys flexibility in preprocessing and inference configuration, at the cost of assembling the pipeline that TotalSegmentator already ships. For a single-organ problem with a public nnUNet model, that trade can be worth it; for whole-body multi-organ masks, the assembled pipeline is the reason to use the wrapper.

There is also a 3D Slicer extension, maintained in a separate repository, for users who work interactively in that environment rather than on the command line. And the project offers hosted web applications for narrower reports such as abdominal organ volume, aorta diameter, spine, pulmonary artery diameter, contrast phase detection and body weight prediction, which is a different consumption model: no local install, no GPU.

Licensing, weights and the cost of staying current

The repository is Apache-2.0, and the README marks the `total` and `total_mr` tasks as openly available for any usage under that license. That is not the whole picture. Several subtasks are annotated with an asterisk and a citation requirement, and the README attaches specific papers to `cerebral_bleed`, `hip_implant`, `pleural_pericard_effusion`, `head_glands_cavities`, `headneck_bones_vessels`, `headneck_muscles` and `liver_vessels`, among others. The asterisk convention is not explained in the text available here, so the safe reading is that some tasks carry conditions beyond the base license. Check the task you intend to use before you ship anything derived from it. This is a description of what the README says, not legal advice.

The maintenance signal is strong. The last push to the default branch was on 2026-09-23, and a weights release tagged v3.0.0-weights landed on 2026-09-07, following v2.5.0-weights in January 2025 and v2.4.0-weights in July 2024. Note the shape of that cadence: releases are weight bundles, not just code. Upgrading is therefore not only a pip operation. The Dockerfile downloads pretrained weights during the build, so a rebuilt image can pull different weights than the one you validated against. Pin the package version and, if reproducibility matters, the weight artifacts too.

A smaller inconsistency worth knowing: `setup.py` declares version `2.18.0` while the newest weights are tagged v3.0.0. The README and release tags are the better guide to what is current than the packaging metadata.

Editorial conclusion

Adopt TotalSegmentator if you need organ, bone or vessel masks from CT or MR volumes and you can accept a research-grade output that the authors explicitly say is not a medical device. Do not adopt it as a certified clinical component on its own, and do not expect it to label structures outside the task you select. Before committing, verify three things: that the task matching your modality exists in the subtask list, that your storage and runtime budget covers a full-resolution run, and that your use case is covered by the Apache-2.0 terms for the task you pick.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. wasserth/TotalSegmentator on GitHub