Version 2.1.3, classified as pre-alpha
Computational Pathology Toolbox developed by TIA Centre, University of Warwick.
At a glance
- What is it?
- TIAToolbox is a computational pathology toolbox from the TIA Centre at Warwick, wrapping PyTorch for whole-slide image work with a command-line interface and twelve teaching notebooks. Its manifest declares the package pre-alpha, refuses Python 3.15, and its Makefile lints with flake8 while the README badge advertises a different tool.
- Who is it for?
- Plan around the pre-alpha label rather than the version number, and decide early whether the pretrained models are acceptable for your setting, since the source licence is BSD-3-Clause while the weights carry whatever terms their training datasets carry. Two smaller checks worth doing before you commit: whether your Python falls inside the supported window, and whether the flake8 or ruff path is the one your own CI will run, because the two disagree.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 3 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 October 12, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The default branch is develop, the contributor link says master
The repository's default branch is develop, and the links in the licence section follow it, pointing at LICENSE and the full licence text on the develop branch.
The contributing link does not. The contributor guidelines are addressed as a file on the master branch, so a reader following the README to find out how to contribute lands on a branch that is not the one the project develops on.
That is a small thing on its own, and a useful signal about the rest of the metadata: this repository carries both a pyproject.toml and a setup.py, a HISTORY.md and a CITATION.cff, and a default branch that is not the one half the documentation assumes. Anyone automating a checkout should name the branch explicitly rather than rely on the default.
The examples are named on develop as well, so the hosted notebooks follow the same branch as the code.
Released 2.1.3, self-classified as pre-alpha
The manifest declares version 2.1.3, which matches the newest release, TIAToolbox 2.1.3, published on 2026-07-21 after 2.1.2 in June. The version numbers line up, which is not always the case.
The development status is the surprise. Both the manifest and the setup script carry the classifier Development Status :: 2 - Pre-Alpha, on a package that is on PyPI and on conda-forge with three releases inside two months. A pre-alpha classifier is a statement about the public contract rather than about the version, and it is the one number in this manifest worth taking literally before you depend on the API.
The tag naming is inconsistent in the same family. One release is tagged v2.1.1.0, four segments, while its release title calls it TIAToolbox 2.1.1. Tools that assume semver will not order that tag correctly.
Python is pinned below 3.15
The package requires Python 3.12 or newer and below 3.15, a range stated identically in the manifest and in the setup script. The classifiers agree with the upper half of it, listing 3.12, 3.13 and 3.14 and nothing else.
An upper bound on a research library is unusual and it has consequences. Anyone on 3.15, whether by choice or because a base image moved, cannot install this package without changing interpreters, and no reason is given for the ceiling. It may track a dependency, but nothing in the documentation says so.
The development instructions pick the floor rather than the middle: the conda environment is created with python=3.12. So the version you get when you follow the guide is the oldest one supported, and the newest is a ceiling nobody explains.
setup.py re-reads the manifest, and macOS loses the CUDA index
Two build files coexist, and the older one derives itself from the newer. The setup script opens pyproject.toml with the standard library TOML parser, pulls the project dependencies out of it, and passes them to setuptools as install_requires. It also duplicates the metadata by hand, repeating the version range, the classifiers and the author.
One line in it is platform-conditional and worth knowing about. The dependency links list points at a PyTorch wheel index for CUDA, but only when the platform is not darwin. On macOS that list stays empty, so a machine that has no CUDA hardware gets no extra index, which is the sensible outcome, and a developer on macOS who wants a specific PyTorch build has to arrange it outside the build system.
The rest of the file is legacy machinery: setup requirements pulling in a pytest runner, a test suite declaration for a package whose tests are run by pytest directly.
The Makefile lints with flake8, the badge advertises another tool
The build tooling disagrees with itself in a way that costs time. The README badge links to ruff, and the repository has a pre-commit configuration directory, but the Makefile lint target runs flake8 over the package and the tests.
flake8 tiatoolbox testsThree more inconsistencies sit in the same file. The phony list names clean, clean-test, clean-pyc, clean-build, docs and help, while lint, test and coverage are defined but not declared, so they are real targets that nothing reserves. The default goal is help, and the help text is generated by parsing the comments in the Makefile itself with a regular expression.
The clean targets are broader than their names. clean-pyc removes compiled files and also every editor backup ending in a tilde anywhere in the tree, and clean-docs deletes generated documentation including a notebooks directory.
Sphinx is a runtime dependency and a web server ships with it
The runtime dependency list runs to around forty entries and mixes three categories that are usually kept apart. Documentation tooling is in it: sphinx appears among the runtime requirements and then again in a docs extra alongside furo, myst-nb and sphinx-design, so every install pulls Sphinx whether or not documentation is built.
A web server is in it too. flask and flask-cors are runtime dependencies, which means the package that reads slides can also serve HTTP with cross-origin requests enabled. That may be there for the viewer, and the presence of bokeh suggests interactive visualisation is part of it, but the README never says which feature needs the server or what it exposes.
Two entries carry more weight than their size suggests. defusedxml is a hardened XML parser, which matters in a package that ingests medical metadata. And wsidicom is the only dependency with an upper bound, held below 0.36.0, which will eventually block a security update until the pin moves.
The source is BSD-3-Clause, the weights are someone else's decision
The licence section separates two things. The source code is released under BSD-3-Clause, and the full text is in the LICENSE file.
Model weights are handled separately and vaguely. The README states that weights are dependent on the datasets they were trained on and sends you to the pretrained documentation for details, which means the terms on the model files are inherited from training data rather than chosen by this project.
That split matters for anyone using the toolbox on data they cannot share. The code is permissive, the weights may not be, and the sentence in between is one line long. Note also that the repository's licence metadata identifies no licence at all, so a tool that reads metadata rather than the README will conclude that nothing is licensed.
Editorial conclusion
Plan around the pre-alpha label rather than the version number, and decide early whether the pretrained models are acceptable for your setting, since the source licence is BSD-3-Clause while the weights carry whatever terms their training datasets carry. Two smaller checks worth doing before you commit: whether your Python falls inside the supported window, and whether the flake8 or ruff path is the one your own CI will run, because the two disagree.
Frequently asked questions
What is TIAToolbox?
A computational pathology toolbox developed at the TIA Centre that provides an end-to-end Python API for pathology image analysis, covering data loading, pre-processing, model inference, post-processing and visualisation, with a command-line interface on top of PyTorch.
How do I install TIAToolbox?
Run `pip install tiatoolbox`, or `pip install --ignore-installed --upgrade tiatoolbox` to replace an existing install. For development, create a conda environment with python=3.12, install openjpeg and sqlite from conda-forge, then run `pip install -e ".[dev]"`.
Which Python versions does TIAToolbox support?
The manifest requires Python 3.12 or newer and below 3.15, and the classifiers list 3.12, 3.13 and 3.14. The development guide creates the environment with python=3.12.
Can I use TIAToolbox model weights commercially?
The licence section applies BSD-3-Clause to the source code only, and states that model weights are dependent on the datasets they were trained on, with further details in the pretrained model documentation.
How do I run TIAToolbox from the command line?
The package installs a console script named tiatoolbox, wired to tiatoolbox.cli, and running `tiatoolbox --help` lists the available features. The Makefile also provides a test target that runs pytest in parallel across workers.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/tissueimageanalytics-tiatoolbox)