### Overview

This page picks up where the
[slow-motion capture and preparation page](/research/arrow-study-2026/methods/slow-motion-capture/)
leaves off. By that point each surviving shot is a folder of high-speed
frames plus a small set of per-shot calibration values (arrow length in
pixels, tape reference line, per-build flex envelope).

What we do here is find the arrow in every frame, turn each frame into a
yaw number (how far the nock has swung off the direction of travel) and a
flex number (how much the shaft is bowing in the middle), filter out bad
frames, summarize each shot down to one number at one bow-relative
position, and then average across the three repeats at each (build,
torque, distance) cell.

The end product is a per-(build, torque, distance) profile of how yaw and
flex evolve in the first ~45 ft of flight. The last section,
[Limitations and Future Capture Changes](#limitations-and-future-capture-changes),
is the honest list of what currently leaks into those numbers.

### Per-Frame Detection

For each frame in the shot, the detector produces tip and nock pixel
coordinates, the angle of the line between them (the chord), 60 sample
points along the shaft, and a valid-or-not flag with a reject reason.
Everything below runs once per shot, frame by frame.

#### Subtract the Background

Almost everything in frame does not move. The tape measure, the table
grid lines, dust on the lens, stuck sensor pixels: they sit on the same
pixels in every frame. The arrow occupies any given pixel for only a few
frames as it sweeps across the field of view.

That gap lets us recover the stationary background cheaply. For each
pixel, the color it has across the majority of frames is the background;
the arrow only ever shows up as the minority. Taking the median across
all frames in the shot produces a clean background image. Every frame is
then re-expressed as itself minus that background, recentered to a
neutral gray. The transformed frames look like a uniform gray field with
the moving arrow and any per-frame lighting noise still visible; the
stationary clutter is gone.

#### Find the Arrow as Motion

On the background-subtracted frames, the arrow's position is found by
subtracting each frame from the previous one (frame differencing) and
keeping the pixels that changed the most. After a small noise-cleanup
pass, any pixel whose change exceeds a threshold becomes part of the
motion mask for that frame.

The motion mask is not a clean silhouette of the arrow. A long, uniform
stretch of shaft looks almost identical frame to frame, so the only
pixels that show up as motion are the tip leaving its previous position
and entering a new one, the nock doing the same, and any colored bands
along the shaft. The detector treats the motion mask as a sparse cloud of
"arrow signal" pixels, not as a solid blob to be cropped.

Two whole-frame guards run before any geometry is attempted:

- If more than 10% of the frame's pixels are motion-positive, the frame
  is rejected as a global lighting change (a flicker or exposure shift).
  A real arrow never covers anything like 10% of the frame.
- If fewer than 60 motion pixels survive, the frame is rejected as too
  quiet to fit. Tiny isolated specks (under 8 pixels) are dropped as
  sensor noise before the surviving pixels are handed on.

A straight line is then fit through the surviving pixels using a method
that down-weights a handful of stray pixels (shadows, sensor blips)
rather than letting them drag the line off course the way an ordinary
best-fit line would. The result is the arrow's long axis in this frame.
Pixels more than about 8 px perpendicular to that line are dropped as
outliers; the rest are the inliers, the motion pixels actually
attributable to the shaft. If the inliers do not span at least 40% of the
calibrated arrow length, the frame is rejected. Shorter spans almost
always mean the arrow is partly out of frame or the line locked onto a
small cluster of noise.

#### Identify the Tip and Nock

Initial tip and nock estimates come from the extreme x-bands of the
inlier cloud, with a slightly wider window on the nock side so the
fletchings get averaged in rather than tugging the nock inward. Those
estimates are biased backward, since frame differencing flags both the
previous and current arrow positions as motion. A refinement step
re-finds each end in the background-subtracted current frame alone,
restricted to a narrow band around the fitted axis, where only the
current position contributes.

The tip needs one more correction. The silver field points used in this
dataset have low contrast against the table and reflect lights
differently every frame, so the refined tip almost always lands at the
shaft / field point boundary rather than at the actual front. With the
nock trustworthy, the tip is slid outward along the fitted axis until
the chord matches the calibrated arrow length: a small (~10 px, the
visible field-point length) but systematic correction.

Three sanity checks reject the obviously-bad detections before the frame
is marked valid:

- **Edge buffer.** If either endpoint lands within 25 px of any frame
  edge, the real endpoint is probably off-screen and the chord we
  measured is not the real arrow length.
- **Chord length deviation.** If the chord length is more than 15% off
  the calibrated length, the line fit has locked onto unrelated
  structure.
- **Chord angle deviation.** At 5000 fps the arrow's pose changes by at
  most a fraction of a degree between frames. If the detected chord
  angle is more than 5° off the per-shot calibrated chord angle, the fit
  is mechanically impossible and is rejected.

Frames that fail any of these tests are written out with{" "}
[Figure: Equation]