QuPath architecture

The goal of this section is to provide an overview of QuPath's design, and justification for why it is as it is.

More details will be added over time.

QuPath modules

The following sections describe the main QuPath modules, i.e. the contents of the Jar files that are packaged up in most QuPath distributions.

Core modules

There are four main core modules:

qupath-core - contains the main data structures, and methods of general usefulness
qupath-core-processing - contains classes, interfaces and static methods related to processing (e.g. plugins)
qupath-core-awt - supplements qupath-core with additional methods that require Java AWT
qupath-core-processing-awt - supplements qupath-core-processing with additional methods that require Java AWT

The reason for keeping any dependency on AWT separate was that it might one day be necessary to run QuPath (or access serialised QuPath classes) on a platform that does not support AWT, e.g. Android. Therefore this structure aims to keep the need for AWT contained.

Additionally, there is very little use of external dependencies (primarily restricted to Apache Commons Math and a logging framework).

In themselves, the core modules can be usefully employed (heedlessly) for scripting applications.

The main GUI

There is one main module containing the QuPath GUI:

qupath-gui-fx

This is written using JavaFX (previously, QuPath was written with Swing... but no more).

This GUI module depends upon the core modules and a small number of external dependencies that supplement the default JavaFX components. This combination provides a functional interactive version of QuPath - albeit one missing quite a lot of useful commands.

Default extensions

All of the other modules bundled along with QuPath are 'default extensions' - or helper modules for extensions. These are optional and could be removed - but tend to add some very useful functionality.

The extension modules are:

qupath-extension-ij - to add commands that use ImageJ as a dependency, e.g. cell segmentation, or commands to transfer data to and from ImageJ
qupath-extension-opencv - to add commands that use OpenCV as a dependency, e.g. object classification, or Delaunay triangulation
qupath-extension-openslide - to add support for whole slide image formats using OpenSlide as a dependency
qupath-extension-pen - to add support for graphics tablets as input devices (with pressure-sensitivity using the Brush tool), with JPen as a dependency
qupath-extension-input - to add support for 3D mice as input devices for slide navigation, with JInput as a dependency
qupath-extension-script-editor - to add a nicer script editor, with syntax highlighting, using RichTextFX as a dependency

The helper modules are:

qupath-processing-ij - to support qupath-extension-ij
qupath-processing-opencv - to support qupath-extension-opencv

It might seem unnecessary to separate out the ImageJ and OpenCV extensions from the helper modules, but there is a good reason for doing so: the helper modules have no dependency on the GUI, while the extensions do. Therefore the interesting processing is implemented in the helper modules, which (combined with the core modules) could be used independently of any GUI. The extension modules are what tie them in to the GUI.

It isn't strictly necessary to separate the GUI-dependent parts of an extension from the parts that should work independently of a GUI. For a small extension adding one or two commands, it probably isn't worth the effort. But since multiple (commonly-used) commands are implemented in the qupath-processing-ij and qupath-processing-opencv modules, it was worthwhile to keep them separate here.

ImageServers

There is one extension that is a bit different: qupath-extension-openslide. This provides an implementation of a general qupath.lib.servers.ImageServer interface, which provides access to pixel data and metadata from images. This, like any ImageServer implementation, can function heedlessly and independently of any GUI.