The comments promised enough pixels. The detector squeezed 4K down to 320x320

The monitoring app has two layers of object detection. The recorder runs a detector on a low-resolution substream (640x360), because it has to do that several times a second on several cameras. That substream is coarse enough to get some things wrong.

So the app has a second step. When an event comes in, a sidecar service runs the event’s still or clip through a detector again to check. If the sidecar finds no person or vehicle anywhere in the clip, it closes the event as a false detection.

The code explained why this worked, and the explanation was wrong.

What the comments claimed

The detection endpoint’s docstring cited a real measurement. On one morning, 16 events were labelled person and none of them were people. When the same moments went through the sidecar, the correct label came back at 0.87 and no person above 0.35. The comment concluded that this was not a better model, just the same model with more pixels to work with.

The first part held up. The second part did not. The model file has a fixed 320x320 input. The detection endpoint and the routine that ranks frames in a clip both took the entire 3840x2160 frame and resized it to 320x320. The commit message that fixed it says so directly: every detection in the sidecar squeezed the whole 4K frame into the model’s fixed 320x320 input, which is coarser than the recorder’s own substream, while the comments claimed the model had enough pixels.

So “full resolution” only meant the input started out as 4K. What the model actually saw was coarser than what the recorder’s own detector works with. The new tiling module describes the effect: a distant person ends up about ten pixels tall. Subjects close to the camera still showed up fine. That is why the comment’s evidence looked convincing. Distant subjects disappeared.

How it was found

On 22 August 2026 Henning said he was not happy with the detection logic. We went through it the way an operator would, using real database rows and real images. One event had been closed as “false detection: no person or vehicle in any part of the clip”, but the event’s snapshot showed that the closure was wrong. The task log says this was checked by eye.

The task log also says this was the same kind of error as an earlier finding, where a model exam had measured at a different resolution than the one used in production.

On attribution: Henning writes no code himself, so both the original comment and the 320x320 path were Claude’s. The comment’s resolution claim was wrong, and it stayed in the code until the review on 22 August.

The measurement

The fix was chosen by measurement. The material sets that against assuming it would work. The test set was the day’s own wrongly closed clips, a set of reference clips, and empty images with nothing to find. All of it was measured on 22 August.

The approach we settled on runs the detector on the full frame first, then on four quadrants. Each quadrant covers 56.25% of the frame on each axis, so neighbouring quadrants overlap by 12.5%. The overlap catches subjects standing near the middle of the frame, where a plain four-way split would cut them in half. This is not real 4K: the model’s input is still 320x320. The module puts the effective width at about 569 pixels per axis. Boxes found in a tile are mapped back to coordinates in the full frame, and duplicates are removed.

Results from the commit and the module docstring:

• Wrongly closed clips: the commit message and the task log say the subject was found in 5 of the 6 clips the old path had closed. The task log adds that the sixth clip really is empty. The docstring in the new module gives a slightly different count: 4 of 6 clips that the full frame alone had judged empty. We report both because the material contains both.
• Cost: a few marginal hits at 0.35 on a static object in the empty images. The commit message counts one and the module docstring counts two. These now go to a judgment step instead of closing the event, so they cost a second look, not a wrong decision.

What changed besides tiling

Tiling is the main fix, but one more change matters as much. The old flow closed an event whenever the detector found zero frames with a subject in the clip. That rule is how a weak detector turned straight into wrong closures. Now an empty result from the detector sends the still image to a separate false-detection check instead of closing the event.

The tile geometry lives in its own small module with no model dependency, so it can be tested on its own. The tests check exact numbers, not shapes. The test file explains why: a box mapped to the wrong place does not throw an error. It just points at the wrong patch of the image, and training data gets labelled with that wrong patch. Among other things, the six new tests check that:

• the full frame comes first
• the quadrants overlap
• the quadrants together cover the whole frame at several sizes
• boxes from a tile map back to the right region

The task log records 30 Python tests passing after the change. The fixed detector was smoke-tested against the day’s failure image as part of the rollout.

The docstring that used to credit the result to more pixels now says the opposite. It never was full resolution. The input is 320x320. Close subjects worked and distant ones were lost.

The rule

The detector now always runs on the full frame plus four overlapping quadrants, including when it ranks frames inside a clip. An empty result no longer closes an event without a second check.

The broader rule: a claim in a comment about what a model can see is a hypothesis until it has been measured. Claims like full resolution or enough pixels are measurable. Until that check is done, a comment like this should be treated as unverified, not as documentation.