Skip to content

Plugin categories

A category defines what kind of processing a plugin performs — ctf, motioncor, particle_picking, and so on. One category can have multiple backends: interchangeable implementations that accept the same input schema and produce the same output schema but run different algorithms or tools underneath.

Operators choose which backend serves each category (or pin a specific one per dispatch). The framework handles routing, progress streaming, and replica management automatically.

CategoryCodePipeline stepWhat it doesCurrent backends
fft1FFTComputes the magnitude-spectrum FFT (power spectrum) of a micrograph. The “always-on” reference — every micrograph gets one.fft
ctf2CTF estimationFits the microscope’s Contrast Transfer Function (defocus, astigmatism, CTF goodness-of-fit) to each aligned micrograph.ctf (ctffind4 native / fast / GPU / external)
particle_picking3Particle pickingLocates particle coordinates (x, y) in each micrograph using template cross-correlation.template-picker
two_d_classification42D classificationClusters extracted particle images into K class averages by appearance; used to remove junk particles. Input is a particle stack, not a single image.can-classifier
motioncor5Motion correctionAligns frames in a raw movie to remove beam-induced specimen motion, producing a single sharp micrograph.motioncor (MotionCor2/3)
square_detection6Target selectionLocates grid squares in low-magnification overview images using an ONNX neural network.ptolemy/square
hole_detection7Target selectionLocates ice holes in medium-magnification images for high-magnification acquisition targeting.ptolemy/hole
topaz_particle_picking8Particle pickingCNN-based particle picking using Topaz, without requiring a template.topaz
micrograph_denoising9DenoisingDenoises micrographs using the Topaz denoising network as a pre-processing step.topaz-denoise
particle_extraction10Particle extractionCuts normalised particle boxes around picked coordinates and writes them into a .mrcs stack.stack-maker
Category codes are stable

Category codes (the integers in the Code column) are part of the wire protocol — they appear in every task message on the bus. They never change once assigned. New categories always receive the next unused integer.

When two or more plugins register under the same category, Magellon gives operators full control over routing:

  • Default backend — one backend is pinned as the category default. Dispatch without a target_backend preference goes here.
  • Set as default — any installed backend can be promoted to default from the Plugins panel without restarting anything.
  • Backend pinning — callers can request a specific backend by name (e.g. target_backend: "template-picker") on a per-job basis.
  • Round-robin within a backend — if that backend has multiple replicas running, tasks are distributed across them automatically.

The per-category drilldown at /panel/plugins/categories/<slug> shows every backend side-by-side with live replica counts and a one-click Set as default action.

Most categories operate on a single image (one aligned micrograph). The exception is two_d_classification, which operates on a particle stack — a collection of particle boxes drawn from many micrographs combined into one .mrcs file. The framework routes and tracks these differently:

Subject kindWhat it meansCategories
imageOne task per micrographAll categories except two_d_classification
particle_stackOne task per extracted particle settwo_d_classification
Writing a new backend

If you want to add a second CTF engine, particle picker, or classifier, you only need to implement execute(input_data, reporter) and declare the matching category and backend_id in your manifest.yaml. The routing, queue wiring, and UI integration happen automatically. See the Plugin authoring guide to get started.