scikit-image: Image Processing in Python, From pip Install to Segmentation

What scikit-image solves, and who it is written for

The library answers a narrow question: given an image already loaded as a NumPy array, which algorithm do I apply, and what comes back? Every operation works on arrays and returns arrays, so results compose with the rest of the scientific Python stack without a conversion layer. That is a different posture from a general computer vision toolkit. The README describes the project simply as "Image processing in Python" and points to scikit-image.org for documentation. The audience follows from the dependency list in pyproject.toml: numpy>=2.1, scipy>=1.15, networkx>=3.0, pillow>=10.1, imageio>=2.33, tifffile>=2025.1.10, packaging>=24, lazy-loader>=0.5. Someone already doing numerical work in Python is the intended reader, not someone looking for an application to open photographs in. The classifiers name the audience directly: Intended Audience :: Developers and Intended Audience :: Science/Research. If you work with microscopy stacks, satellite tiles, or any measured raster that arrives as an array, the fit is immediate. If you want a GUI, it is not here.

How the library is put together: arrays in, arrays out

The repository layout shows a compiled core under src/ with Python modules layered over it. The build dependencies are the tell: meson-python, ninja, Cython>=3.0.10 and pythran>=0.16 all appear in the build extra, so parts of the library are compiled rather than pure Python. That has a practical consequence at install time: wheels exist for common platforms, but a source build needs a working compiler toolchain, and the pyproject.toml lists C as a programming language alongside Python. The data flow is conventional for the ecosystem. imageio and tifffile handle reading and writing, pillow covers common formats, and everything downstream operates on ndarray objects. networkx is a less obvious dependency, but it is there because some routines are graph problems in disguise, such as finding connected components or tracing paths through a skeleton. lazy-loader is used so that submodules are imported on first access instead of at import time, which keeps the initial import cheaper. The documentation states that the package supports Python 3.12 through 3.15 per the classifiers, and requires-python in pyproject.toml confirms '>=3.12'. That floor is high compared with many libraries, and it is worth checking before you plan an upgrade.

Installing scikit-image with pip or conda

The README gives two installation routes. The pip route is a single command, and the conda route pulls from conda-forge. Both are quoted verbatim below; there is no separate installer, and the README points to INSTALL.rst for anything beyond these two lines.

pip install scikit-image

The conda equivalent, for environments managed by conda:

conda install -c conda-forge scikit-image

The README does not include a first-use example, so the next step is the documentation site it links to, https://scikit-image.org/docs/stable/, which carries the worked examples for loading a sample image, filtering it, and thresholding it. What you should confirm after either command is that the import resolves in the same interpreter you installed into; installing into a different interpreter than a notebook kernel is the most common reason an import fails. The repository also provides an environment.yml and a requirements.txt that fans out into default, build, test and developer requirement files, which is the route for a source checkout rather than for a user install.

Where scikit-image is the wrong tool

Three boundaries are worth stating plainly. First, the library is not a real-time video system. There is no capture device abstraction in the dependency list, and no frame loop in the README. If your problem is decoding a camera stream at 30 frames per second, the array-in, array-out design is the wrong shape, and you will spend your time building the plumbing around it. Second, it is not a pipeline runner. There is no configuration format for chaining operations, no scheduler, and no way to declare a processing graph in a file. You write Python, and the order of operations lives in your code. For a one-off analysis that is fine; for a production batch system you will likely want a workflow tool on top. Third, the installation is not trivial on every platform. Because the build extra pulls in Cython and pythran, environments without prebuilt wheels need a compiler. The README does not document a rollback procedure for a failed upgrade, so pinning versions in your own environment file is the practical safeguard.

scikit-image versus OpenCV: different defaults, different jobs

The comparison people search for most often is scikit-image against OpenCV, and the difference is in the defaults rather than in the algorithm list. Both implement filtering, morphology, edge detection and segmentation. OpenCV is built around its own matrix type and optimises for throughput on video and for deployment into C++ applications; its Python bindings are one interface among several. scikit-image is built around NumPy arrays and optimises for readability of the calling code and for correctness of the numerical result. The practical consequence is that scikit-image code reads like the textbook description of the algorithm, with named parameters, while OpenCV code tends to be shorter and closer to the metal. A second difference is licensing posture: the pyproject.toml classifier states 'License :: OSI Approved :: BSD License', and the repository carries LICENSE.txt, while the GitHub metadata for this repository reports NOASSERTION, which means the platform could not match the file to a known licence automatically. Read LICENSE.txt itself rather than the badge. If your constraint is a permissive licence, the BSD classifier is the relevant fact; if your constraint is latency on a live feed, OpenCV is the more direct answer.

Release cadence, version pinning and licence implications

The most recent release in the repository metadata is v0.26.0, published on 2025-12-20, preceded by two release candidates in the same month. The last push to the default branch was on 2026-09-09, which is recent enough that the project is clearly still receiving commits, but the release history is the number that matters when you plan an upgrade: a minor version bump from 0.25 to 0.26 can carry deprecations, and the project's own release notes are the place to check them. Because the version field is dynamic in pyproject.toml, the installed version is set at build time, so `pip show scikit-image` is the reliable way to see what you actually have. The dependency floor is the upgrade cost to watch. numpy>=2.1 and scipy>=1.15 mean that adopting a current scikit-image can force a NumPy upgrade in an environment that is still on 1.x, and that upgrade can break other packages in the same environment. Plan the bump across the whole environment, not just this package. On licensing, the BSD classifier in pyproject.toml indicates a permissive licence, but the metadata field reports NOASSERTION, so the file LICENSE.txt is the authority. This is not legal advice; read the licence text and your own obligations.

How to cite scikit-image in a paper

The README gives the citation directly, so there is no ambiguity to resolve. It asks users to cite van der Walt, Schönberger, Nunez-Iglesias, Boulogne, Warner, Yager, Gouillart, Yu and the scikit-image contributors, in PeerJ 2:e453 (2014), with the DOI 10.7717/peerj.453. The repository also carries a CITATION.cff file at the top level, which is the machine-readable form of the same information and is what reference managers and GitHub's citation widget read. If you are writing a methods section, the version you ran matters as much as the paper: state the version number from `pip show scikit-image`, because algorithm defaults have changed across releases and a reader reproducing your work needs to know which one you used. The README does not ask for a separate citation per module, so one reference for the library is the expected practice.

Editorial conclusion

Adopt scikit-image when your data is already a NumPy array and you want algorithms that return arrays, not a viewer or a pipeline runner. Do not adopt it when your input is a video stream, a camera feed, or a folder of files you want processed by a graphical application; the library has no such entry point. Before committing, verify that your Python is 3.12 or newer, since pyproject.toml sets requires-python to '>=3.12', and confirm that the algorithms you need appear in the stable documentation rather than in a tutorial you found elsewhere.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. scikit-image/scikit-image on GitHub