A photo of a drink can scored 0.8944 as "AI". I tested 598 more. It was just that photo.

One image is an anecdote

The tempting move after a result like 0.8944 is to go and collect more glossy product photos, find that some of them also score high, and publish "AI detectors flag real product photography". That would have worked. Roughly one real photograph in thirty trips this detector at its shipped threshold, so any bag of thirty images produces a hit, and a page built around the hits is a page built around nothing.

What makes it a question instead of a story is a control: the same detector, the same threshold, the same source, the same gate, on photographs of things that are not glossy. If glossy product close-ups are a weakness, they have to be flagged more than trees and doors are.

Two corpora, one gate

Both arms come from Wikimedia Commons. The glossy arm is beverage cans, beer and soft-drink bottles, glass bottles, bottle caps, canned food, drinking glasses, cutlery and steel cookware — printed labels on cylinders, curved metal, curved glass. The control arm is trees, bicycles, doors, bread, houses, mountains, books, benches, bridges, staircases and windows. The control categories were fixed by name before anything was scored and were never curated by looking at the pictures, because picking through a control for images I judged "too glossy" is exactly the freedom that turns a pre-registered test into a chosen one.

The study is worthless if the "real photographs" are not real photographs, so a file is kept only when Commons' own EXIF carries both a camera Make and a Model, and anything whose categories mention AI, rendering, 3D, screenshots or scans is dropped even when it has EXIF. EXIF is writable and this is not proof; it is the strongest cheap signal available and it removes the renders and mockups that fill these categories. That gate leaves 298 glossy and 300 control camera-originals from 365 distinct camera models, the commonest accounting for 3.0% of the glossy arm and 3.3% of the control — neither arm is one photographer's camera roll.

Scoring is the same score_image() that produced my published numbers and that judges the bounty — one implementation, not a second copy of the rule. Two details that would otherwise silently compare different pipelines: the baseline's "clean" condition is a quality-97 JPEG round-trip rather than the file as downloaded, and the detector's two-crop path only engages at a short side of 384 or more, so both corpora have a 384 floor and the published run is restricted the same way before it is quoted.

What was written down before any score existed

One hypothesis, one operating point — 0.65, the extension's own shipped threshold, not a sweep and not a best case. Two-sided Fisher exact at alpha 0.05 with Wilson intervals. A planned sensitivity analysis re-running the same test inside the short-side band both arms share, because the arms come from different categories and could differ in resolution, and the detector downsamples to 440 before cropping. And four bounds that stop the run instead of producing a finding: flagged cannot exceed scored; the false-positive rate cannot reach the detector's own recall on AI images in the same condition, computed at runtime rather than typed, because a corpus that does that is mislabelled and not a discovery; more than 20% of an arm skipped by the detector's own gates means the arm is not what I think it is; and a control arm under 60 images is reported as underpowered rather than as a null.

The answer is no

598 photographs, 1,794 scorings, one operating point.

Two-sided Fisher exact: p = 0.82. The control arm is 300, so the underpowered bound does not apply — this is a null, not a shrug. The planned sensitivity analysis agrees: inside the shared short-side band of 1232–3456 pixels it is 6/200 against 7/221, p = 1.00. The detector's own reject gates skipped zero images in either arm, so those rates are over the entire corpus.

Glossy printed labels and curved metal are not a systematic false-positive class for this detector. The 0.8944 submission was an individual photograph, which is the more useful answer: the failure was about that image, not about every drink can.

The number I am not going to build this around

The two other degradation conditions were scored too, labelled secondary and not pre-registered, because the pre-registration said they would be.

That 0.046 is the headline this page would have if I were looking for one, so it gets the opposite treatment. It is one of two secondary tests, which puts the corrected threshold at 0.025, and it does not clear it. Inside the resolution band where the arms are matched it falls to 0.15. The glossy arm carries more low-resolution originals than the control — 10th-percentile short side 746 against 1232 — and that, not the subject matter, is the parsimonious explanation. The direction is the same in all three conditions, which is worth one sentence and no more: three degradations of one corpus are three correlated views, not three experiments, and this is precisely the shape a pre-registration exists to stop me from promoting.

For scale rather than for testing: my published run's real photographs at short side ≥ 384 flag at 1/67 = 1.49%, and both Commons arms sit above it at about 3%. That gap is corpus provenance — Commons camera-originals against academic datasets — and it was never a hypothesis here, so it is a thing to notice rather than a thing I measured.

What this null does not say

It does not say tight, frame-filling close-ups are safe. A Commons camera-original of a beer bottle is usually a wide product shot on a table; the bounty submission was a phone held close enough that a printed label and a wet reflection filled the frame. This corpus varies the subject, and framing rides along with it rather than being controlled. The honest scope is that photographs of glossy printed labels and curved metal, as Commons photographs them, are flagged no more often than photographs of trees and doors. Whether extreme macro framing is its own weakness is a different study.

That study now exists, and it is also null: Is it the subject, or the framing? takes these same 598 photographs and, for each one, compares a centre-crop against the whole frame resized to identical pixel dimensions — same image, same pixel count, different amount of scene. At the tightest rung the pre-registered comparison comes back 14/298 against 11/298, p = 0.66.

It also does not say the detector is accurate. Both arms flag around one real photograph in thirty at the shipped threshold. The study compared two halves of that number; it was never designed to move it.

Two things the corpus got wrong, and how they surfaced

The corpus builder crashed once with an HTTP 414 — fifty free-text Commons filenames in one query string overflow the URL limit — and the exception escaped the per-category loop and ended the run at 216 files with four of eleven categories never attempted. The manifest looked exactly like a finished corpus. Nothing in the artifact said "I stopped early". The fix that matters is not the POST request that avoids the 414; it is recording requested-versus-obtained categories inside the output, so completeness is checkable from the artifact after the log is gone.

The second is smaller and stranger. One glossy category holds 38 files against a stated cap of 30, because the cap was lowered from 40 to 30 after that category had already been filled, and a resumable fetch only stops new downloads — it never removes. The corpus quietly stopped matching its own written rule and nothing computed the difference. Reported rather than silently trimmed: recomputing the headline with that category cut back to its first 30 by download time, a score-blind rule, gives 10/290 = 3.45%, p = 0.8184, and none of the eight extra images was flagged. The instance is harmless; the general shape is not. A constant that changes between resumable runs leaves earlier work built under the old value, and the output records no trace of which run wrote which row.

Reproducing it

Every kept file's Commons page, licence, camera, dimensions and SHA-256 is in the corpus manifests, so the corpora rebuild exactly without my redistributing anyone's photographs: glossy (298 files) and control (300). The full output, including per-category and per-resolution-tertile breakdowns, the balance statistics and the cap-conformance check, is in result.json.

The pre-registration is in the source of the script that ran the test, the bounds are code that halts rather than prose that hopes, and that result file carries the numbers that did not support the hypothesis — which, this time, is all of them.