slicer-forge
A 3D Slicer extension that batch-imports DICOM through the dicom-forge pipeline.
slicer-forge adds a DICOM Forge Batch module to Slicer. Point it at a folder of DICOM, and it de-identifies each series (removes patient names and IDs from headers), runs quality control, converts to NRRD, and loads the volumes straight into your Slicer scene — driven entirely by the headless, independently tested dicom-forge library.
The two-repo design
| Repo | Role | Tested |
|---|
dicom-forge | Headless pipeline (ingest · de-id · QC · convert) | Unit-tested in CI without Slicer |
slicer-forge (this) | Thin Slicer GUI on top of it | Self-test runs inside Slicer |
This mirrors how Slicer itself is built (ITK/VTK do the work; the GUI is a shell on top). All the heavy logic lives in dicom-forge, so it is fully testable on its own; this repo stays a small, focused front-end.
What the module does
- Install dependencies — one button runs
pip_install('dicom-anvil[convert]') into Slicer's own Python environment (the engine ships on PyPI as dicom-anvil; it still imports as dicomforge).
- Pick folders — a DICOM input folder and an output folder.
- Choose options — de-identification level (basic / moderate / strict) and output format (NRRD / NIfTI).
- Run — every series is de-identified → QC'd → converted → loaded into the scene, with a per-series PASS/FAIL summary and warnings. Cancel stops the batch after the current series; the panel updates between series.
📖 New to the module? Follow the step-by-step usage tutorial. See the changelog for what has changed.
Installation
From source (developer install)
git clone https://github.com/DaCameraGirl/slicer-forge.git
In Slicer: Edit → Application Settings → Modules → Additional module paths, add the slicer-forge/DicomForgeBatch folder, and restart. The DICOM Forge Batch module appears under the Informatics category.
Build as a loadable extension
The repo is laid out for the standard Slicer extension build (CMakeLists.txt + slicerMacroBuildScriptedModule) so it can be built against a Slicer build tree and submitted to the Slicer Extensions Index.
Module anatomy
Slicer scripted modules use a fixed four-class shape — this one lives in DicomForgeBatch/DicomForgeBatch.py:
DicomForgeBatch — module metadata.DicomForgeBatchWidget — the GUI panel (built programmatically).DicomForgeBatchLogic — Qt-free logic wrapping dicom-forge (reusable from the Python console).DicomForgeBatchTest — a self-test that generates synthetic DICOM and runs the whole pipeline inside Slicer.
Testing
The self-test runs inside Slicer (it needs the slicer runtime):
In Slicer's SelfTests module (category Testing) run DicomForgeBatch, or from the Python console: slicer.selfTests['DicomForgeBatch']().
CI runs on every push at two levels:
- a fast lane lint-checks and byte-compiles the module, and
- a headless-Slicer lane that downloads real 3D Slicer and runs the full pipeline end-to-end — de-id → QC → convert → load — across CT and MR, multiple series, both output formats, every de-identification level, and failure paths.
⚠️ De-identification is best-effort risk reduction, not a compliance guarantee. See dicom-forge's SECURITY policy.
Desktop validation with public DICOM data
A desktop smoke run was captured in 3D Slicer 5.10 using a publicly available, raw DICOM brain MR series from TCIA's ReMIND collection (CC BY 4.0). The archive-assigned case ReMIND-086 / 2D_AX_T2_FLAIR contained 32 MR slices. The local DICOM Forge Batch module processed that input with the moderate de-identification setting, reported QC=PASS, wrote series_000.nrrd, and loaded the resulting volume into Slicer.
This specific desktop run establishes the scenario above: moderate de-identification, QC=PASS, NRRD output, and scene import for this one public MR series. It does not by itself establish NIfTI output, the basic or strict settings on this machine, or clinical interpretation. De-identification is risk reduction, not a compliance guarantee.
License
Apache-2.0 © Angela Hudson
