Slideflow: digital pathology tooling where the foundation models are a separate license

The six foundation models are in a different package

The licensing arrangement is the first thing to understand, and it is not a detail buried in a terms file. The core library is Apache-2.0. The pretrained models and a handful of the headline architectures are not. They arrive through two extra packages:

pip install slideflow-gpl slideflow-noncommercial

That install adds integrated access to six pretrained foundation models, naming UNI, HistoSSL, GigaPath, PLIP, RetCCL and CTransPath, along with the multiple-instance learning architecture CLAM, the uncertainty quantification algorithm BISCUIT, and the GAN framework StyleGAN3. So the feature list on the front page, which advertises built-in foundation models, multiple-instance learning, uncertainty quantification and GANs, is true of the project but not of the Apache-2.0 distribution. For a research group that is a reasonable split. For anyone planning to run this inside a commercial product, the model weights are the thing to price and clear, not the library, and the repository gives you no guidance on what non-commercial means in your context. The claim to make in front of a legal reviewer is that you have checked the separate package, not that the project is Apache-2.0.

cuCIM reads faster and understands fewer scanner formats

Whole-slide images are enormous, so how they are read is an architectural decision rather than an implementation detail, and Slideflow supports two readers with a genuine trade-off between them. By default it uses cuCIM, which the documentation describes as much faster than other OpenSlide-based frameworks while supporting fewer slide scanner formats. The alternative is a Libvips backend, and what it buys is format coverage: it adds support for the scn, mrxs, ndpi, vms and vmu extensions. Choosing between them is therefore a question about where your slides came from rather than about speed. The backend is selected with an environment variable:

export SF_SLIDE_BACKEND=libvips

The same variable in the other direction gets you the faster default. There is a knock-on effect worth noting for installation, since the accelerated reader needs a CUDA array library whose package name depends on the installed CUDA version, and that library is not needed at all if you go with Libvips. So the format coverage you need may also determine how painful your install is, and the version constraint on Python interacts with the choice as well, since the accelerated reader is documented as requiring a Python older than the project's stated minimum.

Two Dockerfiles, and the PyTorch image needs a bigger shared memory mount

The container route is the most reliable way to get a working install, and the repository ships two Dockerfiles at the top level, one per deep learning backend, with pre-built images published for both. The Tensorflow image is the simpler invocation:

docker pull jamesdolezal/slideflow:latest-tf
docker run -it --gpus all jamesdolezal/slideflow:latest-tf

The PyTorch image carries an extra flag that is easy to miss and expensive to debug without:

docker pull jamesdolezal/slideflow:latest-torch
docker run -it --shm-size=2g --gpus all jamesdolezal/slideflow:latest-torch

Both images ship with OpenSlide and Libvips already present, so the slide-reading backends are available without the optional install, and both pass through all GPUs. The shared memory flag on the PyTorch variant is there because the default container shared memory region is too small for the data loading this kind of work generates, and the symptom of omitting it is a data loader failure rather than anything that points at the cause. The third route is running from source, which clones the repository, creates a conda environment from the shipped file, and installs the package in editable mode alongside the CUDA array library.

Preserved-site cross-validation needs a linear solver

One optional dependency is worth calling out because it is unusual and it tells you something about the statistics the library supports. Preserved-site cross-validation requires a linear solver, and the documentation names two routes: IBM's CPLEX at a pinned version 20.1.0 with its Python API, or Pyomo with the Bonmin solver. Neither is in the standard requirements, and both are heavyweight, so this is not a dependency you pick up casually. It does suggest the library is built for the setting where spatial structure in a slide has to be respected when splitting data, which is the central methodological problem in digital pathology: a random split of tiles leaks information between train and test because neighbouring tiles come from the same tissue. Everything else on the optional list is lighter, being the alternative slide reader and nothing more. The feature surface itself is broad, spanning customisable training pipelines, stain normalization, weak and strong supervision, self-supervised learning, heatmaps, mosaic maps, saliency maps, synthetic histology, layer activation analysis and an interactive deployment interface.

One environment variable chooses the framework, and both are installed anyway

Backend selection is a single environment variable, with a default that only matters when you have both frameworks present. Slideflow supports PyTorch and Tensorflow, and when both are available it defaults to PyTorch. You override it like this:

export SF_BACKEND=tensorflow

The detail that makes this less of a choice than it looks is the requirements file, which lists both frameworks, Tensorflow within a bounded range and PyTorch from 1.9.1 upward, along with a matching set of Tensorflow-adjacent packages including a probability library and a datasets library, both upper-bounded. So the documented Tensorflow support window is narrow and explicitly capped, while the PyTorch side is open-ended. The stated requirements are Python 3.7 or newer, PyTorch 1.9 or newer, or Tensorflow between 2.5 and 2.11. Given that a Python floor of 3.7 and a Tensorflow ceiling of 2.11 both date from well before current releases, the combination is only satisfiable on an older interpreter, which is worth checking against your own environment before you plan an install.

A project owns the slides, the tiles and the annotations

The unit of work is a project rather than a script, and that is the design decision that makes the library usable on real cohorts. A project supervises the storage of whole-slide images, the tiles extracted from them, and patient-level annotations, which is the level at which splits have to be made. The documented fast path is to start from a preconfigured project, which will download slides from the Genomic Data Commons automatically, verify them, and leave you ready to extract tiles:

import slideflow as sf

P = sf.create_project(
    root='/project/destination',
    cfg=sf.project.LungAdenoSquam(),
    download=True
)

The configuration object names the cohort, so swapping datasets is a matter of choosing a different one rather than rewriting a data loader. Verification as a distinct step is the part that matters in practice, since a partially downloaded slide that passes an existence check will fail much later inside a training run. For developers, the documentation also points at multiple endpoints for integrating with other packages and external training paradigms, which is the escape hatch for people who want Slideflow's slide handling and stain normalization without adopting its training loop.

The dependency list is frozen, and one package appears twice

The requirements file is the clearest evidence of the project's maintenance state, and it is a long one. Two pins are exact rather than bounded, most notably the hyperparameter optimization library at a single fixed version, and the rest carry upper bounds that read like a frozen environment: Tensorflow below 2.12, a protobuf series below 3.21, Tensorflow probability below 0.20, seaborn below 0.14, a language processing library below 3.8 and a segmentation library below 2.2. The breadth is also revealing. Alongside the obvious imaging stack of OpenCV headless, scikit-image, rasterio and a Zarr store, there is a cell segmentation library, a dimensionality reduction library, a language processing library, a fastai dependency, geometry libraries, a GUI toolkit with OpenGL bindings, a PDF writer, a rich terminal library, and a mail sender. One package is listed twice in the file, which is harmless but is the sort of thing that appears when a list accretes. The installation script also probes for an existing OpenCV install and prefers the headless build, defaulting to it when neither variant is present, which is a sensible default for a server.

Three releases in 2024, then two years of commits without a tag

The version history needs to be read alongside the dependency list. Version 3.0.0 was tagged in August 2024, 3.0.1 in September of that year and 3.0.2 in October, and there has been no release since. The repository, however, is not archived and the last push was on 2026-09-24, which means development has continued for roughly two years past the last tag. For a library that pins a hyperparameter optimizer to one exact version and caps several others, that gap is the dominant practical fact: you are installing a 2024 dependency set against a 2026 code base, and whether that combination works is something you have to establish yourself rather than read off a support matrix. The packaging itself is unremarkable in a good way, using versioneer to derive the version from the repository state, shipping the normalisation reference tile and the studio interface assets including fonts and icons as package data, and registering a console script for the studio interface alongside the Apache-2.0 classifier.

Editorial conclusion

Slideflow is worth evaluating if you are doing real whole-slide work and want slide processing, stain normalization and weak supervision handled in one library rather than assembled from parts. Two things to settle before you plan around it. The pretrained foundation models everyone names in this field are not in the Apache-2.0 package, they are in a separately installed non-commercial package, so a commercial deployment has a different licensing conversation. And the release history stops in October 2024 even though the repository was pushed to on 2026-09-24, so the dependency set is effectively frozen: the requirements file pins several packages to exact or upper-bounded versions, which is what you would expect from a project that has not cut a release in two years.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. slideflow/slideflow on GitHub