Acia-Workflows: Automated Single-Cell Analysis

Updated 4 July 2026

Acia-workflows is an open-source platform for automated single-cell imaging analysis that integrates a Python library, notebook workflows, and application templates.
The platform modularly combines eight deep learning segmentation and tracking methods with standardized interfaces to facilitate precise and flexible analysis.
Acia-workflows employs parameterized Jupyter Notebook workflows and papermill for scalable, reproducible analysis in high-throughput live-cell imaging experiments.

acia-workflows is an open-source platform for automated single-cell imaging analysis in live-cell imaging, especially microfluidic live-cell imaging experiments. It was introduced to address a specific shift in the field: deep learning methods for cell segmentation and tracking had become strong enough that the main bottleneck was no longer isolated model performance, but the integration of these methods into workflows that are accessible, reproducible, scalable, and customizable for routine biological use. The platform combines three components: the acia Python library, notebook-based workflows, and a collection of application workflows for real-world analyses. In the paper’s terminology, these components jointly support six practical workflow capabilities—accessibility, customizability, modularity, scalability, shareability, and reproducibility (ACMS2R) (Seiffarth et al., 7 Oct 2025).

1. Problem setting and scientific scope

acia-workflows is situated in the analysis of live-cell imaging (LCI) and, more specifically, microfluidic live-cell imaging (MLCI). The motivating problem is that high-throughput microfluidic setups can run tens to hundreds of parallel cultivations under controlled conditions, but the resulting time-lapse microscopy data are large enough that the relevant biological signals are obscured unless segmentation, tracking, and downstream quantification are automated (Seiffarth et al., 7 Oct 2025).

The platform is therefore not presented as a single segmentation model or a single tracker. Its purpose is to make automated single-cell analysis usable as an end-to-end workflow. The paper identifies two unsatisfactory alternatives in prior practice. One is the method-centric pipeline built around a single segmentation or tracking approach, which limits flexibility across morphologies and modalities. The other is the plugin-centered ecosystem, exemplified by flexible image-analysis environments in which users assemble pipelines manually; these are powerful, but can be difficult for beginners. acia-workflows is designed to bridge this gap by packaging method integration, analysis logic, documentation, visualizations, and execution into reusable workflows (Seiffarth et al., 7 Oct 2025).

A broader workflow perspective helps clarify why this emphasis matters. The workflows-as-code literature reports that the most common developer obstacles arise in workflow definition and workflow execution, rather than only in deployment or optimization (Yasmin et al., 2024). This suggests that acia-workflows is addressing a general workflow-engineering problem through a domain-specific biological platform: not merely how to run models, but how to make complex analysis pipelines explicit, reusable, and operational.

2. Architectural organization

The platform has a three-layer architecture. The first layer is the acia Python library, which provides the computational building blocks for image loading, segmentation, tracking, feature extraction, visualization support, and export. The second is the workflow concept, implemented as executable Jupyter Notebooks that package code, software dependencies, documentation, plots, and visual outputs into a single analysis document. The third is the application workflow collection, which provides more than ten reusable workflows and highlights three representative ones in detail (Seiffarth et al., 7 Oct 2025).

This architecture is deliberately modular. The acia library standardizes inputs and outputs so that methods can be exchanged with minimal redesign. Notebook workflows provide the user-facing analytical layer, where parameter settings, visual checks, filtering logic, scientific interpretation, and result generation are made explicit. The application collection supplies concrete templates for reuse, customization, and scaling across experiments (Seiffarth et al., 7 Oct 2025).

The notebook-centered packaging places acia-workflows within a recognizable workflow lineage. AiiDAlab, for example, also packages workflows, computational environments, and interfaces into browser-accessible applications backed by a workflow engine and provenance layer (Yakutovich et al., 2020). acia-workflows differs in scope and domain, but the shared design logic is clear: executable documents are used not only as interfaces, but as reproducible workflow containers. This suggests that acia-workflows should be understood as an analysis platform in which workflow packaging is a first-class systems decision rather than a presentation convenience.

3. Pipeline model and computational interfaces

The core data model in acia represents a time-lapse as a $T \times H \times W \times C$ array, where $T$ is time, $H$ and $W$ are image dimensions, and $C$ is the number of channels (Seiffarth et al., 7 Oct 2025). The library introduces an ImageSequenceSource interface that iterates over time and yields per-frame images as NumPy arrays of shape $H \times W \times C$ . This establishes a standard representation for heterogeneous microscopy inputs, including local data, custom formats, and OMERO-backed image stacks (Seiffarth et al., 7 Oct 2025).

On top of this representation, acia implements a multi-step analysis pipeline. In the paper’s practical formulation, the workflow proceeds through loading data, segmenting cells, tracking cells, extracting features, and deriving and visualizing biological insights. In software terms, this expands into data loading, preprocessing or custom loading logic, instance segmentation, tracking, feature extraction, quantification, visualization, and downstream analysis (Seiffarth et al., 7 Oct 2025).

Two interface abstractions are central. A SegmentationProcessor takes an ImageSequenceSource and produces an Overlay of cell instances, represented for example as masks or polygon contours. A TrackingProcessor consumes the image sequence and segmentation overlay and produces a lineage as a networkx.DiGraph (Seiffarth et al., 7 Oct 2025). The tracking representation has both a detection-level graph and a tracklet-level graph, making the platform suitable not only for object linking but for lineage reconstruction.

The paper states that acia integrates eight deep learning segmentation and tracking approaches through these interfaces. The four segmentation methods are Cellpose, CellposeSAM, Omnipose, and CPN. The four tracking methods are LAP, Trackastra, PyUAT, and Ultrack (Seiffarth et al., 7 Oct 2025). This is one of the platform’s defining properties: it is not committed to a single segmentation or tracking stack, but to modular interchangeability under common interfaces.

Feature extraction is built around standard scientific Python data structures. acia produces linked Pandas tables for segmentation-level and tracking-level features, connected through a "label" column identifying the tracklet. Extracted features include cell location, area, length, perimeter, fluorescence, age, birth size, and division size. The platform uses pint to make feature extraction unit-aware, so physical units can be derived from microscopy metadata such as camera calibration and frame interval (Seiffarth et al., 7 Oct 2025).

4. Workflow execution, scaling, and reproducibility

In acia-workflows, a Jupyter Notebook is itself treated as a workflow. Each workflow packages code, software dependencies, explanatory text, figures, visual outputs, and custom analysis logic into a single executable document (Seiffarth et al., 7 Oct 2025). This provides the operational basis for several ACMS2R properties.

Accessibility is achieved because workflows can be executed in a web browser, including Google Colab with GPU acceleration. Customizability follows from the ability to modify notebook cells and insert short Python snippets for loading, filtering, or domain-specific analysis. Reproducibility follows because the executed workflow records code, parameter settings, plots, and outputs in one place. Shareability follows because the notebook can be distributed as a complete analytical artifact (Seiffarth et al., 7 Oct 2025).

The paper gives special attention to scalability. High-throughput MLCI experiments typically involve multiple time-lapses or parallel cultivation chambers, so a workflow that only analyzes one recording is insufficient. acia-workflows addresses this through a scaling mechanism based on notebook parameterization and papermill. A workflow is parameterized by a unique time-lapse identifier; papermill then executes the notebook repeatedly for different inputs, stores the executed notebook for each run, and supports aggregation of results across all runs in a separate scaling workflow (Seiffarth et al., 7 Oct 2025).

This scaling model is lightweight but consequential. It transforms a notebook from a one-off analysis script into a reusable workflow template that can be systematically instantiated across replicates. It also creates a persistent execution record per time-lapse, which functions as a practical provenance artifact even though the platform is not framed as a full provenance graph system (Seiffarth et al., 7 Oct 2025). In a broader workflow context, related HPC work has emphasized that metadata reorganization is a core systems function rather than an afterthought (Shpilker et al., 18 Jun 2025). acia-workflows takes a notebook-centered route to the same practical concern: preserving the structure and outputs of each run so that scaling does not destroy interpretability.

5. Application workflows and scientific use cases

The paper highlights three representative workflows.

Workflow	Main analytical goal	Representative methods
Population growth quantification	Compare image-derived growth measures	Omnipose segmentation
Co-culture characterization	Separate fluorescent sub-populations and compare growth	Omnipose segmentation, fluorescence features, k-means
Oxygen-switch single-cell dynamics	Quantify rapid individual-cell response to changing oxygen	Omnipose segmentation, Trackastra tracking

The first workflow studies how to quantify microbial population growth from time-lapse data. It compares cell count (CC), total colony area (TCA), and total single-cell area (TSCA) using C. glutamicum data from the “Tracking One in A Million” dataset. The pipeline uses Omnipose for segmentation, artifact filtering by cell-size thresholds, extraction of CC/TCA/TSCA time series, and log-linear growth fitting. All three measures indicate exponential growth, but they behave differently: CC exhibits staircase behavior because of synchronous division, TCA is smoother but depends on colony packing, and TSCA is the smoothest and best aligned with the log-linear model. The paper also notes that CC is highly sensitive to under- and over-segmentation, whereas TCA and TSCA are more robust to over-segmentation because area is summed (Seiffarth et al., 7 Oct 2025).

The second workflow analyzes co-cultures of two C. glutamicum strains marked by mVenus and E2-Crimson fluorescence. The workflow uses Omnipose, extracts mean fluorescence intensity per cell, filters non-fluorescent particles and artifacts, computes median-cell fluorescence, and applies k-means clustering to classify cells into the two fluorescent classes (Seiffarth et al., 7 Oct 2025). The scaled analysis over eight replicates yields TSCA growth-rate estimates of $0.477~h^{-1} \pm 0.026$ for mVenus and $0.473~h^{-1} \pm 0.030$ for E2-Crimson, leading the authors to conclude that there is no systematic growth-rate difference attributable to the fluorescent labels (Seiffarth et al., 7 Oct 2025).

The third workflow moves from population summaries to single-cell dynamics in an oxygen-switching experiment on E. coli. It uses Omnipose for segmentation and Trackastra for tracking, then corrects over-segmentation and restricts analysis to cells observed over their full life cycle. The workflow extracts single-cell area trajectories and computes an instantaneous growth rate (IGR) from frame-to-frame area changes over elapsed time; the supplementary expression is reported in the paper as malformed, but the intended quantity is the finite-difference growth rate from consecutive area measurements (Seiffarth et al., 7 Oct 2025). The main biological result is that individual cells show a rapid and consistent decrease in IGR within minutes after switching from 21% $O_2$ to 0% $O_2$ , and this pattern remains visible across five scaled replicates (Seiffarth et al., 7 Oct 2025).

Together, these workflows demonstrate the platform’s range: population-level growth inference, fluorescence-based sub-population analysis, lineage-aware single-cell dynamics, and perturbation-centered temporal quantification.

6. Limitations and position within workflow research

The paper is explicit about several limitations. acia is currently designed mainly for 2D+t data, so direct support for volumetric workflows is limited. Customization still requires writing Python, even if the required snippets are intended to be short. The showcased workflows focus on bacterial systems, although the framework itself is not claimed to be bacteria-specific. Finally, workflow quality still depends on segmentation and tracking quality; filtering, artifact correction, and visual inspection remain necessary in practice (Seiffarth et al., 7 Oct 2025).

The planned directions are correspondingly concrete: extension to 3D segmentation and tracking, support for broader morphologies and imaging modalities, and continued expansion of the workflow collection (Seiffarth et al., 7 Oct 2025).

Within the broader workflow literature, acia-workflows occupies a distinctive position. It is not a generic orchestration engine such as Airflow, nor an asynchronous human-AI framework such as CIF, nor a workflow metadata substrate for HPC observability. Instead, it is a domain-specific scientific workflow platform that packages modular image-analysis methods, executable notebook workflows, and reusable application templates into a system for routine biological analysis (Mendoza et al., 5 May 2026). This suggests that its central contribution is not algorithmic novelty in segmentation or tracking alone, but the conversion of those methods into workflows that can be executed, scaled, inspected, and reused by life-science practitioners.

In that sense, acia-workflows is best understood as a workflow integration platform for single-cell live-cell imaging. Its significance lies in making deep learning-based analysis operational: not only segmenting and tracking cells, but doing so through documented, parameterized, scalable workflows that preserve analytical context and support routine scientific use (Seiffarth et al., 7 Oct 2025).