[frgfm]

Decision: keep closed. A real-camera study found no useful repeats.

This option would reuse the last detections when a camera/pose has exactly the same pixels and model/mask settings. Alerts and uploads still update; the option defaults off.

flowchart LR
  A[Camera picture] --> B{Same pixels and settings?}
  B -- "No: every observed input" --> C[Run YOLO]
  B -- Yes --> D[Reuse previous detections]

Loading

We checked 6,963 original frames from 23 fixed-camera sequences:

Dataset	Frames	Exact repeats between consecutive images
HPWREN FIgLib: outdoor wildfire cameras	1,563	0 / 1,543
CDnet2014: crossing, road and harbour	5,400	0 / 5,397

FIgLib includes 769 pre-fire frames and 302 frames from four named night sequences, covering about 26.5 camera-hours. Its original capture timestamps are usually one minute apart. CDnet captures are 1, 2 and roughly 6 seconds apart; sampling them roughly 30 seconds apart also found zero hits, across every possible starting position.

What was compared: the exact PR fingerprint at 1b7a20d, after the camera API's JPEG95 round trip and the engine's 720p resize, with fixed model/mask settings. Every input was unique within its sequence. The direct-image control agreed. Ignoring the outer image borders, where timestamps appear, also gave 0 / 6,940 repeats; that crop was a diagnostic only. Repeated-copy and changed-pixel controls passed. No model inference is needed to measure this pixel-based condition.

The check previously cost 2.3 ms on x86; Pi 4 cost remains unmeasured. Here it would skip no inference. Repeated reads of a saved snapshot or a frozen camera can still hit, but their production frequency is unknown. These samples do not prove repeats can never happen.

HPWREN data courtesy of HPWREN / UC San Diego. FIgLib selection used seed 449 before measuring. Scripts, hashes, data and this diagram remain outside Git history. This finding concerns the cache in this PR; #427's per-image optimizations remain separate.