Filter Wheel

Catalogs quote the move: 25 to 50 ms between adjacent positions on a good wheel. The figure that governs your scan is larger, for two reasons neither of which appears in the specification.

The wheel has to stop oscillating before you expose. A filter is a disc of glass in a mount at the end of a rotating arm, and it rings for some tens of milliseconds after the motor says it has arrived. Expose into that and you have blurred an image by a mechanism no amount of focusing will fix.

And the move is not always to the next position. A six-position wheel asked to go from 1 to 4 travels three steps, not one, and three times the distance and rather more than three times the settle.

Cost it out. Four channels over 500 fields, at 80 ms per change including settle: 4 × 500 × 0.08 = 160 seconds, or 2 minutes 40 seconds per plate, spent entirely on moving glass. Across a twenty-plate run that is 53 minutes. It does not appear anywhere in the exposure settings and it is most of the difference between an overnight run that finishes and one that does not.

This one is free, and it is skipped almost universally because acquisition software lists channels in the order you created them.

If DAPI is in position 1, your marker in position 4, a counterstain in position 2 and a control in position 5, then acquiring in that order walks 1→4→2→5: three steps, then two, then three, and back four to start the next field. Twelve steps per field.

Acquire in wheel order — 1→2→4→5 and back — and it is one, two, one, and four home. Eight steps. You have removed a third of the mechanical travel by reordering a list, and the images are identical.

Two refinements if you are already this far in. Arrange the wheel itself so the channels you always acquire together are adjacent, since the positions are yours to assign. And if your software supports serpentine ordering, let alternate fields run the sequence backwards, which removes the long trip home entirely.

This is the cheapest speed improvement available on any instrument, and it costs one afternoon of thinking about the order of a list.

A filter wheel puts every channel on the same sensor, through the same optical path, onto the same pixel grid. Your channels are registered because they are physically incapable of being otherwise.

Set that against a multi-camera splitter, where every channel lands on a different sensor and alignment must be solved from bead calibrations, maintained against thermal drift, and re-solved when anything is touched. For colocalization, for ratiometric imaging, for anything where the question is whether two signals occupy the same place, the slow instrument is the one whose answer needs no asterisk.

The same sensor also means one gain, one read noise, one flat-field, one set of hot pixels. Intensities are comparable across channels without cross-calibrating instruments.

Which sets the choice out plainly. A filter wheel costs you time and keeps your geometry and your photometry honest. A splitter costs you geometry and photometry and buys back time, plus simultaneity, which is the one thing a wheel genuinely cannot offer, and the only reason to give the rest up.

Everything above concerns one plane. Add a Z dimension and the overhead does not add, it multiplies, and which way it multiplies is a choice most people never notice they are making.

Acquisition software offers two loop orders. Channel inside Z means: go to a plane, collect all six channels, move to the next plane. Z inside channel means: collect the whole stack in one channel, then change the filter once and collect the whole stack again.

For a 500-plane stack in 6 channels at 80 ms per filter change, the first order costs 500 × 6 = 3,000 filter changes, or 240 seconds: four minutes of a rotating wheel. The second costs 6 changes. Half a second. The images are the same images.

So why is channel-inside-Z the default, and often correct? Because the two orders differ in when each channel was acquired. Channel-inside-Z puts all six channels of a plane within a few hundred milliseconds of each other, so anything moving stays registered and bleaching affects all channels about equally. Z-inside-channel separates them by the full duration of a stack, so channel six was acquired minutes after channel one, on a sample that has been illuminated the whole time.

Which means the rule is legible: fixed and stable, loop Z inside channel and take the four minutes back. Live, moving, or bleaching visibly, loop channel inside Z and pay. What you should not do is accept whichever the software opened with, which is what usually happens.