{
  "markdown": "<!-- mcp-name: io.github.OpenHCSDev/openhcs -->\n\n<div align=\"center\">\n\n<img src=\"openhcs/resources/assets/openhcs-icon-square.svg\" width=\"132\" alt=\"OpenHCS array-processing logo\">\n\n<h1>OpenHCS</h1>\n\n**Turn high-content microscopy images into reproducible measurements**\\\n**One reviewable workflow across the GUI, Python, CellProfiler, and local agents**\n\n[![PyPI version](https://img.shields.io/pypi/v/openhcs.svg)](https://pypi.org/project/openhcs/)\n[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)\n[![Python 3.11-3.13](https://img.shields.io/badge/python-3.11--3.13-blue.svg)](https://www.python.org/downloads/)\n[![GPU Accelerated](https://img.shields.io/badge/GPU-Accelerated-green.svg)](https://github.com/OpenHCSDev/OpenHCS)\n[![Documentation](https://readthedocs.org/projects/openhcs/badge/?version=latest)](https://openhcs.readthedocs.io)\n\n</div>\n\nOpenHCS is designed for imaging scientists and research software teams running\nhigh-content studies where many wells, sites, channels, Z planes, or time points\nmust be analysed consistently. Source selection, processing steps, and result\ndefinitions stay together in one validated pipeline instead of being split\nacross interface-only state, scripts, and automation.\n\nIt is a good fit when a workflow must remain reviewable across visual editing,\ncode, and automation. The same pipeline can be edited in the desktop GUI or as\nPython, imported from supported CellProfiler `.cppipe` files, and built or\nreviewed through the local MCP surface.\n\n### Install\n\n[**Windows installer**](https://github.com/OpenHCSDev/OpenHCS/releases/latest/download/OpenHCS-Windows-Installer.exe) ·\n[**macOS installer**](https://github.com/OpenHCSDev/OpenHCS/releases/latest/download/OpenHCS-macOS-Installer.dmg) ·\n[**Installation options**](https://openhcsdev.github.io/openhcs/#install)\n\nThe graphical installers set up an isolated CPU-safe desktop environment with\nthe OpenHCS GUI, CellProfiler compatibility, local MCP server, Napari,\nFiji/ImageJ, and Bio-Formats. GPU libraries remain optional.\n\n---\n\n## See OpenHCS in use\n\n[![OpenHCS desktop application with several assay plates](website/assets/gallery/multi-plate-overview.webp)](https://openhcsdev.github.io/openhcs/#gallery)\n\n[Browse the UI and viewer gallery](https://openhcsdev.github.io/openhcs/#gallery) ·\n[Watch an agent build, debug, run, and inspect a workflow](https://openhcsdev.github.io/openhcs/#mcp)\n\n---\n\nOpenHCS processes large microscopy datasets with a **compile-then-execute**\narchitecture. Pipelines are validated across the selected execution axes *before*\nprocessing starts, preventing late failures after expensive work. Design\npipelines in the GUI, export to Python, edit as code, and re-import — switching\nbetween visual and programmatic workflows. The local MCP exposes that same\nworkflow model to supported agents, so agent-authored pipelines remain visible,\neditable, and reviewable in the GUI and generated Python.\n\n```mermaid\ngraph LR\n    subgraph Sources\n        IX[ImageXpress]\n        OP[Opera Phenix]\n        BF[Bio-Formats]\n        OM[OMERO]\n    end\n\n    subgraph OpenHCS Platform\n        PD[\"Pipeline Designer<br/>(GUI ⇄ Code ⇄ Agent)\"]\n        CO[\"Typed Compiler<br/>(resolve + validate)\"]\n        EX[\"Bounded Worker Executor<br/>(well scheduling · multi-GPU)\"]\n        FN[\"Registry-Discovered Functions<br/>scikit-image · CuPy · pyclesperanto<br/>PyTorch · JAX · TF · CuCIM · custom\"]\n        PS[\"PolyStore<br/>(Memory ↔ Disk ↔ Zarr ↔ Stream)\"]\n    end\n\n    subgraph Viewers\n        NA[Napari]\n        FJ[Fiji/ImageJ]\n    end\n\n    IX --> PD\n    OP --> PD\n    BF --> PD\n    OM --> PD\n    PD --> CO --> EX\n    EX --> FN --> PS\n    PS --> NA\n    PS --> FJ\n```\n\n---\n\n## ⚡ Key Capabilities\n\n<table>\n<tr>\n<td width=\"50%\" valign=\"top\">\n\n### 🛡️ Compile-Time Validation\nConfiguration is resolved once into step snapshots and a compilation session. Typed plans then validate sources, artifacts, materialization, memory contracts, and worker requirements before execution begins. Errors surface immediately, not after hours of processing.\n\n</td>\n<td width=\"50%\" valign=\"top\">\n\n### 🔄 Bidirectional GUI ↔ Code\nDesign pipelines visually, export as executable Python, edit in your IDE, re-import to the GUI. Code generation works at **any scope level** — function patterns, individual steps, pipeline configs, full orchestrator scripts — any window holding objects can generate and re-import code.\n\n</td>\n</tr>\n<tr>\n<td width=\"50%\" valign=\"top\">\n\n### 🧠 Agent-Assisted Workflows\nGive a supported MCP client a microscopy folder or plate and an analysis goal. It can inspect the connected execution server's functions, build and validate a typed pipeline, run it, inspect results in OpenHCS or a viewer, and revise the generated Python.\n\n</td>\n<td width=\"50%\" valign=\"top\">\n\n### ⚡ Multiprocessing & GPU Acceleration\nBounded worker lanes use `ProcessPoolExecutor` by default, with deterministic\nwell assignment and sequential processing inside each lane. Compiled callable\ncontracts select framework-local GPU devices independently; single-worker and\ndebugging configurations can use inline or threaded execution.\n\n</td>\n</tr>\n<tr>\n<td width=\"50%\" valign=\"top\">\n\n### 🔌 Any Python Function\nRegister **any** Python function by decorating it with `@numpy`, `@cupy`, `@pyclesperanto`, `@torch`, or another memory-type decorator. Custom functions receive contract validation, UI integration, multiprocessing-safe import identity, and the same server-owned catalog projection as built-in functions. Persisted functions live in the platform-specific OpenHCS user-data directory.\n\n</td>\n<td width=\"50%\" valign=\"top\">\n\n### 📊 Results Materialization\nCallable and module artifact contracts declare semantic outputs independently of Python argument names. The artifact graph and materialization plans route images, measurements, object labels, relationships, tables, and files to their configured stores and exporters.\n\n</td>\n</tr>\n<tr>\n<td width=\"50%\" valign=\"top\">\n\n### 🔬 Process-Isolated Napari & Fiji\nStream images to **Napari** and **Fiji/ImageJ** in real time during pipeline execution. OpenHCS `StreamingConfig` declarations and viewer adapters own identity, display, and persistence policy. PolyStore builds generic storage and streaming payloads; ZMQRuntime supplies process-isolated transport, readiness, acknowledgments, and lifecycle.\n\n</td>\n<td width=\"50%\" valign=\"top\">\n\n### 🪟 Live Cross-Window Updates\nEdit a value in `GlobalPipelineConfig` — watch it propagate in real-time to `PipelineConfig` and `StepConfig` windows. Dual-axis resolution (context hierarchy × class MRO) with scope isolation per orchestrator.\n\n</td>\n</tr>\n<tr>\n<td width=\"50%\" valign=\"top\">\n\n### 🧬 CellProfiler Pipeline Import\nOpen `.cppipe` files in the desktop application or lower them from Python into ordinary `PipelineConfig` and `FunctionStep` declarations. Named images, objects, measurements, relationships, and exports use the same typed compiler and runtime as native OpenHCS pipelines. The source-backed Official30 suite continuously exercises 30 pipelines from CellProfiler examples, tutorials, and benchmark supplements under explicit equivalence policies.\n\n</td>\n<td width=\"50%\" valign=\"top\">\n\n### 🤖 MCP Agent Automation\nUse the local stdio MCP server with ChatGPT desktop, Codex, Claude Desktop, and other supported clients, or deploy the separately secured HTTP surface. The graphical installers register detected local clients automatically. Capability profiles, schemas, knowledge, UI attachment, authoring, execution, runtime inspection, viewer review, and governed custom-function registration are projected from typed authorities rather than duplicated tool lists.\n\n</td>\n</tr>\n</table>\n\n---\n\n## 🧩 The OpenHCS Ecosystem\n\nOpenHCS is built on **8 purpose-extracted, separately published libraries** — each solving a general problem and all composed into one platform:\n\n```mermaid\ngraph TD\n    OH[\"OpenHCS Platform<br/>(domain wiring + pipelines)\"]\n\n    OH --> OS[\"ObjectState<br/>(config)\"]\n    OH --> AB[\"ArrayBridge<br/>(arrays)\"]\n    OH --> PS[\"PolyStore<br/>(I/O + streaming)\"]\n    OH --> ZR[\"ZMQRuntime<br/>(exec)\"]\n    OH --> QR[\"PyQT-reactive<br/>(forms)\"]\n\n    OS --> PI[\"python-introspect<br/>(signatures)\"]\n    OH --> MR[\"metaclass-registry<br/>(plugins)\"]\n    OH --> PC[\"pycodify<br/>(serialization)\"]\n```\n\n| Library | Role in OpenHCS | What It Does |\n|:--------|:----------------|:-------------|\n| [**ObjectState**](https://github.com/OpenHCSDev/ObjectState) | Configuration framework | Lazy dataclasses with dual-axis inheritance (context hierarchy × class MRO) and `contextvars`-based resolution |\n| [**ArrayBridge**](https://github.com/OpenHCSDev/ArrayBridge) | Memory type conversion | Unified API across NumPy, CuPy, PyTorch, JAX, TensorFlow, pyclesperanto with DLPack zero-copy transfers |\n| [**PolyStore**](https://github.com/OpenHCSDev/PolyStore) | Unified I/O & stream payloads | Generic storage and streaming payload primitives, backend lifecycle, virtual workspaces, atomic writes, format detection, and ROI extraction |\n| [**ZMQRuntime**](https://github.com/OpenHCSDev/ZMQRuntime) | Process & transport runtime | Generic request, status, progress, cancellation, process-lifecycle, and viewer-control transport protocols |\n| [**PyQT-reactive**](https://github.com/OpenHCSDev/PyQT-reactive) | UI form generation | React-style reactive forms from dataclasses with cross-window sync and flash animations |\n| [**pycodify**](https://github.com/OpenHCSDev/pycodify) | Code ↔ object conversion | Python source as serialization format — type-preserving, diffable, editable, with collision handling |\n| [**python-introspect**](https://github.com/OpenHCSDev/python-introspect) | Signature analysis | Pure-Python function/dataclass introspection for automatic UI generation and contract analysis |\n| [**metaclass-registry**](https://github.com/OpenHCSDev/metaclass-registry) | Plugin discovery | Zero-boilerplate registry system powering microscope handler and storage backend auto-discovery |\n\n---\n\n## 🔬 Microscope & Function Support\n\n<table>\n<tr>\n<td width=\"40%\" valign=\"top\">\n\n**Image Sources**\n\n| Source | Support |\n|:-------|:--------|\n| ImageXpress | Native plate and metadata handling |\n| Opera Phenix | Native plate and metadata handling |\n| Bio-Formats | Arbitrary folders and supported microscopy containers |\n| OMERO | Remote image and metadata access |\n| OpenHCS format | Native generated and materialized plates |\n\nSource handlers are auto-detected and extensible through `metaclass-registry`.\n\n</td>\n<td width=\"60%\" valign=\"top\">\n\n**Functions — Automatic Discovery**\n\n| Library or route | Execution memory |\n|:-----------------|:-----------------|\n| scikit-image and OpenHCS native | NumPy / CPU |\n| pyclesperanto | OpenCL GPU |\n| CuPy and cuCIM | CUDA GPU |\n| PyTorch, JAX, and TensorFlow functions | Declared CPU/GPU arrays |\n| User custom functions | Declared by their memory-type decorator |\n\nThe connected execution server owns the available catalog, so remote GPU and\ncustom-function availability is reflected without a manually maintained list.\n`ArrayBridge` provides compatible memory conversion, including zero-copy paths\nwhere supported.\n\n</td>\n</tr>\n</table>\n\n**Processing domains**: image preprocessing · segmentation · cell counting · stitching (MIST + Ashlar GPU) · neurite tracing · morphology · measurements\n\nDimensionality is function-defined rather than a global mode: true volumetric\nsegmentation and measurement routes coexist with plane-local functions, whose\nlabels are not silently stitched across Z. See the\n[dimensionality and measurement capability reference](https://openhcs.readthedocs.io/en/latest/reference/dimensionality_and_measurements.html).\n\n---\n\n## 🚀 Quick Start\n\nFor most desktop users, download the\n[Windows installer](https://github.com/OpenHCSDev/OpenHCS/releases/latest/download/OpenHCS-Windows-Installer.exe)\nor [macOS installer](https://github.com/OpenHCSDev/OpenHCS/releases/latest/download/OpenHCS-macOS-Installer.dmg).\nNeither download requires ZIP extraction or an existing Python installation.\nWhen upgrading OpenHCS 0.7.23 or earlier, follow the\n[one-time installer migration](https://openhcs.readthedocs.io/en/latest/getting_started/getting_started.html#installation).\n\nIf macOS blocks the official bootstrap because it is unsigned and not notarised,\ntry to open **OpenHCS Installer.app**, then go to **System Settings > Privacy &\nSecurity**, scroll to **Security**, click **Open Anyway**, authenticate, and\nconfirm **Open**. Only override Gatekeeper for the disk image downloaded from\nthe official OpenHCS GitHub release. [Apple documents the current recovery\nsteps here.](https://support.apple.com/guide/mac-help/open-an-app-by-overriding-security-settings-mh40617/mac)\n\nFor a manual installation, create a virtual environment and install the same\nCPU-safe desktop surface as the graphical installers:\n\n```bash\n# Complete CPU-safe desktop environment\npython -m pip install \"openhcs[gui,viz,bioformats,mcp,cellprofiler-compat]\"\n\n# Launch the application\nopenhcs\n\n# Launch the local MCP server over stdio\nopenhcs-mcp\n```\n\nSmaller environments can select only the required features:\n\n```bash\n# Basic installation with GUI\npython -m pip install \"openhcs[gui]\"\n\n# Add Napari viewer\npython -m pip install \"openhcs[gui,napari]\"\n\n# Add Fiji/ImageJ viewer\npython -m pip install \"openhcs[gui,fiji]\"\n\n# Add both viewers\npython -m pip install \"openhcs[gui,viz]\"\n\n# Add GPU acceleration on a compatible CUDA 12 system\npython -m pip install \"openhcs[gui,gpu]\"\n\n# Full installation (GUI + viewers + GPU)\npython -m pip install \"openhcs[gui,viz,gpu]\"\n\n# Add the local MCP server for agent clients\npython -m pip install \"openhcs[gui,mcp,viz]\"\n```\n\n```python\n# Or lower a CellProfiler pipeline into public OpenHCS declarations\nfrom pathlib import Path\n\nfrom objectstate import ensure_global_config_context\nfrom openhcs.core.config import GlobalPipelineConfig\nfrom openhcs.core.orchestrator.orchestrator import PipelineOrchestrator\nfrom openhcs.interop.cellprofiler.pipeline_import import import_cellprofiler_pipeline\n\nplate_path = Path(\"/data/plate\").resolve()\nensure_global_config_context(GlobalPipelineConfig, GlobalPipelineConfig())\nsteps, pipeline_config = import_cellprofiler_pipeline(\n    \"analysis.cppipe\",\n    source_root=plate_path,\n)\n\norchestrator = PipelineOrchestrator(\n    plate_path,\n    pipeline_config=pipeline_config,\n).initialize()\nexecution_bundle = orchestrator.compile_pipelines(steps)\n```\n\nThe GUI and execution services consume the same `list[FunctionStep]`,\n`PipelineConfig`, and typed execution bundle. See the\n[API orientation](https://openhcs.readthedocs.io/en/latest/api/) for the explicit\nlow-level execution call and progress lifecycle.\n\n<details>\n<summary><b>📦 All installation options</b></summary>\n\n```bash\npython -m pip install \"openhcs\"              # Headless engine\npython -m pip install \"openhcs[gui]\"         # Desktop GUI\npython -m pip install \"openhcs[gui,napari]\"  # GUI + Napari viewer\npython -m pip install \"openhcs[gui,viz]\"     # GUI + Napari + Fiji\npython -m pip install \"openhcs[gui,viz,gpu]\" # Full installation\npython -m pip install \"openhcs[gpu]\"         # Headless + GPU\npython -m pip install \"openhcs[omero]\"       # OMERO integration\npython -m pip install -e \".[all,dev]\"         # Development (all features)\n```\n\nThe `gpu` extra requires a compatible CUDA 12 environment on a supported\nNVIDIA platform. For a CPU-only\ndesktop installation, install `openhcs[gui]` without the `gpu` extra.\n\n</details>\n\n<details>\n<summary><b>🗄️ OMERO integration</b></summary>\n\nOMERO requires `zeroc-ice`, whose compatible wheels are not published through\nthe normal project metadata. Install the helper requirements before the extra:\n\n```bash\npython scripts/install_omero_deps.py\npip install 'openhcs[omero]'\n```\n\nEquivalent requirements-file installation:\n```bash\npip install -r requirements-omero.txt\npip install 'openhcs[omero]'\n```\n\nSupported on Python 3.11 and 3.12. See [Glencoe Software](https://www.glencoesoftware.com/blog/2023/12/08/ice-binaries-for-omero.html) for manual installation.\n\n</details>\n\n---\n\n## 📖 Documentation\n\n| | |\n|:---|:---|\n| 📘 **[Read the Docs](https://openhcs.readthedocs.io/)** | Full API docs, tutorials, guides |\n| 🏗️ **[Architecture](https://openhcs.readthedocs.io/en/latest/architecture/)** | Typed compiler · sources · artifacts · runtime values · package boundaries |\n| 🎓 **[Getting Started](https://openhcs.readthedocs.io/en/latest/getting_started/)** | Installation · First pipeline |\n\n---\n\n## ⚙️ Architecture Highlights\n\n<details>\n<summary><b>Resolved, typed pipeline compilation</b> — catch errors before execution starts</summary>\n\n```\nPipelineConfig + list[FunctionStep]\n        ↓ resolve once\nStepSnapshot + CompilationSession\n        ↓ derive and validate\ntyped CompiledStepPlan objects\n        ↓ package\nCompiledExecutionBundle\n        ↓ execute\nruntime values + materialized artifacts\n```\n\nThe authoring surface remains an ordered linear step list. ObjectState\ninheritance keeps defaulted configuration sparse, while compilation derives and\nexposes the exact source and artifact dependencies required for execution; the\nderived dependency graph is not a second workflow the user must author.\n\nPipelines are compiled for every selected execution axis before processing begins. Runtime workers consume the compiled bundle rather than reinterpreting mutable declaration objects. [Read more →](https://openhcs.readthedocs.io/en/latest/architecture/pipeline-compilation-system.html)\n\n</details>\n\n<details>\n<summary><b>Dual-Axis Configuration</b> — context hierarchy × class MRO</summary>\n\nResolution walks two axes simultaneously: the **context stack** (Global → Pipeline → Step) and the **class MRO** (inheritance chain). Built on `contextvars` for thread-safe, scope-isolated resolution. Preserves `None` vs concrete value distinction for proper field-level inheritance. Powered by `ObjectState`. [Read more →](https://openhcs.readthedocs.io/en/latest/architecture/configuration_framework.html)\n\n</details>\n\n<details>\n<summary><b>Bidirectional GUI ↔ Code</b> — code generation at any scope level</summary>\n\nAny window holding `ObjectState` objects can generate and re-import executable Python:\n\n```\nFunction patterns · Individual steps · Pipeline configs · Full orchestrator scripts\n              ↕  generate / AST-parse back  ↕\n```\n\nEach scope encapsulates all lower-scope imports. Generated code is fully executable without additional setup. Edit in your IDE or external editor, save, and the GUI re-imports via AST parsing. Powered by `pycodify` + `python-introspect`. [Read more →](https://openhcs.readthedocs.io/en/latest/architecture/code_ui_interconversion.html)\n\n</details>\n\n<details>\n<summary><b>Cross-Window Live Updates</b> — class-level registry + Qt signals</summary>\n\nA class-level registry tracks all active form managers. When a value changes in any config window, Qt signals propagate the change to every affected window with debounced, scope-isolated refreshes. Global → Pipeline → Step cascading with per-orchestrator isolation. Powered by `PyQT-reactive`. [Read more →](https://openhcs.readthedocs.io/en/latest/architecture/parameter_form_lifecycle.html)\n\n</details>\n\n<details>\n<summary><b>More patterns</b> — storage, viewer integration, function discovery, memory types</summary>\n\n- **Storage and viewer streaming**: PolyStore owns generic storage and streaming payload primitives; ZMQRuntime owns process, transport, readiness, acknowledgment, and lifecycle protocols; OpenHCS `StreamingConfig` declarations plus the Napari/Fiji adapters own viewer identity, display, and application policy.\n- **Automatic Function Discovery**: registry-discovered functions with contract analysis and type-safe integration via `python-introspect` + `metaclass-registry`\n- **Memory Type Management**: Compile-time validation of array type compatibility with zero-copy conversion via `ArrayBridge`\n- **Custom Function Registration**: Any Python function decorated with `@numpy`, `@cupy`, `@pyclesperanto`, etc. is auto-integrated with contracts, UI forms, and the function registry\n- **Evolution-Proof UI**: Type-based form generation from Python annotations — adapts automatically when signatures change\n\n[Full architecture docs →](https://openhcs.readthedocs.io/en/latest/architecture/)\n\n</details>\n\n---\n\n## 🤝 Contributing\n\n```bash\ngit clone --recurse-submodules https://github.com/OpenHCSDev/OpenHCS.git\ncd OpenHCS\n# Install the eight local packages using docs/source/development/repository_setup.rst,\n# then install OpenHCS itself:\npython -m pip install -e \".[dev,gui]\"\nOPENHCS_CPU_ONLY=1 python -m pytest tests/unit\n```\n\n**Contribution areas**: microscope formats · processing functions · GPU backends · documentation\n\n---\n\n## 📄 License\n\nMIT — see [LICENSE](LICENSE).\n\n## 🙏 Acknowledgments\n\nOpenHCS evolved from [EZStitcher](https://github.com/OpenHCSDev/ezstitcher) and builds on [Ashlar](https://github.com/labsyspharm/ashlar) (stitching), [MIST](https://github.com/usnistgov/MIST) (phase correlation), [pyclesperanto](https://github.com/clEsperanto/pyclesperanto_prototype) (GPU image processing), and [scikit-image](https://scikit-image.org/) (image analysis).\n\nOpenHCS's CellProfiler interoperability and parity validation build on the CellProfiler project's open-source software, documentation, and public example, tutorial, and benchmark materials. We thank the CellProfiler authors and contributors and the authors of the biological datasets they distribute. Please cite CellProfiler following its [official citation guidance](https://cellprofiler.org/citations), including [Stirling et al., *CellProfiler 4: improvements in speed, utility and usability* (2021)](https://doi.org/10.1186/s12859-021-04344-9).\n\nThird-party project names and logos identify supported integrations, compatible\nclients, or software used by OpenHCS. They remain the property of their\nrespective projects or owners; their appearance does not imply affiliation or\nendorsement.\n",
  "bytes": 22091,
  "sha": "f5e56ada7d20c7d252aabbbc4f8a27a9450193769630e51ef85c3ec82555542b",
  "repo_slug": "openhcsdev/openhcs",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_openhcsdev_openhcs_b8c43dbe/readme"
}