PlantCV: image analysis for plant phenotyping

What PlantCV is for

PlantCV is an open-source image analysis software package targeted at plant phenotyping. The README describes it as providing a common programming and documentation interface to a collection of image analysis techniques integrated from a variety of source packages and algorithms.

That sentence is the whole pitch. Measuring plant traits from images is not one algorithm, it is dozens: colour segmentation, shape descriptors, texture measures, object detection, count estimation, growth over time. Each of these exists as research code somewhere. PlantCV gathers them behind one namespace and one set of documentation, so a lab does not have to reimplement the plumbing for every trait it measures.

The audience is a plant research group, and the workflows it serves are the ones where images arrive by the thousand from a phenotyping platform or a field trial and a consistent measurement has to come out of them. The homepage is plantcv.danforthcenter.org, and the README points there for recorded presentations and for a list of publications that used the package.

The point about the common interface is not cosmetic. If two labs each implemented their own leaf area measurement, the numbers are not comparable across papers. A shared implementation is what makes a trait number in a paper mean something to the next lab.

The modular workflow design

The README states that PlantCV utilizes a modular architecture that enables flexibility in the design of analysis workflows and rapid assimilation and integration of new methods.

In practice this means a workflow is a composition of small units rather than a single large function that does everything. Each step produces a result that the next step consumes, and a new measurement technique can be added as another unit without rewriting the pipeline around it. For a research group, the practical effect is that adding a new trait to an existing workflow is a small change rather than a rewrite, and the existing measurements keep producing the same numbers.

The package itself lives under the plantcv/ directory, with the CLI entry points declared in pyproject.toml pointing at subpackages named parallel, learn and utils. The presence of an AGENTS.md at the root of the repository, alongside a Dockerfile, a.deepsource.toml and a.coveragerc, gives a fairly clear picture of how the project is worked on.

There is also a vice/ directory at the top level, and the docs/ directory with mkdocs.yml at the root is what produces the documentation site at docs.plantcv.org, whose badge in the README points at the stable version.

Installing PlantCV and the command line entry points

PlantCV is distributed through several channels, and the README lists all of them: GitHub, PyPI, Conda-forge and Zenodo for a citable archive with its own DOI. The installation instructions live in the documentation at docs.plantcv.org/installation/, and the environment.yml at the repository root is the conda environment definition.

The dependencies in pyproject.toml explain the shape of the install. The numeric and scientific stack is numpy, scipy, pandas, scikit-image, scikit-learn and statsmodels, with matplotlib for plotting and opencv-python pinned to a version at or below 4.12. The dask and dask-jobqueue entries are the reason the parallel entry point exists, xarray with a 2022.11.0 floor handles labelled arrays, and altair with vl-convert-python produce the interactive charts. There are also two domain specific dependencies, nd2 and flyr.

Python 3.8 is the minimum, and the package classifies itself as intended audience science and research with development status production and stable.

Three console scripts are installed with the package, and they are the quickest way to see what the non-notebook surface looks like.

plantcv-run-workflow = "plantcv.parallel.cli:main"
plantcv-train = "plantcv.learn.cli:main"
plantcv-utils = "plantcv.utils.cli:main"

The parallel entry point runs a workflow across many images, the train entry point handles the machine learning side, and the utils entry point holds the smaller helper commands.

The container image for reproducible batch runs

The Dockerfile at the repository root is built for the batch case, and it is worth reading because it shows how the maintainers expect a large run to be executed.

FROM jupyter/minimal-notebook
LABEL maintainer="PlantCV <[email protected]>"

The base image is the Jupyter minimal notebook image, so the container ships with a notebook server and the analysis environment together. The maintainer label points at the PlantCV team address.

Two details in the middle of the file are the practical ones. The image installs libgl1-mesa-glx, which is the system library OpenCV needs for its headless operations, and it removes the opencv entries from requirements.txt with a sed substitution before running the conda install, because the conda-forge opencv package is the one the image wants. Conda then installs from that file with `--file requirements.txt`.

The result is an environment where the same version of every dependency is pinned in the image rather than resolved on each machine, which is what makes a measurement reproducible across a group. The image runs as the non-root notebook user at the end, so a mounted dataset has to be writable by that user.

For a group that has to re-run an analysis a year later, this container is a better reproducibility story than a conda environment on a laptop, because the whole dependency closure is captured in one artefact.

Machine learning and the parallel execution path

Two of the three console scripts point at capabilities that matter for a phenotyping lab.

The learn package, exposed as plantcv-train, is the machine learning side of the project. The pyproject keywords list image analysis and computer vision, and the package's own description in the project metadata is "PlantCV: Plant phenotyping with computer vision", so the learning models are trained on image features for trait prediction rather than being a separate add-on. The v5.0.0 release candidate naming and the presence of a vice/ directory suggest a version in which the analysis surface is being reorganised.

The parallel package, exposed as plantcv-run-workflow, is what makes a phenotyping run finish in a reasonable time. The dask and dask-jobqueue dependencies are there to distribute workflow execution across workers, and a job queue scheduler is the usual way to give a lab access to a cluster without every user learning to submit jobs by hand. For a group with a shared cluster, that difference is the difference between an analysis that runs overnight and one that runs in an afternoon.

The utils package holds the smaller commands. In a project of this shape the utility layer is usually where the input and output handling lives, the file naming conventions and the coordinate transforms, and the data formats that the trait functions expect.

Where PlantCV is the wrong tool

The first limitation is the size of the dependency set. numpy, scipy, pandas, scikit-image, scikit-learn, statsmodels, matplotlib, opencv, dask, xarray, altair, nd2 and flyr is a heavy install for a task that may be measuring leaf area in one image. For a one-off measurement, a notebook with scikit-image alone is faster to reach for.

The second is the learning curve of the pipeline model. A modular workflow is a good design for a lab that will measure many traits, and it is a real cost for a user who wants one number. The documentation, the tutorial gallery and the recorded presentations all exist, and there is a learning curve in them.

The third is the version churn. The recent releases are v5.0.0rc2 from 2026-08-12, v4.11.3 from 2026-07-10 and v4.11.2 from 2026-06-29. A release candidate sitting next to a maintained 4.11.x line means two API generations are in circulation, and the README links a dedicated updating and changelog page, which is what a project with breaking changes points you to. Code written against 4.x may not run unchanged on 5.x, and a group with a long-running analysis pipeline needs to plan for that.

The fourth is that the dependency pins are strict in places. opencv-python is capped at 4.12, scipy below 1.16, altair below 6 and pandas excludes 3.0.4, and there is a named version floor on xarray. Those caps exist because something in the package breaks otherwise, and they will collide with an environment that already needs a newer version of one of those libraries.

The fifth is the scope of the claim. PlantCV measures things from images. It does not replace a controlled growth environment, and it cannot tell a plant that is drought stressed from one that is nutrient deficient. A trait number from an image is only as good as the calibration behind it.

How PlantCV compares with FIJI, VitisVision and a plain scikit-image script

FIJI and ImageJ is the tool most plant scientists already have open, and the difference in approach is the difference between an interactive desktop application and a library. FIJI gives a scientist a menu and a macro language for measuring things on an image, and it is fast for a one-off. PlantCV is a library, so a measurement runs inside a script that can be applied to a directory of images, versioned in a repository, and re-run when the algorithm changes. For a lab producing thousands of images per week, the script is the only workable shape.

The choice often comes down to whether the measurements need to run unattended on a cluster or in a script, which is where a library like PlantCV fits.

A plain scikit-image script is the third comparison, and it is the honest one. For a single trait, scikit-image has the algorithms and writing the measurement yourself gives full control. What you lose is the common interface and the shared implementation: your leaf area code and the next lab's leaf area code will differ, and the comparability that makes a published trait number useful is gone. PlantCV is worth the dependency weight when the measurement has to match other people's.

Licence, releases and what to check before building on it

The licence field on the repository records MPL-2.0, and the pyproject classifiers name the same licence, Mozilla Public License 2.0. The MPL is a file copyleft licence: modifications to the covered files must be published under the MPL, while a larger work that merely imports PlantCV is not forced into the same terms. For a research group that intends to modify the measurement code and share it, that is the licence that makes modification and redistribution straightforward, and it is the reason the pyproject explicitly points at a LICENSE file rather than an SPDX string.

The repository is not archived and the last push was on 2026-10-22, so the project is actively worked on. It has a Contributor Covenant 2.1 code of conduct, a DeepSource configuration with a code coverage badge, a build workflow, and a Zenodo archive with a DOI for citation. The README asks users to cite the PlantCV publications and links a list of publications that used the package, which is a good sign for a project that wants its measurements to be traceable in the literature.

Four things to check before building a pipeline on it. Which API generation you are targeting, because the 5.0.0 release candidate and the 4.11.x line differ, and whether the v5 changes touch the trait functions you use. Whether your environment can satisfy the dependency caps, especially opencv-python at or below 4.12 and scipy below 1.16. Whether the parallel path fits your hardware, because dask-jobqueue is aimed at a scheduler rather than a laptop. And whether the public image datasets linked from the README, hosted at datasci.danforthcenter.org, give you ground truth to validate a new trait measurement against, because an unvalidated trait number is just a number.

Editorial conclusion

PlantCV suits a plant research group that measures many traits from many images and wants the same measurement code applied consistently across a growing image set, especially when machine learning is part of the pipeline. It is a poor fit for a one-off visual inspection of a handful of images, where a notebook and scikit-image would be faster to reach for, and a poor fit for a project that needs the traits to be identical to another group's implementation without checking the versions. Before adopting it, read the updating and changelog page, because the 5.0.0 release candidate sits alongside the 4.11.x line and the API has changed across major versions.

Frequently asked questions

Official sources

1. danforthcenter/plantcv on GitHub
2. Issues
3. License: MPL-2.0
4. README
5. Releases