# CTK is the shared layer that medical imaging applications keep reinventing > The Common Toolkit is a community effort to supply the code that medical image analysis and surgical navigation projects all need and none of them want to write, and its scope is stated precisely: DICOM, DICOM application hosting, Qt widgets, a plugin framework and a command line interface module. Its build is a CMake superbuild with a dependency manager attached. **commontk/CTK** — A set of common support code for medical imaging, surgical navigation, and related purposes. - Repository: https://github.com/commontk/CTK - Website: https://commontk.org - Stars: 968 · Forks: 525 - Language: C++ - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/commontk-ctk ## The parts of an application that nobody wants to write The project describes itself as a community-driven effort focused on providing support code for medical image analysis, surgical navigation and related projects, and the key phrase in the overview is that it covers topics not addressed by existing toolkits. That framing is what makes it legible. ITK, VTK and DCMTK are the big tools in this field and they each cover a layer, and the layers above them, the DICOM workflow, the plugin system, the reusable widgets, the command line plumbing, are exactly the parts that a dozen unrelated projects end up writing badly and separately. The current scope is listed as five topics, DICOM, DICOM Application Hosting, Widgets, Plugin Framework and Command Line Interfaces. The repository is the usual shape for a project like this, with `Libs/` for the libraries, `Plugins/`, `Applications/` for the sample and tool applications, `CMake/`, `CMakeExternals/` for the dependency machinery, `Documentation/`, `Utilities/` and a `SuperBuild.cmake` at the root, plus a `CTestConfig.cmake` for the test harness. ## The plugin framework is an OSGi model in C++ The plugin framework is the piece that makes CTK a platform rather than a pile of helpers. CTK provides a dynamic component system for C++ modelled after the OSGi specifications, and it enables a development model where applications are dynamically composed of many different reusable components in a service-oriented way. That is a large idea to bring to desktop C++, and it is the reason CTK appears in the topic list of projects that need a plugin architecture and cannot justify writing one. The consequence for a user is that a CTK based application is assembled at run time from components rather than linked at build time, which eases extension and complicates packaging. It also means the framework's own documentation is where you should start rather than the code, since the wiki page is the entry point the README points at. ## DICOM comes from DCMTK, and the widgets are the visible part The DICOM topic is the one most people will meet first. CTK provides high-level classes that support query and retrieve operations from PACS and from local databases, together with Qt widgets for setting up a server connection, sending queries and viewing the results. The underlying toolkit used is DCMTK, which is the important architectural fact, since CTK is not reimplementing the DICOM standard but building a usable layer on top of an existing, well tested one. That is a good trade for a project that wants a graphical query experience without owning a protocol implementation. The Widgets topic is the other visible surface, a collection of Qt widgets for biomedical imaging applications, and the documentation points at a gallery and a widgets page rather than reproducing a list, which is a reasonable thing to do for a widget library that renders better than it reads. ## Application hosting is a reference implementation, still labelled alpha DICOM Application Hosting is the most ambitious and the least finished part of the project. CTK aims to create a C++ reference implementation of the DICOM Part 19 Application Hosting specifications, and it provides the infrastructure to create both hosts and hosted applications. The documentation is careful about the status, saying that although the project is still in alpha status it can be useful for conformance testing and initial experimentation. That is an honest framing, and it tells you what to do with it, which is to use it as a testbed for the specification rather than as a production application framework. The specification itself, Part 19 of the DICOM standard, defines how applications are hosted on a medical imaging system, so a reference implementation is genuinely useful to the people writing such systems, which is a small audience that the project does not pretend to be serving broadly. ## A CLI module for algorithms written in other languages The command line interface module addresses a specific and common problem in this field, which is that the interesting algorithms are often not written in C++ at all. A segmentation method in Python, a registration tool in Fortran, a measurement script in Java, and the application around them is a C++ and Qt program. CTK supports the usage of algorithms written as self-contained executables in multiple programming languages, and the CLI module provides a flexible and extensible framework for defining, executing and configuring those command line interfaces for algorithms. The design value is that the framework makes a foreign executable look like a first class citizen, with its own parameters, its own configuration and a place in the application's menu, rather than something invoked by hand. For a research group whose tooling is a mixture of languages, that is a real saving, and it is the kind of module that is easy to underestimate from the outside. ## The build is a superbuild, and the toolchain has to match Building CTK needs a C++ compiler, the Qt libraries and CMake, and the configuration is done with a small number of CMake options, `CTK_QT_VERSION` set to 5 and a `Qt5_DIR` pointing at the Qt installation. The VTK side is conditional, the visualisation, VTK and widgets layer is switched on with the `CTK_LIB_Visualization/VTK/Widgets` option, and when it is, the documentation is explicit that three VTK modules must be enabled in your VTK build, `VTK_MODULE_ENABLE_VTK_ChartsCore`, `VTK_MODULE_ENABLE_VTK_GUISupportQt` and `VTK_MODULE_ENABLE_VTK_ViewsQt`, or the build will not give you what you asked for. The other note in the build section is a warning worth passing on to your team. The toolchain version has to be compatible with the Qt version, and the documentation gives the exact failure that a mismatch produces, a link error about an unresolved external symbol for `QLinkedListData` when building with Qt 5.12 and Visual Studio 2019, with the two remedies being an earlier toolset or a newer Qt. For a medical imaging project, the environment for the build is often not something the developer picks, and this is the note that saves an afternoon. ## Dependencies arrive by themselves, and the support matrix has edges The last technical topic is dependency management, and it is unusual enough to be worth describing. CTK handles the download, configuration and building of the dependencies it needs, with the exception of Qt, as part of the build process, so that the libraries are there without manual intervention, and each dependency can be overridden with options like `_DIR` or `CTK_USE_SYSTEM_`, with the per dependency files in `CTK/CMakeExternals/.cmake`. Underneath, the project integrates the Artichoke CMake module, which extends the built-in ExternalProject module, so this is a curated dependency pipeline rather than a package manager bolted on. The support matrix has edges that matter. Qt 5 is supported with C++11, VTK 9 or newer and a patched branch of PythonQt, and Python 3 is supported. Qt 4, C++98, VTK 8, ITK 4.13.3 and Python 2.7 were all dropped together in the 2023.07.13 release, which is the last version that supports them. The licence is Apache 2.0. ## Conclusion CTK suits a team writing a medical imaging or surgical navigation application that has found itself implementing DICOM queries, a plugin system or a command line module, since those are exactly the pieces the project maintains. It is a poor fit for a small desktop tool, because the build pulls in VTK, ITK and a superbuild whether you need them or not, and it is a poor fit if you are on Qt 4 or Python 2, since both were dropped with the 2023.07.13 release. Before you start, check three things: which VTK modules you need to enable, since the widget layer depends on three specific ones, whether your toolchain matches your Qt, since the documentation describes a specific link error that comes from a mismatch, and the release line you take, with 2026.09.02 published on 2026-09-02 and the last push to the repository on 2026-10-13. ## FAQ ### What is the Common Toolkit used for? It provides shared support code for medical image analysis, surgical navigation and related projects, in five areas: DICOM, DICOM Application Hosting, Qt widgets, a plugin framework and a command line interface module. The project describes itself as covering topics not addressed by existing toolkits such as ITK, VTK and DCMTK. ### How does CTK's plugin framework work? It is a dynamic component system for C++ modelled after the OSGi specifications, so an application is dynamically composed of reusable components in a service-oriented way rather than linked together at build time. The README points at the Plugin Framework documentation on the project wiki for how to start. ### Which VTK modules do I need for the CTK widgets? When the visualisation, VTK and widgets layer is enabled, the documentation says to enable VTK_MODULE_ENABLE_VTK_ChartsCore, VTK_MODULE_ENABLE_VTK_GUISupportQt and VTK_MODULE_ENABLE_VTK_ViewsQt, and to build VTK with those modules on. ### What does CTK use for DICOM, and is it complete? The underlying toolkit is DCMTK, and CTK adds high-level classes for query and retrieve against PACS and local databases plus Qt widgets for connections, queries and results. The separate DICOM Application Hosting work is a reference implementation of the Part 19 specification and is still described as in alpha status, useful for conformance testing and experimentation. ### Which Qt and Python versions does CTK support? Qt 5 with C++11, VTK 9 or newer and the patched PythonQt branch, and Python 3. Qt 4, C++98, VTK 8, ITK 4.13.3 and Python 2.7 all stopped being supported with the CTK 2023.07.13 release, which is the last version that carried them. Releases continued afterwards, with 2026.09.02 published in September 2026. ## Sources - [commontk/CTK on GitHub](https://github.com/commontk/CTK) - [License: Apache-2.0](https://github.com/commontk/CTK/blob/master/LICENSE) - [Project website](https://commontk.org) - [README](https://github.com/commontk/CTK/blob/master/README.md) - [Releases](https://github.com/commontk/CTK/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/commontk-ctk