DCMTK: the two dozen package DICOM toolkit behind most medical imaging servers

A toolkit that is really a directory of sub-packages

DCMTK is described as a package consisting of source code, documentation and installation instructions for a set of software libraries and applications implementing part of the DICOM and MEDICOM Standard. The structure is the architecture. The toolkit contains around two dozen sub-packages, each in its own sub-directory, and they are not equal in weight. dcmdata is the data encoding and decoding library with its own utility apps, and everything else tends to sit on top of it. dcmiod handles information objects and modules. dcmnet is the networking library with utility apps, and dcmtls adds the security extensions to that network library. dcmimgle and dcmimage cover image processing, with dcmimage adding colour support on top of dcmimgle. dcmjpeg and dcmjpls are the compression libraries. Then there are the specialised ones: dcmect for Enhanced CT objects, dcmfg for functional groups, dcmpmap for parametric maps, dcmseg for segmentation objects, dcmrt for radiation therapy, dcmsr for structured reporting, dcmsign for digital signatures, dcmtract for tractography results, dcmpstat for presentation states, And the servers, dcmqrdb as an image database server and dcmwlm as a modality worklist database server.

Every sub-package ships the same six directories, so the layout is predictable

The consistency of the tree is a practical benefit when you are navigating a codebase this size. Each sub-directory, except config, contains further sub-directories for application source code, library source code, library include files, configuration data, documentation, sample and support data, and test programs. The naming convention is regular enough that you can predict where something lives before you look for it: a library's public headers are in include, its implementation in libsrc, the command line front ends in apps, and the regression tests in tests. Two of the sub-packages deviate slightly. config holds configuration utilities for DCMTK itself rather than an application or a library, and the three supporting packages at the end of the list are not DICOM specific. ofstd is a library of general purpose classes, oflog is a logging library based on log4cplus, and oficonv is a character set conversion library, which is the sort of thing that matters more than it sounds in a standard where character sets are a per-object concern.

Building means CMake or the bundled Makefile, and the Makefile drives every package in turn

This repository does not publish a compiled release for general consumption. The README sends you to the INSTALL file for the build and install procedure, to the COPYRIGHT file for copyright information, and to the HISTORY file for the history of the software. The top-level entries show that both build systems are present, with a CMakeLists.txt and a CMake directory for the CMake route and a Makefile for the classic one. The Makefile gives a clear picture of how the packages relate to each other. It includes a configdir Makefile.def for the shared definitions, sets .NOTPARALLEL so the build does not race across packages, and then defines all, libsrc-all, tests-all, install, install-all and install-bin as long chains that expand to one target per sub-package in dependency order, with dcmdata before dcmimgle, dcmnet before dcmtls, and the servers and the specialised libraries near the end. The result is that a single make invocation builds the entire toolkit, and the same structure lets you build one package if that is all you need.

The all target in the Makefile expands to one entry per sub-package:

all:  config-all oficonv-all ofstd-all oflog-all dcmdata-all dcmimgle-all dcmimage-all dcmjpeg-all dcmjpls-all dcmtls-all dcmnet-all dcmsr-all dcmsign-all dcmwlm-all dcmqrdb-all dcmrt-all dcmiod-all dcmpstat-all dcmfg-all dcmseg-all dcmtract-all dcmpmap-all dcmect-all dcmapps-all

Because .NOTPARALLEL is set, those package targets run in sequence rather than racing each other, which is what keeps the dependency order between the core library and the packages built on top of it intact.

Continuous integration runs on all three desktop platforms

The README leads with three workflow badges, for Windows CI, macOS CI and Linux CI, each pointing at a separate workflow file on the master branch. Three separate workflows rather than one matrix means the platform differences are handled explicitly, which for a toolkit that has to behave identically across compilers and operating systems is the sensible arrangement. The same convention shows up in the source layout, since each package carries its own tests directory and the Makefile exposes a tests-all target that chains to a per-package tests target. There is a CHANGES file and an ANNOUNCE file at the root next to VERSION, which is the convention for a project that has been shipping for a long time and expects downstream packagers to track its release notes. The history of the software is kept in the HISTORY file, and the FAQ for frequently asked questions lives on the project forum rather than in the repository, with the API documentation also published online.

Support is by mailing list and forum, with a wiki for the long tail

The support model is spelled out in the README and it is worth knowing before you adopt a toolkit of this size. Bugs and other problems should be reported by electronic mail to [email protected], with a description in detail and, if possible, a suggested fix, and the CONTRIBUTING.md file explains how to contribute. General questions about how to compile, install or use the toolkit are directed to the public discussion forum at forum.dcmtk.org. Alongside the API documentation there is a wiki system for further information such as HOWTOs. The pattern is the usual one for a long-lived foundation-style project: a stable library with a slow-moving core, an active community around it, and support handled in public rather than through a commercial channel. There is also a dedicated homepage at git.dcmtk.org, and this GitHub repository is the official mirror rather than the primary development host, which matters if you are deciding where to file issues or how you will track upstream changes.

The licence is a custom one, so the COPYRIGHT file is the reference

The licence field for the repository carries a custom licence that GitHub cannot classify, and the README points to the COPYRIGHT file for copyright information. That is a deliberate structure rather than a gap, but it does mean you cannot answer the licensing question from the repository listing alone, and you should not assume a standard OSI licence from the topic tags, which do include bsd-3-clause alongside dcmtk, dicom and toolkit. The only reliable source is the COPYRIGHT file in the repository root. This is a description of where the terms live and not legal advice: if you are embedding DCMTK in a commercial product or redistributing it as part of a packaged distribution, read that file and, if the arrangement is unusual, take your own advice on it. What is safe to say is that the toolkit is open source in the ordinary sense, with source, documentation and installation instructions all published, and that the mirror, the documentation site and the forum are all openly reachable.

Where DCMTK is the wrong tool

Two situations stand out. The first is a team that wants to query a hospital's existing PACS and does not want to implement DICOM at all. DCMTK is an implementation, not a service, and dcmqrdb and dcmwlm are database servers that speak the protocols rather than clients that abstract them, so wrapping them still leaves you responsible for association negotiation, query modelling and the transfer syntaxes. The second is a Java or Python shop with no C++ appetite. DCMTK is a C++ codebase, and while the source and headers are available, integrating it into a managed runtime means either a native extension or a sidecar process, and neither is free. What DCMTK is genuinely good at is the opposite case: reading and writing DICOM correctly at the byte level, handling the awkward corners of the standard such as functional groups, Enhanced CT objects, presentation states and structured reporting, and running the network services that move that data between systems.

Editorial conclusion

DCMTK suits a medical imaging team that has to read, write or serve DICOM data and wants the implementation details rather than a wrapper around somebody else's service, and the per-package split means you can depend on dcmdata alone instead of the whole toolkit. It does not suit someone who wants a managed dependency or a hosted imaging API, because there is no package manager entry point and no prebuilt binary in this mirror. Before you commit, read the INSTALL file at the repository root for the exact build steps, decide whether you need the TLS extensions in dcmtls and the servers in dcmqrdb or dcmwlm, and check the COPYRIGHT file to settle the terms, since the licence field for the repository carries a custom licence that GitHub cannot classify.

Frequently asked questions

Official sources

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