# cuCIM puts whole-slide image processing on the GPU

> NVIDIA's RAPIDS library for GPU-accelerated, multidimensional image processing and IO, built for whole-slide TIFF formats in biomedical and geospatial work, with an OpenSlide-compatible reading API.

**rapidsai/cucim** — cuCIM - RAPIDS GPU-accelerated image processing library

- Repository: https://github.com/rapidsai/cucim
- Website: https://docs.rapids.ai/api/cucim/stable/
- Stars: 469 · Forks: 92
- Language: Jupyter Notebook
- License: Apache-2.0
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/rapidsai-cucim

## Whole-slide images are an IO problem as much as a GPU problem

A single digital pathology slide is a TIFF file measured in gigapixels, too large for memory and too deep for naive readers, and the same multidimensional TIFF pattern recurs in geospatial and remote-sensing data. cuCIM, part of NVIDIA's RAPIDS ecosystem, attacks both halves of that problem: GPU-accelerated image processing and computer vision primitives for multidimensional images, and fast reading of the large, tiled TIFF formats those fields actually use.

The README names the target domains plainly: biomedical, geospatial, material and life science, and remote sensing. Two headline capabilities matter for practitioners: enhanced handling of large n-dimensional TIFF files, and an interface whose reading API matches OpenSlide, the de facto standard library for whole-slide images. That second promise is the adoption path: code written against OpenSlide's conventions can move to GPU-backed reading without learning a new object model.

## Installing: conda or pip, CUDA 12 or 13

Installation follows the RAPIDS conventions. The conda route pulls from the rapidsai channel:

```bash
conda create -n cucim -c rapidsai -c conda-forge cucim cuda-version=`<CUDA version>`
```

with the README specifying CUDA 12.0 or newer, and a rapidsai-nightly channel serving nightly builds with the same shape. The pip route splits by CUDA generation, with one package per major runtime:

```bash
pip install cucim-cu12
pip install cucim-cu13
```

Both CUDA 12 and CUDA 13 are covered, which resolves the usual RAPIDS install question, which wheel matches my driver, into a one-look answer. Building from source is documented through the contributing guide, and the repository carries the infrastructure you would expect from an NVIDIA-adjacent project: CI, benchmarks, a changelog and a version file.

## cuslide2 and the deprecation clock

The TIFF reading layer is in transition, and the README puts the dates in writing. Since version 26.04, the original cuslide plugin is deprecated in favor of cuslide2, with cuslide's removal planned for 26.08. cuslide2 decodes through NVIDIA's nvImageCodec for GPU-accelerated TIFF decoding and adds tile-level caching, asynchronous batch decoding and broader format support.

Migration is an environment variable:

```bash
ENABLE_CUSLIDE2=1 python your_script.py
```

The README also ships verification scripts so the switch is not a leap of faith: test_aperio_svs.py can download a sample SVS file and run against it, and test_philips_tiff.py exercises Philips TIFF files, both honoring the cuslide2 flag. The lesson generalizes beyond this project: when a storage plugin is being replaced, published timelines, sample files and per-format test scripts are what make a migration a checklist instead of an investigation.

## Formats, and the OpenSlide contract

Format support is enumerated precisely. Aperio ScanScope Virtual Slide, the SVS format dominating digital pathology, is supported, as is Philips TIFF, along with generic tiled, multi-resolution RGB TIFF using no compression, JPEG, JPEG2000, LZW or Deflate. That list covers the practical majority of whole-slide workflows, with the compression matrix telling you whether your archive's flavor decodes on the GPU path.

The API compatibility claim is aimed squarely at migration friction: a matching API for OpenSlide means the reading layer slots into code that already speaks OpenSlide, which is most of the digital pathology Python world. Processing-side, the connection to scikit-image is by positioning: NVIDIA's own blog frames cuCIM as accelerating the scikit-image style of n-dimensional image processing on GPUs, and the documentation site carries the API references. Multidimensionality is native rather than bolted on, since the library was designed for images whose Z, time and channel axes matter as much as X and Y.

## First run: the Welcome notebook

The on-ramp is a notebook. notebooks/Welcome.ipynb, also viewable on NBViewer, walks the API basics, and the README includes the commands to fetch sample images, noting Docker is required because the test data ships in a container image:

```bash
./run download_testdata
```

or, for the equivalent manual steps:

```bash
mkdir -p notebooks/input
tmp_id=$(docker create gigony/svs-testdata:little-big)
docker cp $tmp_id:/input notebooks
docker rm -v ${tmp_id}
```

The container-based sample delivery is a small decision with real consequences: SVS test files are large and licensed awkwardly, and shipping them in a disposable image sidesteps both problems. Combined with the GTC and SciPy talks linked from the README, including the 2021 SciPy talk where the project was introduced, the first-run path is unusually complete for a systems library.

## Maintenance and provenance

The provenance is as solid as open source gets: Apache-2.0 licensed, copyright NVIDIA Corporation from 2020 to 2026, part of the RAPIDS suite with its developer page, and a LICENSE-3rdparty.md documenting the third-party components. The repository runs the full enterprise hygiene stack: SECURITY.md, CONTRIBUTING.md, pre-commit configuration, clang-format for the C++ portions, benchmarks, CI workflows and a VERSION file, with release notes published on the project wiki.

Activity is current: the last push was on 2026-09-10, with three releases in the recent window. The long view also matters here; the project has been presented publicly since SciPy 2021 and GTC 2021, so this is not a promising prototype but a five-year-old component of a larger platform, with the stability and the corporate priorities that imply. Teams adopting it are plugging into RAPIDS' release train, which is a benefit and a coupling at the same time.

## Against OpenSlide, scikit-image and CPU pipelines

The alternatives are the CPU world cuCIM accelerates. OpenSlide remains the reference reader for slide formats, stable and dependency-light, and it is the right choice when throughput is adequate; cuCIM's matching API exists precisely so the switch is cheap when it stops being adequate. scikit-image owns CPU-side n-dimensional processing with an enormous algorithm surface, and cuCIM is not replacing it wholesale, it accelerates the operations where GPUs pay, which is why NVIDIA frames the relationship as acceleration rather than replacement.

The decision reduces to where your minutes go. If your pipeline reads a handful of slides and runs classical processing, CPU tooling is simpler and sufficient. If you tile thousands of whole-slide images, decode JPEG2000 constantly, or feed GPU training loops that stall on IO, the GPU decode and processing path pays for its CUDA constraint. The honest evaluation is a profile of your current pipeline: find whether wall-clock time hides in file IO, where cuCIM's reading layer is aimed, or in compute, where its processing primitives apply.

## Conclusion

cuCIM fits teams processing large multidimensional TIFF data, whole-slide pathology above all, who already run CUDA 12 or 13 GPUs and want GPU decode and processing with an OpenSlide-compatible reading API. Skip it on CPU-only infrastructure, for formats outside its supported list, or when your pipeline's bottleneck is neither IO nor the processing primitives it accelerates. Verify the fit on real data: install the pip package matching your CUDA, enable cuslide2, run the project's SVS and Philips test scripts against one of your own slides, and profile the wall-clock difference before rewriting anything.

## FAQ

### How do I install cuCIM?

Via conda from the rapidsai channel with cuda-version set to 12.0 or newer, or via pip with the package matching your runtime: cucim-cu12 for CUDA 12 and cucim-cu13 for CUDA 13. Nightlies are on the rapidsai-nightly channel.

### What is the relation between cuCIM and scikit-image?

cuCIM's README promises a matching API for OpenSlide on the reading side, and NVIDIA's blog positions the library as accelerating the scikit-image style of n-dimensional image processing on GPUs rather than replacing it wholesale.

### What is cuslide2 in cuCIM?

The new TIFF plugin, decoding through nvImageCodec with tile-level caching and asynchronous batch decoding, enabled by setting ENABLE_CUSLIDE2 to 1. The original cuslide is deprecated since 26.04 with removal planned for 26.08.

## Sources

- [License: Apache-2.0](https://github.com/rapidsai/cucim/blob/main/LICENSE)
- [Project website](https://docs.rapids.ai/api/cucim/stable/)
- [rapidsai/cucim on GitHub](https://github.com/rapidsai/cucim)
- [README](https://github.com/rapidsai/cucim/blob/main/README.md)
- [Releases](https://github.com/rapidsai/cucim/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rapidsai-cucim