Commit graph

8 commits

Author SHA1 Message Date
kiyo9w
81a2ab10e7 docs(decision): measure G1 against Van on the same stream and catalog
The G1 row compared against a van run whose server had loaded the legacy
stock-lopia catalog, so its ids were template-level (sku_005) and every answer
scored wrong. Re-run with both servers on stock-lopia-clean, 20 s pan 12:

  van    17/27 (63%) coverage   53% precision   7 wrong   6 unenrolled accepts
  local  19-20/27 (70-74%)      77-85%          0 wrong   0 unenrolled accepts

G1 asks the new system to be no worse than Van on coverage; it is better on
both axes, so G1 now reads as passing on the stream rather than unmeasured.
Both recordings are committed under stream-gated/.
2026-09-29 04:28:20 +09:00
kiyo9w
01d9a5e614 docs(decision): re-measure the stream and live rows after the calibration
The stream row was recorded before the accept lines moved. Three fresh 20 s pan
replays through the shipped lane: 70-74% coverage at 77-85% precision, 0 wrong
labels in all three (0-1 before), 8-14 unknown false accepts - the near-unknown
case, which the size gate and catalog completeness own rather than the accept
line.

Live resolution on the shipped evaluator: 56% end-to-end at 97% precision with
1 false accept, so the calibration is not a full-resolution artifact.

The recordings are committed under stream-gated/ so the row is reproducible.
2026-09-29 04:22:46 +09:00
kiyo9w
5eb4bdf6c8 chore(eval): reconcile the distractor sets and refresh the sweep numbers
The Wikimedia collector truncated the whole basename at 60 characters, so 13
files lost their extension and cv2 could not read them by name - the distractor
sets were quietly scoring 13 images fewer than they held. It now truncates the
stem and keeps the extension, and the files on disk are renamed to match.

The search terms also pull in .djvu volumes whose page 1 Commons serves as a
JPEG thumbnail. Twelve book scans were in the sets; they contributed 0 false
accepts, and they are not shelves, so the collector filters them and the
manifests no longer list them.

With all 2650 crops readable the sweep is re-measured end to end: 3.09% at the
old lines, 0.30% at the shipped 4.0/4, image6 44 shown / 42 correct / 95.5%.
The accept sweep table and the verdict's far-unknown sentence now carry those
numbers instead of the pre-calibration ones.

Also: the fetched images are gitignored (manifests and results are not), the
l10/l11 shelf-tag crops that back the catalog corrections are committed, and a
stale pre-gate eval.json and a duplicate of eval/labels/image6.json are gone.
2026-09-29 04:17:54 +09:00
kiyo9w
4bdad66bbe docs(decision): record the far-unknown calibration and the gate status
The far-unknown claim in the verdict said 0.2-0.7% on 602 crops. That was the
audit's variant matcher on the add/ photos; the shipped lane at the shipped
lines was 3.61% on the Wikimedia sets. Both are now stated, with the sweep that
chose 4.0/4 and the live-endpoint result: 44 named, 42 correct, 95.5% precision
against 53/48/90.6% before.

Gate status is recorded per gate rather than as a blanket claim: G2 and G3's
far half pass offline, G8 passes, and G1/G4/G5/G6/G7 are not yet measured on
held-out data because Tier 2 does not exist.

The Wikimedia manifests and results are committed; the 59 MB of images are not,
because collect_shelf_images.py fetches them from the source URLs the manifests
record.
2026-09-29 04:11:00 +09:00
kiyo9w
d13ce94123 test(server): final smoke with every catalog correction live
/v1/recognize: 111 detections, 53 named in 2.38 s, no view-suffixed ids, no
missing product info. l06 now names all 4 of its facings - it was 1/4 at live
resolution before the current package was enrolled, which is the F-12 fix
visible in the product.

/v1/stream, 20 s pan: 82 tracks labelled, 0 label changes, 0 unexplained. The
label-memory fixes hold under a pan.
2026-09-29 03:41:05 +09:00
kiyo9w
8754738dc1 docs(decision): refresh every number the corrected labels moved
Five blocks still printed pre-correction figures. Each was re-run through the
evaluator and replaced with what it actually outputs now:

- The lane comparison: local 75% at 91% against Van 64% at 38% (full), and
  59% at 93% against 66% at 39% (live). At live resolution Van now answers more
  facings correctly and is wrong on 67 of them to the local lane's 3 - stated
  plainly rather than left as a win on both axes.
- The accept sweep: 75/67/67/62% end-to-end at 91/91/93/95% precision, with the
  evaluator's own column definitions spelled out, since my first re-derivation
  used the wrong denominator.
- The G1 stream claim: four pan replays give 63-70% coverage at 76-84%
  precision, not 75% at 100%.
- The upscale paragraph: the guard is intact, but sku_l09.jpg is now a
  1000x1000 packshot, so the current run no longer exercises it.
- catalog_hash and the pyramid floor: the hash covers view bytes, not just
  names, and every view is now above the 800 px floor.

Also refreshes the server smoke against the renamed catalog: 53 named in 2.58 s,
no view-suffixed ids, no missing product info. l12 is not among them - it has
no enrolled view, which is the documented gap.
2026-09-29 03:18:30 +09:00
kiyo9w
74e9afed7d test(server): record the real-endpoint smoke after the size gate
/v1/recognize on add/image6.jpg against stock-lopia-clean: 111 detections,
53 named, every one carrying product_name and price, no view-suffixed ids.
sku_l10 answers 9 facings, which it could not do before it was enrolled.

The live WebSocket path was exercised too: 217 frames, 77 tracks labelled,
0 unexplained label changes, l09 and l10 in the final summary.
2026-09-29 03:06:28 +09:00
68061635d9 Enroll from a repo data dir; read packshots in every orientation
Two enrollment defects, both found by trying to enroll real packshots.

`rebuild_catalog.py` crashed on every successful run: the report referenced
`small` but the call to `below_pyramid_floor` was missing, so the pyramid-floor
check the enrollment protocol asks for never ran and the tool died with a
NameError after writing the catalog.

The name/OCR check read one orientation. A packshot whose identifying text runs
vertically - the やまや めんたいマヨネーズ image reads 明太手屋さんが only when
rotated - was refused as a mismatch, which is the worst failure this check has:
it rejects good data while claiming to validate it. `best_orientation_text`
tries all four right-angle rotations and picks the one that explains the most of
the catalog name, not the one that reads the most characters, because the
upright pass returns stray kana that concatenate longer than the real read.

The regression test goes through `audit`, not the helper: the bug was that
`audit` called a single-orientation read, and a helper unit test would have
passed on the broken code. Verified to fail before the fix and pass after.

Data now lives in the repo, not /tmp:

  data/packshots/source/   packshots as downloaded, with ATTRIBUTION.json
  data/evaluations/        per-session run artifacts, so a number in
                           DECISION.md traces to the run that produced it

sku_l09 is re-sourced at 1000x1000 from Matsukiyo's Rakuten image, replacing
the 305px view that the README documents as the reason l09 wins facings it
should not.
2026-09-29 02:33:47 +09:00