Fast OFM: Moonraker motion, RG autofocus and pyramidal WSI

Contributions
1

Hello OpenFlexure community,

I am Alexander Fridman, and I am preparing a prototype checkpoint called
Fast OFM, an independent whole-slide-imaging extension built on the
OpenFlexure Microscope Server. It is not an official OpenFlexure release. I
decided to share this work to support accessible digital microscopy and to
expose several reviewable implementation boundaries that may be useful
independently—not to present the combined fork as a monolithic alternative.

The prototype uses an existing custom Cartesian linear stage. The work in this
release begins at its controller boundary: MKS/Klipper motion control, the
Moonraker-backed OpenFlexure stage, Arduino/MKS illumination, RG calibration and
focus estimation, sparse focus prediction, scan orchestration, stitching
acceleration and pyramidal OME-BigTIFF output.

03-fast-ofm-red-green-autofocus
03-fast-ofm-red-green-autofocus1774×887 117 KB

Current architecture

  • replaceable compute host: OpenFlexure server, scan planning, camera access,
    RG analysis, focus-surface updates and image storage; the measured scan used
    Raspberry Pi 4 and the current deployment uses Raspberry Pi 5;
  • MKS Robin Mini V2.0: Klipper step generation for the installed X/Y/Z motors
    and RED/GREEN/WHITE timing gates;
  • Arduino-compatible controller: configured channel brightness values at
    62.5 kHz PWM;
  • x86 server: replay/benchmark environment for stitching and OME-BigTIFF.

The accepted prototype is still stop-and-shoot. It used commanded stepper
position and an operator-defined local zero; verified homing and encoders are
not claimed.

The architectural portability claim is deliberately narrow. Sangaboard has
USB-capable configurations, but the current OFM v3 appliance documentation is
centred on Raspberry Pi 4 plus Sangaboard v0.5. The MKS/Klipper/Moonraker
boundary lets the motion controller attach independently of a particular Pi,
so the scanner host could later be a Pi 5, another Linux SBC or a desktop-class
computer with a USB industrial camera. The timings below remain Pi 4 timings;
I have not yet produced a matched Pi 5 comparison.

Project map:

The GPL server talks to the noncommercial core only through versioned JSON and
verified file artifacts; it does not import that implementation. The final
registration/rendering process remains separately replaceable under
LGPL-3.0-only because it adapts openflexure-stitching.

1. Moonraker-backed XYZ stage

The MKS board runs Klipper, and the server controls it through a bounded
Moonraker stage backend. Machine configuration remains separate from the OFM
adapter:

I would appreciate feedback on whether a generic Moonraker-backed stage would
be useful upstream, and which machine-specific assumptions should be removed
before preparing a focused PR.

2. Split Arduino/MKS illumination control

The Arduino sets configured RED/GREEN/WHITE PWM brightness values; the MKS
board gates the channels for scan timing. Hardware current limiting remains
mandatory.

The repository also contains a newer firmware candidate, but the accepted scan
used v4; I have kept that distinction explicit.

3. Simultaneous red/green focus

The focus path selects tissue-bearing windows, estimates R/G displacement,
applies measurement QC, converts the calibrated shift into bounded signed Z,
and refuses unsafe results. It can recover patches outside the central crop and
falls back to WHITE autofocus if RG cannot produce a valid result.

4. Sparse focus map and prediction

Accepted RG measurements become anchors in a local focus surface. Later fields
can use bounded predicted Z; insufficient support requests another measurement,
and invalid RG can route to WHITE autofocus rather than aborting the scan.

In one accepted physical run, 30 saved fields used measured RG focus and 67
used predicted Z. No WHITE fallback was needed in that run, although the
fallback path remains part of the design.

5. Stitching and WSI output

The current stitcher reuses forward FFTs under a bounded cache, releases that
cache before rendering, precomputes the actual-neighbour graph and packed
nearest-centre/Voronoi ownership masks, reuses decoded images, and supports
multiple disconnected tissue regions using stage coordinates plus local
component alignment. Output is pyramidal OME-BigTIFF.

On a retained 91-tile 4K dataset, the matched OME-only path improved from
180.41 s to 150.28 s with three workers and a 4 GiB cache budget. A 20-tile
renderer test improved from 42.33 s to 19.64 s. The matched pixel comparison had
maximum channel delta zero in that timing A/B. Final review then corrected the
preview downsampler’s one-pixel outer-edge loss. A synthetic ground-truth replay
is now level-0 exact including the final row and column; the 91-tile post-fix
replay retained identical registration geometry and changed 0.00746% of pixels
relative to the pre-fix file. A faster expected-overlap-strip experiment failed
the accuracy gate on two pairs, so it is not the default.

The data-free final file was also opened in QuPath 0.5.1 through Bio-Formats,
which detected the base image and one SubIFD reduction as two levels. This
exposed an important deployment constraint: libvips 8.9 multi-page output is
seen as a flat single-level image, so OME export now requires libvips 8.10+ and
refuses incompatible hosts before rendering. DZI-only export still works there.

Physical reference run

The accepted scan used an adaptive tissue-aware spiral with a 7.5 mm
centre-radius planner limit. Its saved-field centres span 8.808×13.200 mm and,
after adding the calibrated 4K field span, the retained fields’ axis-aligned
bounding footprint is approximately 10.108×14.179 mm. This is a bounding
box, not a fully populated rectangle. The 15mm suffix in the historical scan
identifier records the planner’s nominal 15 mm diameter; the measured result
below uses the actual retained-field footprint:

  • 132 addressed locations;
  • 97 saved 4056×3040 fields;
  • 35 background skips;
  • 30 RG anchors;
  • 67 predicted-Z captures;
  • 0 WHITE fallbacks in that run;
  • 572 s / 9:32 acquisition time.

The separate 91-tile dataset used for the x86 stitching benchmark has an input
footprint of approximately 10.1081×10.0543 mm.

A planned 14×18 route with an approximately 15.613×15.004 mm bounding
footprint is currently estimated at about 14.7 minutes by scaling a separate
measured 6×14 stop-and-shoot run—294.6 seconds for 84 addressed positions—by
three to 252 positions. Separately, scaling the 91-tile stitching benchmark by
the 2.3051 footprint-area ratio gives about 5:46 with a warm cache. Adding the
measured correlation cost scaled from 158 to 472 expected neighbour pairs gives
a rough first-cold estimate of 8:06. These are extrapolations, not completed
end-to-end measurements.

Candidate upstream boundaries

I would particularly value guidance on four possible contribution boundaries:

  1. Is the Moonraker stage backend useful as a small independent contribution?
  2. Should RG measurement/calibration remain a separate package from OFM focus
    policy and UI integration?
  3. Would a generic sparse-focus-surface primitive be useful even without RG?
  4. For stitching, is it better to propose FFT reuse, renderer ownership masks
    and disconnected components as separate PRs?

The preferred future path uses a triggered 4K global-shutter camera and moves
the prepared motion/light/trigger schedule onto a deterministic controller
timeline. The compute host would first extract tissue boundaries and sparse
focus points from a prescan, then transfer the route and focus schedule. The
controller would execute the trajectory, apply scheduled Z, select illumination
and trigger the camera. Each exposure would emit a typed frame event carrying a
frame ID, coordinates and RG or WHITE mode; the host would retrieve the
matching frame, update the focus surface from RG evidence and send bounded
corrections for future route segments. A dedicated Pico-class companion remains
a fallback if the MKS interface cannot provide the required trigger semantics.
Eliminating repeated stop-and-host-round-trip latency could plausibly increase
acquisition throughput by more than 2×, but that is a design target rather than
a measured result. It still requires validation of motion blur, row-turn
acceleration, camera buffering, event-to-frame identity and focus-update
deadlines.

This controller-owned timing does not eliminate stitching. The released
prototype has no encoder feedback, and commanded coordinates cannot account for
all backlash, missed-step, compliance and optical errors. High-resolution
encoders could ultimately make coordinate-first tile placement accurate enough
to replace most correlation with verification, but that requires measured
image-space residuals across the full travel. Until then, encoder coordinates
should seed registration rather than be treated as ground truth.

Thank you to the OpenFlexure maintainers and contributors for the platform this
work builds on. I welcome critical review, especially
where the current code is too coupled to this particular prototype.

Fast OFM is a research prototype; it is not
clinically validated and is not for diagnostic use. Fast OFM is independent
and not endorsed by OpenFlexure. OpenFlexure- and Klipper-derived code retains
GPL licensing; original Fast OFM repositories document their separate
licensing boundaries.

2

Hi Alex,

We do not yet have an AI policy, but we are likely to block/remove long AI generated posts about AI generated repositories, as they add little value to the community. Especially when the hardware repository is only markdown files.

I would ask you to reconsider your name. While we have no copyright/trademark on the OFM acronym it does seem purposefully chosen to imply that your project is part of the OpenFlexure Microscope project.

3

Hi Julian,

Thank you for the feedback. I would like to clarify the scope of the project, because I do not think “AI-generated repositories” accurately describes what is being shared.

Fast OFM is an independent software R&D project built around OpenFlexure. It is not part of, endorsed by, or affiliated with the OpenFlexure project, and this is stated in the repositories and article.

The published work comes from experiments on a physical microscope prototype. It includes motion-controller integration, illumination control, autofocus calibration, measured red/green focus data, predictive focus-surface estimation, acquisition telemetry, real scan results and stitching benchmarks. AI-assisted tools were used during parts of the implementation and documentation process, but the engineering decisions, experiments, measurements and validation are the substance of the work.

The hardware repository does not contain CAD or manufacturing files because the mechanical design was created by another contributor and is not mine to publish. I do not want to claim ownership of that work or release it without permission. The available hardware material therefore documents only the interfaces required to understand and reproduce the software integration.

The material I am offering to the community is primarily software:

  • Klipper/Moonraker motion-control integration for OpenFlexure;

  • RED/GREEN/WHITE illumination control;

  • calibrated red/green autofocus with quality checks and WHITE fallback;

  • sparse focus anchors and predictive focus-surface estimation;

  • acquisition planning and telemetry;

  • measured stitching optimisations and pyramidal OME-BigTIFF output.

I also intend to submit the generally applicable stitching improvements as a pull request to the upstream stitching repository, where they can be reviewed on their technical merits independently of the rest of this prototype.

The name was chosen for an independent project concerned with accelerating an OpenFlexure-based imaging pipeline, not to imply that it is an official OpenFlexure project. I am happy to make the independence notice even more prominent, but I believe the software, experiments and reproducible results can be evaluated on their own merits and may be useful to the community.

I can keep the forum post concise and focused on the concrete software contributions, measurements and upstream-relevant changes.