Server-Side Slide Platforms

Running whole-slide viewing, annotation and analysis on a shared server that several people reach through a browser, instead of on one pathologist’s desktop — and what that architecture changes about storage, jobs, and how an analysis has to be packaged.

Running whole-slide viewing, annotation and analysis on a shared server that several people reach through a browser, instead of on one pathologist’s desktop — and what that architecture changes about storage, jobs, and how an analysis has to be packaged.

What it is

Almost everything image-side in this group runs on QuPath: a desktop application, opening files from a local or mapped drive, with analyses written as Groovy scripts or packaged as QuPath extensions. One person, one machine, one session. That is the default, and QuPath Tooling indexes the whole cluster built on it.

The alternative is a server. A slide platform of this kind — the instance here is a Digital Slide Archive deployment, imagebank — is a set of cooperating services rather than an application:

• an application server (Girder) holding users, permissions, collections and metadata;
• a tile server (large_image) that serves pyramidal regions over HTTP, so the client never holds the slide;
• a browser viewer (HistomicsUI) that draws annotations against those tiles;
• a database (MongoDB) where annotations and metadata live, shared by construction;
• a queue and workers (RabbitMQ) so an analysis runs as a background job.

The user opens a URL. Nothing is installed, nothing is downloaded, and two people can be looking at the same slide with the same annotation layer.

What actually changes

Five things, and they are the reasons to choose this rather than side-effects of it.

1. Annotations become shared state rather than files. In the desktop model an annotation lives in a project file on someone’s disk, and collaboration means sending it. Here it is a row in a database with an owner and permissions. This is the single biggest difference and the one that motivates the whole architecture.

2. Storage decouples from the application. Slides sit on a mounted volume that both the tile server and any analysis container can read. Configured well, an analysis reads the slide in place rather than downloading a copy — imagebank does this through a shared mount and a configured asset-store path. On WSI-sized files the difference between reading in place and copying per job is the difference between a workable pipeline and an unworkable one.

3. Analyses become jobs, not sessions. Work is submitted to a queue and a worker picks it up, so a long run does not occupy the person who started it and a batch can proceed overnight. The desktop equivalent is a script that must not be interrupted.

4. There is a REST API, so the platform is programmable. Anything the browser can do a script can do, which makes the platform addressable from Python without a GUI in the loop.

5. Plugins must be containerised, and this is the real cost. An analysis is not a script you drop in a folder. It is a Docker image plus an XML manifest describing its parameters, which the platform reads to generate a form in the Analyses menu; the tool receives an authentication token and posts its results back to the API itself. That is a genuinely different packaging target from a QuPath extension, with its own build, its own registry and its own failure modes — and writing for it is a commitment to maintaining a second plugin ecosystem alongside the Groovy one.

Why it matters for my work

The group has one instance of this and fifty of the desktop alternative, so the honest framing is not “which is better” but what the server buys that is otherwise unavailable. On the evidence here that reduces to one thing: more than one person working on the same material at the same time, with permissions and a shared annotation store. Nothing in QuPath Annotation Workflow provides it, and no amount of QuPath tooling will.

That is worth something specific and bounded — a reader study, a consensus annotation exercise, a teaching set several trainees annotate, or handing a cohort to a collaborator without giving them a drive. If none of those is the actual need, the server is overhead.

Three cautions the local instance makes concrete.

The platform is not the plugins. Upstream DSA/HistomicsUI/HistomicsTK is mature software. The analyses written for a local deployment are ordinary local code and get no reliability from sitting inside it — in imagebank the viewer works and all three locally-written QC tools are defective, one of them provably unable to produce a passing result. A menu entry in a professional-looking web interface confers an authority the code behind it may not have earned.

Naming inside a plugin menu is a load-bearing decision. A menu entry is often all a user sees before trusting a number. imagebank ships a plugin presented as “GrandQC Quality Assessment” whose container holds no deep-learning framework at all, in an estate that also contains a real GrandQC wrapper and a study measuring it — so one phrase now denotes two unrelated computations. On a desktop tool the script filename is at least visible; here the implementation is behind a form.

A deployment is a thing that rots. A desktop tool that nobody opens for a year still opens. A Compose stack of five services, GPU drivers, a model server and a set of images does not survive neglect as gracefully — imagebank has been dormant nine months, and standing it up again is a real task rather than a double-click. Server platforms carry an operating cost that has to be somebody’s job.

How it connects

imagebank — the estate’s only instance, and the source for everything on this page.

QuPath Tooling — the desktop hub this is the alternative to; the two are complementary in principle and only one of them has fifty projects behind it.

QuPath Annotation Workflow — the single-user annotation route, and the thing a server platform changes rather than replaces: the annotation work is the same, the sharing is not.

WSI Quality Control — the method whose local implementations here are the cautionary example; a QC plugin inside a platform is still just QC code.

Patch Extraction — a tile server already solves reading arbitrary regions at arbitrary magnification over HTTP, which is most of what a tiling pipeline does by hand.

DZI Web Publication — the other browser-based route already in use here, and the contrast worth holding: DZI publishes a fixed, anonymised, read-only slide to viewers, while this serves a live, writable, access-controlled archive. Publishing needs a gate; a platform needs accounts.

De-identification — a shared server changes the question from “is this file safe on my disk” to “who can reach this collection”, and the answer becomes a permissions matrix somebody has to maintain.

Open questions

• Was the local instance ever used by more than one person? The entire argument for this architecture is multi-user work, and nothing in imagebank records any usage at all. Unanswered, and it decides whether the deployment is worth reviving. [unverified]
• Is model-assisted annotation the real reason to want a server? imagebank runs MONAI Label — click-to-segment and in-loop retraining — which is easier to host beside a GPU than to distribute to desktops. That capability has no page in this wiki and has not been appraised here; it may be a stronger argument for the architecture than the sharing is. [unverified]
• What is the smallest useful version? A tile server plus a viewer, with no job queue, no worker and no plugin ecosystem, would deliver the sharing benefit at a fraction of the operating cost. Nobody has costed that middle option.
• Other platforms in this space — OMERO, caMicroscope — are linked from imagebank’s README but none has been evaluated here, so no comparison on this page should be read as a survey. [unverified]