LazySlide: whole slide image analysis built on SpatialData and the scverse stack
Accessible and interoperable whole slide image analysis
At a glance
- What is it?
- LazySlide is an MIT-licensed Python framework that wraps whole slide image preprocessing, tiling and foundation-model feature extraction around SpatialData objects. Its value is interoperability with scanpy, anndata and squidpy; its cost is a young API surface and a hard dependency on that ecosystem.
- Who is it for?
- Adopt LazySlide if your downstream analysis already lives in anndata or scanpy and you want tissue detection, tiling and feature extraction to land in the same object model rather than in a separate slide-specific format. Do not adopt it if you need a stable, long-frozen API for a clinical pipeline, or if your work is annotation-centric and you would rather click through regions than script them.
- Can I use it commercially?
- Yes. MIT 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 17 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 LazySlide targets: slides that do not fit single-cell tooling
Digital pathology data arrives as whole slide images, files that are far too large to load into memory as a single array and that carry their own pyramid of resolutions. The single-cell and spatial transcriptomics community, meanwhile, has settled on anndata and SpatialData as the containers it knows how to manipulate, plot and share. Those two worlds have historically been bridged by ad hoc scripts: read a slide with a vendor library, cut tiles, run a model, then hand-build a table that scanpy can accept.
LazySlide is aimed at the person who already works in that second world. The README describes it as a Python framework for whole slide image analysis designed to integrate with the scverse ecosystem, and it states that it adopts standardized data structures and APIs familiar to the single-cell and genomics community. The intended user is a computational biologist who wants histology to be one more modality in a scanpy-shaped workflow, not a separate toolchain with its own conventions. The README also lists multimodal integration, combining histological data with transcriptomics, genomics and textual annotations, which is the same audience stated a second way.
What actually moves through the pipeline: SpatialData as the container
The mechanism the README makes visible is a three-stage preprocessing and feature pipeline that mutates a single object. You start with a slide handle, run find_tissues to identify tissue regions, then tile_tissues to cut the tissue into patches at a specified pixel size and microns-per-pixel scale, then feature_extraction to embed those tiles with a chosen model. The result is stored back on the same object under a key named after the model, in the quick start example resnet50_tiles, and the plotting function reads from that key.
The container is SpatialData. The README states that the framework is built on top of it and that this ensures compatibility with scanpy, anndata and squidpy. That choice is the architectural decision that matters most: features extracted from tiles are not written to a bespoke file that only LazySlide understands, they live in a structure the rest of the scverse stack can consume. The README also notes PyTorch dataloaders are provided, so the same tiles can be fed into a training loop rather than only into inference.
What the README does not document is the internal partitioning scheme, how tiles are indexed, or how coordinates are reconciled across pyramid levels. Those details would need to come from the documentation site or the source.
Getting a slide through the pipeline: the commands and keys in the README
Installation is ordinary. The README gives two options, pip install lazyslide or uv add lazyslide, and notes that a typical installation on a MacBook Pro with uv takes about four seconds. The project is also published on conda-forge, since the README carries a conda version badge, though the install section itself only spells out the pip and uv forms.
The quick start uses a bundled sample slide rather than a path, which keeps the first run short. The README gives this example:
import lazyslide as zs wsi = zs.datasets.sample() zs.pp.find_tissues(wsi) zs.pp.tile_tissues(wsi, tile_px=256, mpp=0.5) zs.tl.feature_extraction(wsi, model="resnet50") features = wsi["resnet50_tiles"] zs.pl.tiles(wsi, feature_key="resnet50", color=["1", "99"])
Two config keys are visible here and both are consequential. tile_px sets the tile edge in pixels, and mpp sets microns per pixel, which is how the framework normalises magnification across scanners that store different physical resolutions. The README reports roughly seven seconds for the whole sequence on a MacBook Pro, which is a statement about the sample slide, not about a real cohort.
For your own data the README switches libraries: from wsidata import open_wsi, then wsi = open_wsi("path_to_slide"). So the slide reader is not part of the lazyslide namespace, it comes from the separate wsidata package. The README does not enumerate which scanner formats that reader handles, and that is the first thing to check against your own files.
Foundation model support and what the model argument implies
The feature extraction step takes a model name as a string. The README's key features list names UNI, CONCH, Gigapath and Virchow as natively integrated foundation models, and mentions tasks such as zero-shot classification and captioning. It also describes the general category as state-of-the-art models, which is a claim about the field rather than something this review can verify.
The practical consequence of a string-keyed model argument is that the set of usable models is whatever the package has registered. The README does not publish that registry, does not say whether weights are downloaded automatically on first use, and does not state the licence terms attached to each model. That last point matters more than it first appears. Several pathology foundation models carry their own usage restrictions that are independent of LazySlide's MIT licence, so the permissive licence on the framework tells you nothing about whether you may use a given checkpoint in a commercial setting. The README is silent on this and it should not be read as granting anything.
The resnet50 example in the quick start is the safe default: a model you can almost certainly run without a gated download. Treat the named foundation models as a separate evaluation.
Where LazySlide is the wrong tool
The README states the framework has been tested from Python 3.11 to 3.13 via GitHub Actions on Windows, Linux and macOS, and that dependency versions are usually flexible, with the specific versions used in development recorded in pyproject.toml and uv.lock. Flexible dependency ranges plus a young release line is a combination that produces version drift. If your environment pins an older anndata or SpatialData for other reasons, the flexible range is not a guarantee that the combination works.
The release history shows why this matters. The most recent releases listed are v0.12.0 from June 2026, a release candidate v0.12.0rc0 two days earlier, and v0.11.1 from late May 2026. A project still shipping release candidates and moving through minor versions at that cadence is one where the API can shift between versions. For a research script that you rerun and fix, that is tolerable. For a validated clinical or regulated pipeline, it is a reason to pin hard and re-verify on every bump.
The second case where LazySlide is the wrong choice is annotation-heavy work. The framework is script-driven: you call functions on an object. If your actual task is drawing regions of interest by hand, reviewing slides visually, or producing annotated exports for a pathologist, a dedicated annotation application will serve you better, and the README does not present LazySlide as competing in that space.
The third is scale without a plan. The README lists scalability and high-throughput analysis as features, but the quick start demonstrates a single sample slide and no batching or distributed execution API is shown. Anyone processing a cohort should expect to build the orchestration layer themselves.
The alternative to weigh: PathML, and the difference that matters
PathML is the obvious comparison point in open source computational pathology. The difference is not feature lists, it is the container. PathML is built around its own SlideData object and its own HDF5-backed storage, with preprocessing modules that produce data in that format. LazySlide is built on SpatialData and pitches compatibility with scanpy, anndata and squidpy as the reason to choose it.
That distinction decides most cases. If your downstream analysis is a scanpy pipeline, differential expression on spatial data, neighbourhood enrichment with squidpy, or anything that expects an AnnData, LazySlide's output slots in and PathML's would need conversion. If your downstream analysis is a PyTorch training loop over tiles with no single-cell component, the container question is less important and PathML's longer history may be the deciding factor. The README does not offer a migration path from either PathML or any other slide format, so switching later means re-running preprocessing.
A second alternative worth naming is simply doing it yourself with openslide plus a tiling function plus a model call. That is perhaps forty lines. What you give up is the SpatialData structure and the plotting helpers, and what you keep is complete control and no dependency on a project at v0.12.
Licence, maintenance and what a version bump costs you
LazySlide is MIT licensed, which is permissive and imposes few obligations on how you use or redistribute the framework itself. Two caveats sit outside that licence and the README does not resolve either. The first is model weights, discussed above: MIT on the code says nothing about the checkpoints you download through it. The second is your slide data. Nothing in the licence touches patient data governance, and the README does not describe any anonymisation or de-identification step. This is not legal advice; if you are handling clinical slides, the licence question is the easy one.
On maintenance, the material supports a few concrete observations. The project is not archived, the last push recorded is August 2026, and the release cadence through mid-2026 is roughly one minor version every few weeks with release candidates in between. The README explicitly invites contributions to documentation, tests and suggestions, which is a fair signal that the documentation is not yet complete. The homepage points to a Read the Docs site with tutorials and an API reference, so the README is a front door rather than the full manual.
The upgrade cost is the part to plan for. Because the framework wraps SpatialData and anndata, a LazySlide upgrade can pull in a SpatialData upgrade, which can change the on-disk representation of objects you have already written. If you cache extracted features, record the LazySlide version alongside them, and re-run the pipeline rather than assuming an old feature table will load cleanly. The README points to pyproject.toml and uv.lock for exact development versions, which is the pair to diff when something breaks after a bump.
Editorial conclusion
Adopt LazySlide if your downstream analysis already lives in anndata or scanpy and you want tissue detection, tiling and feature extraction to land in the same object model rather than in a separate slide-specific format. Do not adopt it if you need a stable, long-frozen API for a clinical pipeline, or if your work is annotation-centric and you would rather click through regions than script them. Before committing, verify three things on your own data: that open_wsi can read your specific scanner format, that the foundation model you intend to use is reachable through the documented model argument, and that the SpatialData object produced by the preprocessing steps survives a write and read round trip in the version you pin.
Community notes