### 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](/research/arrow-study-2026/methods/slow-motion-measurement/)
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](/research/arrow-study-2026/methods/foc/).
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{" "}
[Figure: Equation]