Micro-Manager

The standard open-source microscope-control platform — camera, stage, filter wheel and autofocus behind one device-abstraction layer — which turns out to contain a stage-driven, quality-measured implementation of exactly the tiled-acquisition-and-stitching pipeline this group’s two DIY-WSI projects hand-built, with one documented boundary that matters for H&E: its pyramidal writer’s contract is grayscale-only.

Purpose

Verdict: not adopted — nothing here currently runs a motorised research microscope, which is the hardware premise of the whole tool. The page exists because the reading answered open questions on Video-Based WSI Mosaicing that neither local project could, and because “why not just use Micro-Manager?” is the first question anyone outside the group will ask about DIY WSI — it deserves a written answer rather than a shrug.

Micro-Manager is what it says: control and automation of microscope hardware. A C++ hardware abstraction layer (MMCore, in the separate mmCoreAndDevices repository) with device adapters for the four major microscope manufacturers, most scientific cameras and a long tail of peripherals; a Java/Swing GUI (MMStudio, this repository) built around multi-dimensional acquisition — channel × time × Z × XY position; scripting via Beanshell and a Python route. It is roughly two decades old, community-governed with a written improvement-proposal process, and more active now than most tools evaluated here have ever been.

The three URLs supplied (homepage, user guide, repository) are one project and were processed as one evaluation; the user guide’s content is reflected below rather than filed separately.

Data used

None — it is acquisition software. Nothing was installed or run; every claim below is from the website, the user guide, and the cloned MMStudio source.

Methods

The §6 question, and the genuinely surprising answer

The decisive question is what this does that the indexed stack does not. The expected answer was “drives hardware” — true, generic, and not worth a page. The actual answer came from the source tree: MMStudio now contains a full tiled-acquisition-to-pyramid pipeline, in pieces the website barely advertises:

• The Tile Creator / position list machinery generates a stage-position grid covering a user-defined region (user guide, and plugins/AcquireMultipleRegions).
• The Explorer plugin (plugins/Explorer, self-described “Interactively acquire and stitch tiles through the active processing pipeline”) does interactive tiled acquisition with live stitched display.
• TileAligner (libraries/ExportTiles) computes sub-pixel translation corrections for a grid of overlapping tiles by phase correlation on the overlap strips, followed by BFS global optimisation — and reports an alignment summary: accepted/total pair counts and the RMS deviation of aligned origins from nominal grid positions.
• OMEBigTiffMultiresStorage (libraries/TiledDataProvider) writes the result as pyramidal OME-BigTIFF, five resolution levels, depth fixed up front because a BigTIFF SubIFD array cannot grow after the first plane.

Stage-scanned tiles, phase-correlation refinement, a measured alignment error, and a pyramidal file at the end — that is a whole-slide-imaging pipeline in everything but name, sitting inside a fluorescence-microscopy tool.

The boundary that matters here, stated precisely

The pyramidal writer’s class contract reads: “Grayscale 8- and 16-bit only: RGB and 32-bit (float) images are rejected, because the on-demand mosaic compositor works in byte[]/ short[].” H&E brightfield is RGB, so the pyramid path as documented excludes the one image type a pathology WSI needs. Two precision notes, because this claim nearly went onto the page stronger than the evidence: the flat (single-resolution) tiled storage in the same library does handle RGB — its code comments on Micro-Manager’s 4-byte BGRA layout — so the limitation is specific to the multires compositor; and the read located the documented contract and the rgb_ flag but not an explicit rejection site, so whether an RGB source fails loudly or degrades some other way is [unverified]. The honest summary: tiled RGB acquisition appears supported; the pyramidal export of it is documented out of scope today.

The user guide, consistently, documents no whole-slide or slide-scanning workflow — the capability exists as parts, not as a product.

What this changes about the local DIY-WSI cluster

Three things, all of which land on Video-Based WSI Mosaicing:

1. A third independent implementation of the same registration conclusion. DIY WSI and Video to WSI both built rich-transform machinery and both ship translation-only phase correlation, reasoning from accumulated drift. Micro-Manager’s TileAligner is phase-correlation-on-overlaps too — but with a stage, translation-only is true by construction, and it adds the step neither local project has: global optimisation over the grid rather than chaining pairwise shifts, which is what stops drift compounding across a large mosaic.
2. Stitching accuracy is measured, not eyeballed. That page’s open question — “is stitching accuracy measured anywhere, or only judged by eye?” — has its first concrete answer in this cluster: an RMS-deviation-from-nominal-grid summary, computable exactly because the stage supplies a nominal position to deviate from. A hand-moved slide has no nominal grid, which is why the local projects could not produce this number — the metric is a property of having a stage, not of better software.
3. Calibration is solved by construction rather than defaulted. The µm/pixel problem that both local projects default to 0.5 (the cluster’s recorded calibration gap) does not exist here: pixel size comes from the device configuration, which is the “supplied, not estimated” arm of that page’s framing.

Provenance and currency

Historical provenance is stated in doc/copyright.txt: developed in the Vale Lab at UCSF, funded by the Sandler Foundation, designed by Nenad Amodaj with Nico Stuurman — text that reads as written in the project’s first era and left standing. Current governance is what the governance/ directory shows: a community project with core-developer guidelines and a formal Micro-Manager Improvement Proposal process. The project’s current institutional home, if any, is not asserted here — the website names none and the repository does not either. [unverified]

Currency is in the frontmatter and is exceptional: this is the most actively developed tool evaluated in this wiki, and the 317 GitHub stars are a reminder of why stars are a weak signal — the repository moved to GitHub in 2015, a decade into the project’s life, and its users are laboratories rather than developers.

Python: the site documents a Python library route; pycro-manager and pymmcore exist as separate repositories and were not evaluated — pointer only.

Current state / open questions

• The concrete question this leaves for the cluster: if a motorised stage ever arrives, the build-versus-adopt decision for DIY WSI inverts — Micro-Manager plus a stage covers acquisition, alignment, quality measurement and pyramid export, with only the RGB-pyramid boundary in the way, and that boundary is a compositor limitation rather than an architecture one. Whether any microscope in the department has a motorised stage is not recorded anywhere in this wiki. [unverified] — and it is the cheapest fact that would settle the question.
• The mmCoreAndDevices submodule (the C++ core and every device adapter) was not cloned or read; claims here are about MMStudio and its libraries. [unverified] for anything device-layer.
• Whether the Explorer/ExportTiles path is released in current nightly builds or exists only in the tree was not established — the Explorer plugin is versioned “0.1”. [unverified]
• Licence: recorded as declared, one line, per AGENTS.md §8. The absence of a top-level LICENSE file (GitHub reports license: null) is noted as a fact about the repository, not investigated further.

How it connects

Video-Based WSI Mosaicing — the method page this reading feeds: a third convergent registration design, the cluster’s first measured stitching error, and the demonstration that both come from having a stage.

DIY WSI — the local project whose “why not Micro-Manager?” question this page answers: no motorised stage, and a manual-scope premise Micro-Manager does not serve.

Video to WSI — same relationship; its upload-a-recording design is precisely the no-hardware end of the spectrum Micro-Manager anchors the other end of.

Whole Slide Imaging — the pyramid, tile and metadata concepts here are that page’s, arrived at from the acquisition side rather than the scanner side.

WSI Quality Control — TileAligner’s accepted-pairs and RMS summary is another instance of that page’s favourite object: a computable quality signal produced as a by-product of doing the work.

Slide Metadata Extraction — µm/pixel from device configuration versus estimated after the fact is the acquisition-time version of that page’s measured-versus-computed distinction.

Derived from: full clone of micro-manager/micro-manager read 2026-08-23 (git log, git shortlog, .gitmodules, README.md, doc/copyright.txt, governance/, plugins/Explorer/, plugins/AcquireMultipleRegions/, libraries/ExportTiles/TileAligner.java, libraries/TiledDataProvider/OMEBigTiffMultiresStorage.java and OMEBigTiffTiledStorage.java); GitHub API for stars, forks, issues, licence field and the absence of releases; micro-manager.org homepage and the Micro-Manager User’s Guide fetched the same day. Nothing was installed or run; the device-layer submodule was not read.