QuPath: a Java desktop workbench for whole-slide pathology analysis

The problem QuPath targets: whole-slide images are too large for ordinary viewers

A scanned histology slide is a multi-gigabyte pyramid, and the tools that open it are usually either vendor-locked viewers or general-purpose image editors that cannot hold the coordinate system, the annotation layer and the analysis result in one place. QuPath positions itself as the middle ground. The README lists its scope directly: tools to annotate and view whole slide and microscopy images, workflows for brightfield and fluorescence analysis, cell segmentation, tissue microarray dearraying, interactive machine learning for object and pixel classification, and scripting for batch processing. The intended user is a researcher or a pathology lab analyst who has slides on disk and wants measurements out, not a developer building an imaging product. The README closes with a statement worth taking literally: QuPath is an academic project intended for research use only. That single sentence sets the boundary for everything that follows, including who should not install it.

How the pieces fit: a JavaFX desktop client over a slide-reading and analysis core

The repository is a Java project built on JavaFX, and the topic list names OpenCV, ImageJ and machine learning among its concerns. The architecture implied by the README is a desktop application that reads a slide through an image-server abstraction, renders a region of interest, and stores annotations and detected objects as data attached to the image rather than baked into pixels. Analysis happens in two layers. Object and pixel classification are described as interactive machine learning, meaning the user draws or labels examples in the viewer and the classifier is trained on those labels inside the application. Cell segmentation and tissue microarray dearraying are shipped as algorithms for common tasks rather than as external plugins. Scripting is the third layer: the README describes customization, batch processing and data interrogation by scripting, and the project topics list Groovy, which is the scripting language QuPath exposes. The practical consequence is that a workflow is a sequence of viewer operations plus a Groovy script, and the script is the artefact you can version and re-run. Integration with ImageJ is listed as a feature, so the boundary between the two tools is deliberately porous rather than a hard fork.

Getting it running: download the release, or build from source with the documented page

There are two supported entry points, and the README names both. For normal use, go to the Latest Releases page and take the v0.7.0 build; v0.7.0 was tagged on 2026-03-02, following a release candidate on 2026-02-17, and v0.6.0 preceded it in June 2025. For source builds, the README points to the building page under the readthedocs documentation rather than reproducing the commands, so the exact Gradle invocation is not something this article can quote from the supplied material. What can be stated is the dependency posture: Java, JavaFX and OpenCV are all in play, which means a source build is a JVM build with native components and is not a one-line install. Configuration lives in the application itself rather than in a single config file you edit before launch; the documentation at qupath.readthedocs.io is the reference for settings and for the scripting API. Support runs through the image.sc forum under the qupath tag, which the README links from the badge at the top of the file. If you are evaluating QuPath for a lab, the realistic first step is to install the release, open one of your own slides, and confirm the format reads before you invest time in scripting.

Where QuPath stops being the right tool

The research-use-only statement is a limitation, not a disclaimer to skim. A tool intended for research is not a clinical device, and nothing in the README suggests regulatory clearance or validated diagnostic use. The second constraint is the desktop model. QuPath is a JavaFX application, so the work happens on a machine with enough memory and a screen; there is no server mode described in the material, and a batch of hundreds of slides still needs somewhere to run and someone to watch it. The third is the scripting language. Groovy is capable and the topics list confirms it, but a lab whose analysis code already lives in Python or R will be maintaining two ecosystems, and the Python side will not call QuPath's classifiers directly. The fourth is the licence, covered below. None of these make QuPath a bad choice; they make it a specific one. If your requirement is a web service that pathologists log into from a browser, QuPath does not describe that shape of deployment.

The alternative that differs most: Fiji and ImageJ

The natural comparison is Fiji, the ImageJ distribution. The README itself lists easy integration with ImageJ as a QuPath feature, so the two are not rivals in the sense of replacing each other. The difference in approach is real, though. ImageJ and Fiji grew around a plugin architecture with a macro language and a very large catalogue of community plugins, and they operate comfortably on single images and small stacks. QuPath grew around whole-slide images, an annotation and object data model, and interactive classifier training inside the viewer. If your data is a folder of TIFFs from a microscope and your analysis is a sequence of ImageJ plugins, Fiji is the shorter path. If your data is scanned slides with regions of interest, object counts and a need to re-run the same measurement across a cohort, QuPath's data model is the reason to prefer it. The integration means the decision is not permanent: you can move between them, but you should pick the one that owns the slide and the annotation record.

Licence and the cost of staying current

QuPath is released under GPL-3.0, and the README frames that choice as a way to make analysis methods open and transparent. For a research group running QuPath on its own machines, the licence is unremarkable. If you plan to ship QuPath inside a commercial product, link it into proprietary code, or redistribute a modified build, GPL-3.0 obligations become a question for your institution's legal or technology transfer office; this article cannot give legal advice, and the licence text in the repository is the authority. On maintenance, the release cadence visible here is roughly annual for major versions, with a release candidate ahead of the stable tag, and the project is developed at the University of Edinburgh with funding from the Wellcome Trust and CZI listed in the README. That funding is a dependency worth noting: the project is not a company with a support contract. Upgrading from v0.6.0 to v0.7.0 is a version jump in a scripting-heavy application, so any Groovy scripts you rely on are the thing to re-test, not the installer.

What to check before you standardise on QuPath

Three checks decide whether QuPath fits. First, open a representative slide from each of your scanners and confirm the format and magnification behave as expected; format support is the kind of thing that is best verified on your own data rather than assumed. Second, write one small Groovy script that performs a measurement you already trust and run it on two slides, then confirm the output is identical when you re-run it. Third, read the GPL-3.0 terms against how you intend to distribute anything built on top of QuPath. If all three pass, the case for adopting it is straightforward: a research group gets annotation, classification, cell segmentation and batch scripting in one desktop tool, with ImageJ interoperability and a documented scripting API. If the first check fails on your slide formats, no amount of scripting will fix it, and you should look at a tool whose reader supports your scanner before you invest further.

Editorial conclusion

Adopt QuPath if you are a research group or core facility that needs to annotate whole-slide images, run cell or tissue detection, and reproduce the result later from a script on your own workstations. Do not adopt it if you need a regulated clinical reader, a browser-based multi-tenant service, or a Python-first library that you can call from an existing notebook pipeline. Before committing, verify three things yourself: that your slide formats open at the magnification you need, that the v0.7.0 API matches the Groovy scripts you intend to reuse, and that your institution accepts GPL-3.0 terms for any code you plan to redistribute alongside QuPath.

Official sources

1. License: GPL-3.0
2. Project website
3. qupath/qupath on GitHub
4. README
5. Releases