ZEISS ZEN / Smart Microscopy / November 2026

From image
to action.

Use sample information to choose what ZEN does next: adapt an experiment, find a target, or orchestrate a complete workflow.

Observe the sampleAcquire an overview, not every detail.

Identify what mattersTurn pixels into target locations.

Acquire selectivelyRecord the event at useful resolution.

Fig. 1Smart Microscopy links acquisition, analysis, and an automatic action; recording the same sequence without a data-dependent decision is automation, but not yet adaptive imaging. Images: Smart Microscopy Reloaded.

A visual overview for microscopy users and software developers. English. Local images and playable videos. Reviewed against the supplied material on 13 November 2026.

The short answer

Choose where the decision belongs.

Inside ZEN

OAD scripting

Customize a complete ZEN workflow with internal IronPython scripts.

Use ZEN's internal functionality

During acquisition

Experiment Feedback

React to analysis results or changing system observables in a running experiment.

Adapt the active acquisition

Between overview and detail

Guided Acquisition

Find objects, then image only those objects in detail. Use the module or an OAD script.

Select targets automatically

Outside ZEN

ZEN-API

Let an external application coordinate ZEN, Python analysis, and other workflow components.

Build an external control loop

These options complement each other.

Guided Acquisition is a workflow pattern, not a transport protocol. The module, an OAD script, or a ZEN-API client can implement that pattern.

Start with the built-in module when it fits. Add scripting or an external client only where the application needs more flexibility.

Basis: Experiment Feedback documentation, Guided Acquisition documentation, and public ZEN-API overview.

The interface landscape

Data access and instrument control are different interfaces.

Source illustration places OAD, Experiment Feedback, ZEN API, COM, TCP/IP, extensions, and CZI access around ZEN — Fig. 2The ZEN ecosystem exposes several integration points; the correct one depends on who owns the workflow. Original illustration: ZEN Interfaces. Select an image to open its full resolution.

CZI and its librariesRead image pixels and metadata with tools such as libCZI or pylibCZIrw. A file reader does not move the microscope.
Internal OAD and Experiment FeedbackRun inside ZEN. Access internal workflow functions or acquisition-time observables and actions.
COM and TCP/IPExpose established scripting routes to external software. COM uses Windows automation; TCP/IP sends scripting commands or starts a macro.
C# extensionsAdd application-integrated functionality through the ZEN extension mechanism. This is a different integration model from an external API client.
ZEN-APIUses typed services for external monitoring and control, including acquisition, selected hardware functions, and pixels during acquisition.

Important distinction

The TCP/IP scripting interface and the gRPC-based ZEN-API are not the same protocol. A TCP/IP macro command is not a ZEN-API method.

Reference: included interface overview. Exact availability depends on the ZEN edition, version, licensed functionality, and instrument.

Open Application Development

OAD makes ZEN the workflow host.

ZEN internal script editor with Python code and output panel — Fig. 3OAD scripts run in ZEN's built-in IronPython environment and call ZEN functionality from inside the application. Source: OAD / ZEN-API.

Open Application Development (OAD)

Record supported operations, edit scripts, and combine acquisition, processing, analysis, saving, and user dialogs.

Good fit: ZEN owns the workflow and the required functions exist in its scripting interface.
Strength: broad access to ZEN-internal functions, including processing and analysis not all exposed by ZEN-API.
Constraint: the supplied scripting environment uses IronPython, not ordinary CPython.
Consequence: do not expect to import CPython-native packages such as NumPy or SciPy directly.

External Python, Fiji, or other software can be invoked from a script. That adds a process and data handoff; it does not turn IronPython into CPython.

What OAD is not

It is not a promise that every UI operation is recordable. An unrecorded operation may still have a scripting command. OAD is also not synonymous with the Guided Acquisition module: the script is one way to implement a custom guided workflow.

Source diagram distinguishes the internal IronPython environment from external Python and .NET libraries — The internal runtime and an external Python process remain separate integration environments. Illustration: ZEN Interfaces.

Basis: included OAD runtime illustration and public ZEN-API README: API and internal scripting.

Adaptive Acquisition Engine

Experiment Feedback changes a running experiment.

Original Experiment Feedback workflow with Pre Loop, Main Loop, and Post Loop — Fig. 4Feedback scripts prepare state, react to changing observables, and finish with logging or other actions. Original workflow: ZEN Interfaces; lifecycle verified in the ZEN 3.14 tutorial, pages 6-10.

PreLoop: prepare once

Import modules, define functions, and initialize variables at the start of the experiment.

Loop: react to change

Evaluate rules when a used observable changes. Read online measurements or hardware state and issue permitted actions.

PostLoop: finish once

Write final results or start follow-up work when acquisition finishes. The feedback script is stored in the experiment.

Make the rule explicit.

Stop acquisition after enough objects have been detected.
Adjust permitted acquisition parameters in response to sample changes.
React to a trigger, stage position, or environmental observable.
Log measurements or start an external application.

Not an unconditional polling loop

The Loop script is triggered by changes in observables used by the script. It does not automatically execute forever or once per arbitrary time interval.

Experiment Feedback editor showing the three script areas and observable/action lists — Fig. 5The editor separates setup, event-dependent logic, and final actions. Illustration: ZEN Interfaces.

Synchronization determines which data your rule can trust.

Do not assume results are ready

Script execution can overlap online analysis and disk writing. This mode does not guarantee their completion first.

Wait for analysis

Select an order in which analysis finishes before the script runs when the rule needs current measurements.

Wait for analysis and disk

Use the order that also completes image writing before starting external software that must read those pixels.

Define the required measurements in the image-analysis setting first. Reload a changed setting in the feedback editor. Synchronization and script cost affect acquisition timing.

ZEN 3.14 tutorial, pages 7-11. The source also distinguishes Free Run from Synchronized execution; select the appropriate execution order in that version's UI.

Video AExperiment Feedback demonstration. Recording: included MP4, Sebastian Rhode, ZEISS. This is a demonstration, not a timing guarantee.

Overview / detection / detailed acquisition

Guided Acquisition spends detail on selected objects.

Wide-field overview contains many candidate cells — Fig. 6Guided Acquisition turns an overview into a target list, then acquires detail only at selected regions. Analysis can run in ZEN or external software. Workflow: Guided Acquisition; images: mitosis case study.

Image-analysis feature filters select candidate mitotic cells — Fig. 6Guided Acquisition turns an overview into a target list, then acquires detail only at selected regions. Analysis can run in ZEN or external software. Workflow: Guided Acquisition; images: mitosis case study.

The ZEN module: configure the workflow

A dedicated module provides a streamlined UI. Select overview and detail experiments, optional processing, and an image-analysis setting.

No scripting knowledge required for the standard workflow.
Checks required analysis parameters and supports well-plate workflows.
Integrates supported processing steps before detection.
A separately offered module; confirm entitlement and instrument support.

Choose how to find objects.

ZEN Guided Acquisition can incorporate machine-learning and deep-learning methods to detect objects in the overview:

Semantic Pixel Classifier: classify pixels into target and background classes using trained image features.
Semantic DL Models: use neural networks to assign pixels to classes and derive target regions.
Instance Segmentation: identify individual objects, including objects that touch.
CellPose Model: segment cells or nuclei to generate candidate objects.
External DL models: import compatible models into ZEN or integrate external inference and return detected targets.

Available methods depend on the ZEN version, enabled analysis features, and model compatibility. External inference requires a configured integration, such as a scripted handoff; it is not automatically part of the standard module sequence. The Semantic Pixel Classifier is a machine-learning option, not necessarily a deep-learning model.

Guided Acquisition module with overview, processing, image analysis and detail scan settings — Fig. 7The module's setup UI sits beside the overview-to-detail workflow: analysis supplies XYZ positions and region shapes for targeted acquisition. Source: Guided Acquisition module and workflow illustration. Open either image for full resolution.

Overview scans of brain sections feed internal or external analysis; detected XYZ positions and ROI shapes guide detailed imaging — Fig. 7The module's setup UI sits beside the overview-to-detail workflow: analysis supplies XYZ positions and region shapes for targeted acquisition. Source: Guided Acquisition module and workflow illustration. Open either image for full resolution.

The OAD script: own the workflow

A macro implements the same pattern inside ZEN. Customize processing, target selection, experiment modification, and external analysis handoffs.

Useful when the module's standard sequence does not fit.
Requires IronPython and knowledge of the ZEN scripting interface.
The published example script is free to use at your own risk; required ZEN capabilities still apply.
You maintain the code, coordinate handling, error paths, and recovery.

Detailed source workflow for scripted Guided Acquisition — Fig. 8The script exposes workflow steps that the module normally manages. Source: scripted Guided Acquisition. Open the original image to read the full workflow.

Other applications use the same selection pattern.

Organoid overview and selected detailed images — Fig. 9Organoids can be selected by image-derived features before detailed imaging. Sample courtesy Dr. M. Lutolf, EPFL, Switzerland. ZEISS Guided Acquisition.

Overview of sectioned mouse brain with a detailed projection of a detected neuron — Fig. 10Rare labeled neurons can be located in tissue sections and then imaged in detail. Sample courtesy Dr. L. Lim, Katholieke Universiteit Leuven, Belgium. ZEISS Guided Acquisition.

Guided Acquisition gallery pairs cell and tissue overviews with selected high-resolution details, including mitotic cells and neurons — GalleryThe same overview-to-detail selection pattern applies across cell and tissue imaging. Original ZEISS gallery: Guided Acquisition; sample credits remain with the source material.

Basis: Guided Acquisition README and tutorials. “Module” and “script” describe the implementation and user experience, not two different biological selection principles.

A concrete event-driven workflow

Find mitosis early, then follow the event.

Video BThe supplied workshop demonstrates event-driven Guided Acquisition around prometaphase. Source: Smart Microscopy Reloaded.

The biological question sets the acquisition.

A useful recording must include the event's start, not only a bright cell found too late.

Screen a broad field at low magnification.
Segment candidates and reject unwanted objects.
Acquire selected cells with a suitable time-lapse and Z-stack.
Track the event and measure anaphase initiation downstream.

Sequential well processing reduces the delay between detection and detail. Classification errors and time spent acquiring each stack still limit useful throughput.

Fig. 11The reported overnight run acquired 300 positions: 266 true mitotic events and 34 false positives, mainly apoptotic cells. This is one reported experiment, not a general accuracy claim. Source: high-throughput case study.

Video CThe case-study montage shows event-centered acquisitions from the reported run. Source: Smart Microscopy Reloaded.

Cell-division montage with marked anaphase initiation and a distribution of event timing — Fig. 12The useful output is a biological measurement, not only a collection of images. Downstream analysis identifies anaphase initiation. Source: ZEISS case study.

A custom OAD example makes the scheduling logic visible.

OAD smart imaging example shows continuing overview and detailed acquisition cycles — Fig. 13The OAD example coordinates overview detection and detailed event acquisition using a custom scheduler. Source: SmartMicroscopy / Detecting Mitosis.

Video DThe repository includes simulated data and a custom event-driven workflow; the source video is labeled 4x playback. It is not a real-time latency measurement. Source: Detecting Mitosis.

Case-study media: included images and recordings. Credits: ZEISS, Marion Lang, Sandra Orthaus, Phillip Seidel, Pierre Menard, and contributors. No general speed or detection guarantee is inferred.

ZEN-API deep dive / architecture

Your application owns the workflow. ZEN owns acquisition.

ZEN-API connects an external process to a running ZEN system. It exposes services, not mouse clicks.

Original ZEN API architecture shows external consumers connecting through a gateway to API providers in the ZEN ecosystem — Fig. 14The gateway is the client's common endpoint; ZEN applications provide the actual capabilities. Illustration: included architecture image, Sebastian Rhode, ZEISS. Its network labels describe possible connectivity, not a recommendation to expose the gateway to the public Internet.

Client

Your Python program or other application calls services, analyzes data, and chooses the next action. It can run locally or on another permitted machine.

Gateway

A separate application routes calls to registered providers and handles shared concerns such as access management and aggregated service descriptions.

API provider

A running ZEN ecosystem application hosts an API server and registers its services. The provider implements the microscope-specific operation.

A complementary interface

ZEN-API does not replace OAD or expose every internal ZEN function. It is not a UI-automation interface. Check that the exact operation exists for the running system before designing the workflow.

Basis: public ZEN-API overview, gateway, and glossary. LM means light microscopy; EM means electron microscopy. A shared acquisition concept does not imply identical hardware support.

ZEN-API deep dive / contracts

A typed contract separates the client from ZEN internals.

Source illustration connects C# interface definitions, protocol-buffer contracts, gRPC services and generated client code — Fig. 15Language-neutral contracts describe service methods and messages; generated client code lets another language call them. Original illustration: ZEN API - gRPC.

Protocol Buffers

A .proto file defines services, request and response messages, and fields. It is the contract, not the microscope driver.

gRPC

Remote Procedure Calls use HTTP/2 and Protocol Buffers. Methods can return a response or a stream of responses.

Generated client stubs

A stub makes a remote service callable from your program. Generated messages enforce the API's data structure; they do not supply unsupported server features.

The Python layers have different jobs.

zen_api supplies the generated API messages and gRPC client wrappers.
zen_api_utils supplies separate, application-side connection and workflow helpers.
NumPy, image analysis, AI inference, and visualization are client-side choices, not requirements of the gateway.

Version matching is part of the design.

Package version, service namespace, and server capabilities are separate concerns. Namespaces such as v1 and v1beta coexist in a package.

A method present in a generated package may still be unavailable on an older ZEN server or a different instrument.

Basis: contract-generation overview, utility package documentation, and versioned proto contracts.

ZEN-API deep dive / data during acquisition

PixelStream delivers pixels with acquisition context.

Video EA Python client displays semantic segmentation during acquisition. Receiving and analyzing a stream does not automatically create a feedback action. Recording: included PixelStream semantic segmentation MP4.

Video FThe Noise2Void example demonstrates client-side denoising of streamed pixels. Processing throughput is model- and hardware-dependent. Recording: included PixelStream N2V MP4.

Keep with the pixels	Why it matters
Experiment ID and frame number	Associate a response with its experiment and frame; do not identify frames only by arrival time.
Frame position	Use the acquisition indices, such as time, Z, channel, tile, and scene, when organizing the data.
Stage position and scaling	Relate image measurements to physical locations. Verify coordinate frames, origins, and units.
Pixel type, full-frame size, and raw bytes	Decode the correct type and shape. A byte payload is not already a NumPy image.
Payload start position and size	Place partial data at the correct offset within the full frame. Do not reshape every response as a complete image.

Get the next frame

The reviewed service offers single-response methods such as GetNextFrame, optionally scoped to an experiment or channel.

Monitor an experiment

MonitorExperiment and MonitorAllExperiments return server streams. Select the intended experiment and channel scope.

Choose assembled or raw data

The monitor requests include enable_raw_data. Raw data can contain partial frames or lines; the non-raw mode assembles full frames.

Engineering guidance: keep the loop responsive.

Separate pixel reception, expensive analysis, and hardware decisions. Bound buffering, record processing lag, and define what happens when analysis is slower than acquisition. Do not claim hard real-time performance from a demo video.

Basis: ExperimentStreamingService, FrameData, and FramePixelData contracts; pixel-stream example. The concurrency guidance is a design recommendation, not an API delivery guarantee.

ZEN-API in an external viewer

napari can watch, start, or store a ZEN acquisition.

Video GThe supplied napari-zenapi-streaming recording places a Python viewer beside the ZEN system. It demonstrates an external client, not a replacement for ZEN's acquisition engine. Source: ScreenPal recording collection.

Watch an experiment

Start acquisition in ZEN Blue and let napari display incoming frames. Connecting does not start an acquisition. The passive mode does not know the experiment ID in advance; run only one acquisition at a time.

Start the selected setup

Select a prepared experiment, then start it from napari. The plugin reads experiment dimensions from exported XML and filters frames by the returned experiment ID.

Write OME-Zarr directly

The OME-ZARR-only mode uses a dedicated channel and writer rather than the Display pipeline. It can start the experiment or arm the writer before a manual ZEN start.

napari ZEN API Streaming widget shows experiment selection, OME-ZARR-only mode, acquisition dimensions, and writer progress — Fig. 16The plugin exposes experiment selection and stream/output controls; the source screenshot shows the direct writer running. Source: napari-zenapi-streaming documentation.

napari displays data from a streamed OME-Zarr beside the selected ZEN well-plate acquisition — Fig. 17The resulting OME-Zarr can be opened in napari after acquisition and optional pyramid generation finish. Source: napari streaming repository.

Display and storage use different paths.

Display mode receives frames through an asynchronous reader, queue, and processor. It can show only the latest frame, but still retains received frames for final scene assembly.

After acquisition, tiles are placed using streamed positions into scene mosaics per channel. A lightweight live preview does not mean acquisition memory use stays constant.

Completion needs more than a finished status.

The repository documents that final pixel payloads can arrive after ZEN reports acquisition complete. A napari-started Display run also waits for its expected unique frame count, with inactivity as a fallback.

The configured writer checks expected coordinates. Missing frames can leave a partial store and an error; inspect acquisition_status.json rather than assuming success.

Preview is not raw quantitative data

The reviewed Display path assumes uint16 input and normalizes each frame for visualization. Do not compare its layer intensities as untouched acquisition values. The configured OME-Zarr writer preserves supported raw GRAY8 or GRAY16 intensities; it does not support color pixel types.

Check the plugin's own compatibility and operating limits.

The repository describes an alpha / MVP project, targeting ZEN Blue and its gateway on Windows. The package requires Python 3.12-3.14; this is narrower than the API utility package's support range.
Install compatible zen_api and zen_api_utils wheels in the same environment as napari. They are required dependencies, not implied downloads from PyPI.
The documented API dependency range is 2026.5.1 through 2026.11.1. Match the gateway and instrument, not only the plugin.
The configured CLI and plugin share the direct writer. The older unconfigured CLI mode buffers the acquisition and does not provide the same completeness certification.
Linux-to-Windows remote streaming is experimental in this repository. Simulated tests do not establish end-to-end hardware throughput or frame completeness.
Stream reception, visualization, and writing are not by themselves a sample-driven feedback controller. The plugin is not documented as automatically running the N2V or semantic models shown in the separate API demos.

Viewing an existing CZI is a separate workflow.

Video HThe napari-czitools large-CZI recording illustrates file-based image viewing. It does not demonstrate a live PixelStream subscription or instrument control. Source: napari-czitools_large_CZI.mp4. The recording is not a general file-size or loading-speed benchmark.

Use a CZI reader to explore existing data. Use the streaming plugin to receive pixels during acquisition. Add a validated decision and control action when the scientific question needs a closed loop.

Basis: repository README, runtime behavior, requirements, package metadata, and display normalization code; two supplied napari recordings. Repository authors: Krijn H. van der Steen and Sebastian Rhode. Recorded UI versions may differ from the current checkout.

Additional Applications using ZEN-API

Receive and display pixels without processing.

Video IReceive and display. The no-processing recording establishes the PixelStream baseline: pixels leave ZEN and appear in an external client. Source: ZEN_API - PixelStream - No processing.mp4.

The viewer and processing examples are not interchangeable.

The napari plugin above provides viewing and storage modes. These recordings also show separate custom Python clients. Do not infer that a function shown in one client is built into another.

Compare this receiving-only baseline with Videos E and F in the PixelStream section for segmentation and denoising, and Video J below for Guided Acquisition. Each demonstration is embedded once per document. The alternate recording of the same Guided Acquisition workflow remains linked, not embedded, in the recording collection. Media references, credits, and hashes are listed in the media manifest.

ZEN-API deep dive / building a smart workflow

External analysis can choose the next experiment.

Video JThe external client analyzes an overview and requests detailed acquisitions for detected objects. Recording: included ZEN-API Guided Acquisition MP4. The current code example is listed under workflow examples.

A complete guided workflow has an explicit handoff.

Acquire an overview from a prepared ZEN experiment and wait for the required completion or data readiness.
Analyze in the client with the appropriate Python libraries or another analysis service.
Validate targets and convert image results into calibrated physical coordinates.
Clone a detail recipe and update the supported regions or positions.
Acquire each target and retain image outputs, target information, and errors.

What does the supplied example actually do?

The Python guided-acquisition example loads and clones experiments, clears tile regions, creates a rectangle, polygon, or ellipse, and runs a detailed acquisition.

Its tile-region calls document physical dimensions in meters. Do not pass segmentation pixel coordinates directly to stage or tile-region APIs.

The example also imports a legacy TCP/IP helper. Treat it as a mixed-interface example; do not assume every supporting operation is a pure ZEN-API call.

One external workflow is not another ZEN core job.

Client-side orchestration

The external program sequences wells, focus, acquisition, file readiness, and analysis. The supplied CD7 example keeps hardware operations sequential while background analysis works on previous CZI files.

Use this when Python must own the complete process or coordinate other systems.

ZEN core workflow services

The API can run ZEN core jobs and modify supported workflow parameters. Consult the versioned API documentation for available services.

A ZEN core job and an acquisition experiment are distinct concepts. Verify available workflow services for that edition.

Delegate the correct-sized block to ZEN.

Source sequence illustration divides a CellDiscoverer workflow between an external client, ZEN, the imaging system and data storage — Fig. 18Split the workflow into automatable blocks, but leave optimized acquisition execution in ZEN. Illustration: included workflow-block image, Sebastian Rhode, ZEISS. This conceptual illustration is not a specification for current output-path RPCs.

Avoid replacing a stable experiment with many low-level hardware calls when one supported acquisition block will do. More external flexibility can add coordination and processing overhead.

Close the loop deliberately

Analysis, denoising, or a dashboard alone is monitoring. A smart feedback workflow also has an explicit rule, a supported control action, and a checked result.

Basis: repository control examples and public OAD Python workflows; included workflow-block illustration. Sample loading and carrier navigation are instrument-specific, not generic promises for every ZEN installation.

Workshop examples

Connect microscope control, image data, models, and measurements.

These four example collections cover the steps around a smart acquisition. Image reading, model inference, and assay analysis do not control the microscope unless connected to an explicit acquisition decision.

Control and acquire through ZEN-API

A computer displays cell images, a selected target, acquisition tiles and stage controls beside a connected microscope illuminating a selected specimen region — An external client controls acquisition and receives image data from ZEN. Conceptual illustration for the workshop control and streaming examples, not a hardware specification or recorded result.

Explore stage and focus control, optical changers, autofocus, acquisition positions, tile regions, and Z-stacks. Continue with status monitoring, live processing, OME-Zarr streaming, or overview-driven guided acquisition.

Control ZEN: examples and setup

Read CZI pixels and metadata in Python

Python pylibCZIrw output pairs two CZI image planes with NumPy array shape and metadata for time points, Z planes, channels, width and height — Python reads both CZI pixels and acquisition metadata, without running ZEN. Composite of saved image-plane and dimension outputs in the pylibCZIrw notebook.

Inspect metadata, pixels, scenes, well plates, and attachment images. Try lazy viewing, CZI writing, OME-Zarr export, and reference-backed VZIP access. VZIP still requires the unchanged original CZI.

CZI handling: notebooks and scripts

Bring segmentation models into the workflow

Saved notebook output compares a fluorescence image, predicted nuclei segmentation and the label mask — The saved prediction output compares input, model prediction, and labels. Extracted from the CZANN inference notebook; this is an example, not a general accuracy claim.

Inspect CZANN metadata, unpack an ONNX model, and run inference with ONNX Runtime. A separate teaching notebook trains a small PyTorch nuclei-segmentation model and exports CZANN; preprocessing must match the selected model.

Deep learning: training, CZANN export, and inference

Turn images into a biological readout

Translocation assay example compares EGFP and DAPI images with segmented nuclei and surrounding cytoplasmic rings — The assay separates nuclei and surrounding rings before measuring EGFP translocation. Source: saved assay segmentation image.

The translocation assay segments DAPI nuclei and measures nuclear-to-cytoplasmic EGFP signal. It reads CZI or OME-Zarr plate data, then exports cell measurements, well summaries, heatmaps, and dose-response fits.

Translocation assay: example and inputs · Illustrated assay walkthrough

These are educational examples. Review each README, input data, model assumptions, and output paths. Validate hardware coordinates and use the instrument's approved procedures before running control scripts.

Links and additional info

Explore the documentation, examples, and included media.

The links below point to online resources or files included in this repository. Full-resolution illustrations and videos are included with this page. Videos play only when requested; no microscope code runs from this page.

S1 / ZEN Interfaces

Included interface map; OAD illustration; feedback workflow; feedback editor; public OAD repository.

Interface and workflow illustrations credited to Sebastian Rhode, ZEISS.

S2 / Experiment Feedback

README and examples; ZEN 3.14 tutorial PDF.

Adaptive Acquisition Engine, observables, actions, script lifecycle, and synchronization.

S3 / Guided Acquisition

README, tutorials, and scripts.

Module and scripted workflows, external analysis, requirements, and biological examples.

S4 / SmartMicroscopy

Detecting Mitosis.

Event-driven OAD use case, simulation data, acquisition settings, and analysis settings.

S5 / OAD ZEN-API

ZEN-API README; ZEN 3.14 documentation, API 2026.5.1.

Architecture, installation, compatibility, gateway configuration, and troubleshooting. Match the documentation to the target ZEN system.

S6 / Included Experiment Feedback demonstration

Experiment Feedback recording.

ZEISS Smart Microscopy demonstration, credited to Sebastian Rhode, ZEISS.

S7 / Included mitosis case-study media

Overview; target detection; detail images; acquisition mosaic; biological readout; prometaphase recording; event-centered montage.

Included ZEISS case-study media. Sample and contributor acknowledgements accompany the relevant figures.

S8 / Included ZEN-API illustrations

Gateway and provider architecture; workflow blocks.

Illustrations credited to Sebastian Rhode, ZEISS. Current service behavior is defined by the versioned API documentation.

S9 / Client-side utilities

zen_api_utils README.

Connection and workflow helpers; utility versions are independent from generated API versions.

S10 / Acquisition contracts

Reviewed 2026.11.1 acquisition contracts; 2026.5.1 protocol reference for ZEN 3.14.

Service methods, requests, frame metadata, and pixel payload definitions. The newer reviewed contracts are not a promise of availability in ZEN 3.14.

S11 / Workflow examples

Workshop control and streaming examples; OAD Python examples.

Guided acquisition, experiment configuration, streaming, coordinate handling, and client-side orchestration.

S12 / napari-zenapi-streaming

Repository and documentation.

Viewing and storage modes, mosaics, completeness handling, and compatibility. Authors: Krijn H. van der Steen, UMC Utrecht, and Sebastian Rhode, ZEISS.

S13 / Included demonstration recordings

napari streaming; CZI viewing; Guided Acquisition (embedded); alternate recording of the same Guided Acquisition workflow (link only); PixelStream baseline; Noise2Void; semantic segmentation.

Both documents embed each distinct demonstration once using repository-local media. The alternate Guided Acquisition recording is retained here without a second player. Recorded interfaces do not establish current support or performance guarantees.

Included media retains its ZEISS/workshop and sample-contributor credits. Inclusion here does not grant additional publication or redistribution rights.

Built as a local visual explainer. No remote AI service, analytics, or CDN media is required. This is an educational overview, not a product specification or a substitute for the target system's documentation.