Slow-Motion Capture & Preparation

Overview

On top of the standard group-size testing, a subset of the 2026 front-of-center (FoC) builds were filmed with a Phantom high-speed camera so we could measure what each arrow was actually doing in flight: how much the shaft bends (flex) and how far the nock swings off the line of travel (yaw). The numbers behind the early-flight characteristics analysis of the FoC results all come out of this pipeline.

This page covers the front half of that pipeline: how the camera is set up, how each clip is trimmed and oriented, and how a small set of per-shot calibration values is built from hand-annotated frames. The companion page covers the per-frame detector that consumes those calibrations and the per-shot and cross-shot aggregation that produces the final yaw and flex profiles.

We use "torqued" throughout to mean a shot taken with the bow deliberately rotated in a calibrated torque jig, the same setup used for the broader FoC group-size protocol on the Front-of-Center Testing Overview. A "build" is a single (shaft, spine, point weight) combination from the FoC matrix.

Capture

A Phantom high-speed camera is mounted overhead looking straight down at an 8 ft table that runs between the shooting machine and the target. The camera frames the table so the full 8 ft of table width fits across the 1280-pixel image. The arrow flies over the table roughly parallel to the table's long edge, and a long tape measure is laid along the table between the shooting machine and the target.

Each cine file holds one shot. The camera is triggered by a microswitch on the bow release, recording at 5000 fps with a 40 µs shutter at 1280×832 px and 10-bit depth.

The camera stays put for any given group of shots but is relocated along the table to capture different segments of the arrow's flight, so the recording delay between trigger and arrow-in-frame has to be re-tuned at each station. At the 40 ft station the arrow takes much longer to arrive than at the 0 ft station. At each station, three torqued and three untorqued shots are captured per build.

For every shot the operator writes down which build was on the string, whether the bow was torqued, the bow-to-table distance, and the timestamp the shot was fired. The wall-clock timestamp matters because the cine file header carries its own trigger timestamp from the camera's internal clock, and matching the two is how each cine on disk gets bound back to its build, torque, and distance entry in the log.

Three things go wrong during capture often enough to call out:

• Empty cines. The release-switch tether is not perfectly reliable. Many triggers fire with no arrow in frame, either because the trigger fired without an actual release or because the capture buffer was already full from a previous trigger. These cines contain no arrow motion and have to be removed before any frame-level processing.
• Re-positioning between shots. To cover the full flight from bow to target, the camera is relocated along the table between groups of shots. Each shot therefore sees only about 6 ft of trajectory at most; the full flight is reconstructed by stitching segments from many shots at known camera distances.
• Capture direction. Depending on which end of the table the bow is on for a given station, the arrow flies left-to-right or right-to-left across the frame. The orientation flip in the preparation step below makes the rest of the pipeline indifferent to this.

Preparation

Cines are large and many of them are empty, so they are not processed directly. Three things happen between capture and the per-frame detector.

Trim to In-flight Frames

Each cine is scanned with an external motion detector that scores per-frame motion against the static background and reports the first and last frames where motion occurs. The resulting motion span is opened in a spreadsheet, padded by 50 frames on each side so the arrow's entry into and exit from the camera buffer is not clipped, and obvious bad cines are removed by hand at the same time. Cines with no detected motion across their entire length are marked empty and dropped from the dataset. The kept ranges are written back into the shot log as motion-start and motion-end, so later steps can map an in-flight frame number back to its position in the original cine.

Export as TIFFs

The cleaned trim list is handed to an external trimming tool that reads each cine and writes out only the frames inside the trim window as TIFF images, one directory per surviving shot. Trimming up front means every later step in the pipeline operates on small, fast-loading TIFF stacks instead of re-decoding gigabyte-scale cines.

Flip to Left-to-Right

Right-to-left captures are flipped horizontally so that in every TIFF the rest of the pipeline sees, the tip is the higher-x point and the nock is the lower-x point. The firing direction is preserved in the shot log as direction (ltr or rtl) so the original orientation is recoverable, but everything from this point on can assume arrows fly left-to-right and that tip_x > nock_x. The detector never has to disambiguate which end of the detected segment is the tip.

The output of this stage is, per surviving shot, a directory of TIFFs named frame_NNNNN.tiffwhere the number is the frame's position in the original cine, plus a shot-log row carrying its build, torque, distance, direction, and motion-window bounds. Cine header metadata (fps, resolution, trigger time, lens, and so on) is extracted separately and stored alongside, so downstream steps can recover frame rate and image dimensions without re-opening the cine.

Manual Annotations

A small fraction of frames from each shot are hand-annotated to give the detector ground truth and to fix per-shot scale and reference geometry. Two kinds of points are placed.

• Arrow tip and nock.For three frames near the middle of each shot's flight window, the tip and nock pixel coordinates are marked in an external image annotation tool. These three frames per shot give a calibrated arrow length in pixels, an expected chord angle, and an independent ground truth that the detector's output is later checked against frame by frame. Mid-flight is the best window because the entire arrow is reliably visible there; in earlier or later frames one end can be off the edge of the image.
• Tape measure edge. Several points along the bottom edge of the tape measure are marked, spread across the full width of the frame. The tape lies along the table, roughly parallel to the flight path but offset vertically below it. Its job downstream is purely geometric: it defines a straight line in image coordinates that is parallel to the arrow's direction of travel, against which the arrow's yaw can be measured. The tape edge is annotated rather than auto-detected because its contrast varies between shots and an unsupervised edge detector would not reliably pick out the bottom edge over the top edge or a glare line.

Both annotation types share one TSV; the per-shot calibration step splits them back out and consumes each separately.

Per-Shot Calibration Values

From the manual annotations, three calibration values are computed once per shot and reused for every frame of that shot: the arrow length in pixels, the tape reference polynomial, and a per-build flex envelope inherited from a reference build.

Arrow Length in Pixels

For each shot, the Euclidean distance between the annotated tip and nock points is computed for each annotated frame and the mean across frames is taken as the calibrated arrow length in pixels for that shot. The sample standard deviation is recorded as a sanity check: shots with a deviation larger than a pixel or two are flagged for re-annotation.

This pixel length is the per-shot scale ruler. Combined with the known physical arrow length in inches, it converts every later pixel measurement to inches at the height the arrow flies. That distinction matters because the arrow flies above the table and is therefore closer to the camera than the table itself, so the on-screen pixels-per-inch at the arrow's height are larger than the pixels-per-inch at the table surface. Using a table-based scale would systematically underestimate physical distances at arrow height by a few percent.

Tape Reference Polynomial

The annotated tape points are used as seeds for a more precise edge fit. At each seed location a column of pixels is extracted and the strongest positive- and negative-gradient peaks within a search window are taken as the bottom and top edges of the tape. Detections are accepted only when the two edges are separated by a plausible tape width and the bottom edge sits close to the annotated y. The accepted bottom-edge points are fit to a low-order polynomial, the full frame width is then re-scanned using the polynomial as a seed, and a final polynomial is fit to the consolidated, outlier-rejected bottom-edge points.

The result, per shot, is a quadratic of the form:

which in practice is essentially a straight line (the quadratic coefficient is near zero) running parallel to the flight path. The detector uses the linear portion of this polynomial as the reference axis for yaw: the perpendicular offset of the nock from a line tangent to the polynomial at the tip's x is the per-frame yaw. The quadratic portion is kept around as a diagnostic for tape straightness, which can pick up lens distortion or a slightly bowed tape.

Before downstream steps consume the fit, each shot's polynomial is overlaid on its source frames in a validation viewer so that bad fits, usually caused by glare or annotation drift, can be caught and re-annotated.

Per-Build Flex Envelope

The detector needs a physical prior on how much a given arrow can plausibly flex, otherwise low-signal frames can produce wildly large lateral fits. That prior comes from a single dense annotation. For one carefully chosen reference build (340 spine, 350 gr front weight, 29.75″ arrow length), many points are marked along the shaft at its point of maximum flex, and the lateral deviations of those points from the straight tip-to-nock chord are fit to a power-law shape:

where t ∈ [0, 1] runs from tip (t = 0) to nock (t = 1). The fit gives an amplitude A (which converts to a maximum-flex value in thousandths of an inch via the per-shot pixel scale) and the shape exponents α and β that locate the peak of the flex curve at t = α / (α + β).

The reference build's parameters are then scaled analytically to every other build. Amplitude scales linearly with spine number (a stiffer-spine arrow flexes less under the same load), and the α, β exponents scale with FoC according to a cantilever-beam first-mode argument: a heavier tip shifts the peak of the flex curve toward the nock, which corresponds to a larger α / β ratio. The resulting per-build (α, β, max_flex_thou) triple is what the detector uses as a physical envelope: any measurement of lateral deviation larger than the envelope predicts is treated as noise.

The envelope serves two purposes inside the detector. It bounds the lateral-amplitude fit on each frame to prevent runaway fits in low-signal frames, and when no per-frame measurement is available it provides the analytic shape of the flexed centerline.