HistomicsTK: a Python pathology toolkit that also runs as a Digital Slide Archive plugin
A Python toolkit for pathology image analysis algorithms.
At a glance
- What is it?
- HistomicsTK packages color normalization, color deconvolution, nuclei segmentation and feature extraction for whole-slide histology images. It works either as a plain Python library or as a containerized task library behind HistomicsUI, and the install path is the part most teams will underestimate.
- Who is it for?
- Adopt HistomicsTK if you already run a Digital Slide Archive instance and want containerized analysis tasks surfaced in HistomicsUI, or if you need a plain Python library for color deconvolution and nuclei segmentation and are willing to manage the large_image native dependencies yourself. Do not adopt it as a general computer-vision framework, and do not assume the OSX instructions are complete: the README itself says that path needs confirmation from an OSX user.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap HistomicsTK was written to fill
Whole-slide imaging produces multiresolution images of tissue at a scale that makes manual review expensive and computational review attractive. The README argues that open-source tooling for managing, visualizing and analyzing digital pathology has lagged behind radiology and genomics, and it names the two audiences it wants to serve: pathologists and biologists who want to apply existing algorithms to their own slides, and algorithm researchers who want to write new methods and distribute them. That second audience is the more distinctive one. HistomicsTK is not only a bag of image functions; it is a delivery mechanism. Algorithms can be wrapped with slicer cli web and integrated into the Digital Slide Archive so that non-programmers invoke them through HistomicsUI on data that never leaves the server. If you only need color normalization in a notebook, the standalone library mode covers you. If you need a shared, web-accessible analysis service for a lab or a pathology department, the plugin mode is the reason to pick this project over a generic image library.
Two ways to consume the same code
The README describes the split explicitly. As a pure Python package, HistomicsTK applies algorithms to data independently of the Digital Slide Archive and offers what it calls fundamental algorithms for color normalization, color deconvolution, nuclei segmentation and feature extraction. As an image-processing task library for HistomicsUI and DSA, it lets end users apply containerized analysis modules and pipelines over the web. Those two modes imply different operational work. Library mode means you manage a Python environment and read slides yourself. Plugin mode means someone manages a DSA deployment, and the algorithms arrive as containers invoked from a browser. The repository's own history explains why this matters: it used to hold most of the Digital Slide Archive and HistomicsUI, and the deployment and UI code has since moved to separate repositories, with the README stating that the remaining deployment and UI code will eventually be removed from master. Anyone pinning to an old commit expecting a full stack should read that note carefully.
Slide reading happens in large_image, not here
The most important architectural fact in the README is that HistomicsTK uses the large_image library to read content from whole-slide and microscopy image formats. That dependency is where the practical difficulty lives. large_image needs native libraries for each format family, and the README is candid that installing them can be complex depending on the system. Two strategies are offered. The first is to pull prebuilt wheels from a find-links index hosted at girder.github.io/large_image_wheels, which bundles non-official prebuilt libraries for Linux. The second is to let the system libraries do the work, which on Ubuntu means installing libopenslide-dev and libtiff-dev through the package manager. The choice is not cosmetic. If a previous install of HistomicsTK or large_image used system libraries, the README warns that pip may need --force-reinstall --no-cache-dir before it will honour the find-links option. This is a dependency-resolution trap rather than an algorithm problem, and it is the first thing that will break in a fresh environment.
Install commands, Linux first
The README gives a PyPI install as python -m pip install histomicstk --find-links https://girder.github.io/large_image_wheels, and a source install as a git clone of the HistomicsTK repository followed by python -m pip install -e . with the same find-links flag. Windows from source is a longer sequence: pip install large-image, pip install cmake, clone the repository, install setuptools-scm, Cython, scikit-build, cmake and numpy, then pip install libtiff, then pip install large-image-source-tiff to get typical tile sources, with the note that other sources need other libraries. Visual Studio 2017 Community and the C++ build tools are required, with the instruction to ensure the first eight boxes under Desktop Development with C++ are checked, followed by python -m pip install -e . and pip install girder-client. The OSX section is short and honest: use homebrew for libtiff and openslide or whichever libraries match your tile sources, then pip install histomicstk large-image-source-tiff large-image-source-openslide. The README states that this section needs confirmation from an OSX user and probably makes assumptions about available libraries. Treat the Windows and OSX paths as starting points that will need adjustment, not as tested recipes.
Where the toolkit stops
HistomicsTK is not a slide viewer, a database, or a user interface. Those responsibilities sit in the Digital Slide Archive and HistomicsUI repositories, and the README points readers there for installation instructions. It is also not a general-purpose computer-vision library with a broad model zoo; the described functionality is the fundamental set of pathology operations plus whatever you or others add through slicer cli web. Two further constraints are worth stating plainly. First, format support is inherited from the tile sources you install, so a pipeline that works on one site's scanners may fail on another's until the matching source library is present. Second, the plugin mode assumes you have a DSA deployment to plug into, which is a heavier commitment than a pip install. A team that wants a single self-contained script for one slide format will find the containerized task model unnecessary overhead, and a team that wants a hosted service without operating the surrounding platform will find that the surrounding platform is not in this repository.
How this differs from OpenSlide plus scikit-image
The obvious alternative for reading and processing whole-slide images in Python is to combine a slide reader such as OpenSlide with general image libraries like scikit-image or OpenCV, writing the pathology-specific steps yourself. The difference is in what comes preassembled. With the OpenSlide route you get a reader and a large collection of generic operations, but color deconvolution, stain normalization and nuclei segmentation are your responsibility, and there is no packaging convention for handing a finished algorithm to a colleague who does not write Python. HistomicsTK bundles those pathology operations and defines a path from algorithm to deployed task through slicer cli web and HistomicsUI. The trade-off runs the other way too: the generic stack has a much wider user base and far more documentation, while HistomicsTK's install surface is tied to large_image's native dependencies and its server-side story assumes the Digital Slide Archive. Choose based on whether the deliverable is a notebook or a service.
Licence, maintenance and upgrade cost
HistomicsTK is Apache-2.0, which permits commercial and academic use and modification with the usual notice and attribution conditions; the README's licence badge links to the large_image licence file rather than a HistomicsTK-specific one, so confirm the file you actually receive when you vendor or redistribute. Recent release activity shows v1.4.0 in February 2025 and v1.3.13 and v1.3.14 in October 2024, with a last push to master dated September 2026, so the project is not dormant. The maintenance cost is concentrated in the environment rather than the API. large_image native dependencies, the find-links wheel index and the format-specific tile source packages all have to be kept in step, and the README's force-reinstall note suggests that upgrades can silently keep using older system libraries. The funding note credits NIH grant U24-CA194362-01, which is context for the project's institutional backing rather than a guarantee of support. Plan for a pinned environment and a rebuild step when tile sources change, and read the release notes before moving between minor versions.
Editorial conclusion
Adopt HistomicsTK if you already run a Digital Slide Archive instance and want containerized analysis tasks surfaced in HistomicsUI, or if you need a plain Python library for color deconvolution and nuclei segmentation and are willing to manage the large_image native dependencies yourself. Do not adopt it as a general computer-vision framework, and do not assume the OSX instructions are complete: the README itself says that path needs confirmation from an OSX user. Verify first that your slide formats are covered by the tile sources you install, for example large-image-source-tiff or large-image-source-openslide, and check whether pip needs --force-reinstall --no-cache-dir because an earlier large_image install came from system libraries rather than the girder wheels index.
Community notes