This dataset is released for research use. Access is reviewed and granted manually by the maintainers. Please state your name, affiliation, and intended use.

181-mcq

Region-MCQ (Set-of-Mark) for anomaly localization — 1,943 items, deterministic (no LLM), one per anomalous DAGM record of 9 classes. 2×2 grid A–D; exactly one panel's red region contains the anomaly. Negatives are location-only (the true mask translated to positions drawn from the SAME class's gold-centroid pool, mirror fallbacks) — under a coarse containing-region GT, extent-based negatives (dilate/erode) are an annotation convention rather than a visual fact, so they were removed after adversarial review. Placing negatives at class-typical positions makes them positionally indistinguishable from golds by construction: a geometry-only attacker scores 0.225 pooled (below 25% chance) with worst class 0.300 — machine-gated in verify_181.py. Gold letters A 468 / B 480 / C 499 / D 496; every independent choice from its own salted hash; template×letter at chance. Both gold and negatives must render ≥30 visible px outside the letter tag. Raw base images. Exclusions (counted, confidence-over-coverage): Class6 entirely (150 — huge border-flush masks make position-fair negatives impossible; a 51% per-class position exploit was measured and eliminated by exclusion) + 7 Class8 golds hidden under the letter tag. Class6/Class8 anomalies remain fully covered by the companion region/grounding/L1 sets.

Weak-GT disclosure. DAGM's official labels are deliberately COARSE ellipses ("roughly indicating" the defect) — every localization here is a containing region, not a tight extent (metadata.coarse_gt: true). Grade localization by containment/center-hit, never tight IoU.

Query diversity (2026-07-11). The query field is drawn from a pool of 25 surface variants for this task (paraphrases that preserve the task and answer-format exactly; the answer-format directive is held verbatim), each selected by an independent per-record hash. This replaces the earlier 4-template design to prevent instruction-format overfitting; answers, images, ids, and all provenance are unchanged. A machine gate in verify_*.py checks that no template correlates with the gold (binomial z < 4.5).

Roles

Roles: this is an answer-only tier — there is no reasoning column; annot is both the machine-parseable gold AND the direct-answer SFT target ('SFT-ready' here means direct imitation of annot in the query-specified format); it is also the exact-match/IoU reward key for RLVR.

Overlap / de-duplication (§8)

270 of these images (all anomalous, DAGM Classes covered by DefectSpectrum) also appear byte-identical in the D15 family (D15-annotated / D15-mcq / D15-region / D15-grounding) with FINE masks and defect-type labels. Reconstruct the exact overlap via metadata.image_sha256. Both official DAGM splits are processed identically here (project policy): metadata.split preserves the original Train/Test membership — carve your own held-out set downstream and keep it out of training.

Provenance

Built from AI4Manufacturing/181 by annotate/181/build_181_derived.py (forge_model), verified by verify_181.py. Exact-match / RLVR-ready. Companion sets: 181-annotated, 181-region, 181-grounding.

Geometry (`metadata.geometry`)

Every record carries a geometry block inside the existing metadata JSON string, so that its gold can be re-derived at any render size. No schema column changed; existing loaders are unaffected.

⚠ This repo's images are COMPOSED (a multi-panel montage), so the image in a record is not the image the coordinates belong to. The block says so explicitly:

image_wh — dims of the montage actually stored in the record
source_wh — dims of the source image the boxes are measured in
coords_frame: "source_image" — bbox_xywh are SOURCE pixels, not montage pixels
scale: null — a composed image has no single scale to the source

1,943 of 1,943 records are composed. The boxes are the regions the question was built from; they do not locate anything in the montage, and rescaling them by the montage size would be wrong.

"geometry": {
  "image_wh":  [W, H],        // dims of the image in THIS record
  "source_wh": [W, H],        // dims of the original source image
  "scale": 1.0,               // image_wh / source_wh; < 1.0 would disclose a publish-time downscale
  "n_instances": 2,
  "instances": [
    { "instance_id": 1, "bbox_xywh": [x, y, w, h], "min_side_px": 65, "class": null }
  ],
  "n_dropped_subminimum": 0,  // components removed by the filters below
  "union_box_fallback": false,// true => boxes are per-class unions, NOT real instances
  "conventions": { ... }      // see table
}

instances is present even when empty. [] means the record genuinely has no defects; an absent block would mean geometry could not be recovered. Those are different states and are never conflated.

Conventions used to derive it

There is no universal definition of "one defect instance" — it depends on the mask the source shipped. This repo's is stated, not implied:

field	value
`algorithm`	`containing_box`
`binarisation`	`gt:0`
`connectivity`	`4`
`merge`	`none`
`min_area_px`	`0`
`max_instances`	`1`
`artifact`	`coarse`
`fill_floor`	`None`
`legibility_floor_px`	`None`
`min_side_floor_px`	`24`
`spec_sha`	`ccc479c9706b8f85`

Provenance and verification


records	1,943
carrying a geometry block	1,943 / 1,943
instances per record	`1`: 1,943
total instances	1,943
image dimensions	920×920 (1,943)
`scale` values present	[None]

Derived from the AI4Manufacturing/181 masks and verified against this repo's own published answers before it was written — a recomputation that disagreed with the shipped gold would have aborted the update rather than overwritten it.

⚠ The 16px floor applies at the RENDER, not at native

min_side_px is in native pixels. The model does not see native: Qwen2-VL caps by megapixels AND snaps each dimension to a multiple of 28. So min_side_px >= 16 is the floor tested in the wrong frame. Measured on this repo:


native → rendered (qwen2_vl @ 2.36MP)	920×920 → 924×924
shipped boxes	1,943
legible at that render (>=16px there)	1,943 (100.0%)

⚠ An earlier version of this section reported the inverse — boxes clearing 16px at native and failing at the render — and that number was misleading. It is frame-relative: publishing at a larger native size lets more boxes clear 16 in the published frame, so more can "fail", which penalises exactly the choice that helps. Measured on 179: publishing native (3024) means a box needs >=32px native to be legible at the render and 86.7% qualify; the previous 1024 publish needed >=47px native and only 69.5% qualified. The native republish improved rendered legibility by 17 points while the old metric scored it as 12.5% "broken". The figure above is the comparable one.

Nothing in the data is frame-dependent — geometry is native and complete. Use forge_model/common/adapt_engine.py, which applies the floor at whatever size the consumer renders.

Using it

Coordinates only stay correct if they are rescaled with the image. A patch-based VLM does not render at native size: Qwen2-VL's processor snaps both dimensions to a multiple of 28, so this repo's 920×920 is rendered 924×924 and native-pixel boxes are then wrong by a few pixels. forge_model/common/adapt_engine.py regenerates coordinates for a target render size, re-derives counts, and drops records whose gold no longer holds there.

Query text — pooled paraphrases (v2)

Every record's query is drawn from common/vision_query_pools.json[181/mcq], a pool of 46 gate-verified paraphrases of the shipped wording, assigned by the rung builder's own hash of the derived record id and recorded as metadata.query_template (46 templates in use, top share 3.1%).

v1 drew from the first 28 of these templates with the same hash rule; templates [15] were corrected in wording (81 records keep their v1 text). Query pool only: topped up 28 -> 46 and one template's wording corrected (it said the views were 'annotated with' a red zone -- the model sees an outline, not an annotation); annot and reasoning (null) are untouched.

Template ↔ gold independence on this build: 1,943 records, 46 templates, worst template p = 0.00338, alpha 2.2e-04, 0 flagged → PASS.

Frame-size floor (common/lazy_floors.py, the standing (width, height)-only row): vacuous by construction — all 1,943 images share one frame size.

Answers, images, masks, split and every other field are byte-identical to v1: this revision was issued from the published parquet itself (tools/requery_published.py), not rebuilt from source, and the pixel-identity guard ran on the embedded images (§8 below).

Image identity — measured at this republish

Two identities, and they answer different questions. metadata.image_sha256 hashes the file bytes: it finds byte-identical copies and is blind to a re-encode. metadata.pixel_sha256 hashes the decoded image (mode | size | pixels): it finds the same photograph saved twice. Only the second one settles whether an image is duplicated.

Measured at build time, not asserted afterwards — a violation aborts the build and names the offending records:


images checked	1,943
distinct by decoded pixels	1,943
images carrying more than one record	0
images on both sides of the split	0

Downloads last month: 70

Total file size:

941 MB

You need to agree to share your contact information to access this dataset