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

Roles

Roles: canon repo — annot is the source label, kept machine-parseable as the gold for verification and reward parsing; there is no reasoning column and this repo is not itself a training view. Derived repos (-annotated, -grounding, -region, -mcq) each state their own regime on their own card. Geometry for every record lives in metadata.geometry (below).

187

Metal-parts binary anomaly detection & localization. Category B, task T-B1, in the unified Smart-Manufacturing SFT schema.

The repository name is an internal task code. See Provenance below for the underlying dataset.

Records

1,346 records (test=458 · train=888). Pixel masks are embedded as a mask image column.

Unified SFT schema

field	type	meaning
`query`	str	the question / instruction (model input)
`image`	Image	the input image (bytes embedded); for multi-image rows, a preview of the first view
`images`	list[Image]	(multi-image rows) all input views / modalities for the row, bytes embedded
`annot`	str	the answer — for this dataset: the plain-text image-level label `good` or `anomalous` (MPDD's benchmark task is binary AD). The source per-category defect-type sub-label is kept in `metadata.defect_type`; the `mask` column is localization ground truth for a separate, deferred task — see Task, mask & split below
`reasoning`	null	no native CoT in these datasets
`cate`	"B"	SFT category
`task`	"T-xx"	unified task id
`metadata`	str (JSON)	split, provenance, `image_path`, `image_sha256` (dedup key)
`mask`	Image \| null	(T-B1/T-B2 only) the pixel ground-truth mask, bytes embedded
`masks`	list[Image]	(multi-image T-B1 / D21) per-view masks aligned with `images` (None where a view has no defect), or multi-region masks

Task, mask & split

What this is. MPDD (Jezek et al., ICUMT 2021) — Metal Parts Defect Detection: MVTec-AD-style unsupervised anomaly detection & localization over 6 metal-part categories (bracket_black / bracket_brown / bracket_white, connector, metal_plate, tubes), trained on defect-free images only. The benchmark task is binary (normal vs anomaly) at the image level plus pixel-level localization.

Query & answer (this repo's SFT task). query is our own instruction template (the dataset ships no natural-language question). It names the metal part and asks only whether it is good or anomalous; annot is the plain-text answer good or anomalous. The query does not ask for a pixel mask.

Defect types (secondary, in metadata — not the answer). MPDD organizes 5 of its 6 categories' test anomalies into named defect folders (e.g. hole, scratches, major_rust, parts_mismatch); the tubes category is not sub-typed (a single anomalous folder). These are the authors' organization, not the benchmark target, so the source label is kept in metadata.defect_type (null for normal, the folder name for anomalies) rather than in annot.

Mask (deferred localization GT). Each anomalous image ships a single binary ground-truth mask (mask column; 1 = defect, 0 = background); normal images have mask=null. A text-output model cannot emit a pixel mask, so localization is deferred (mask kept as GT).

Split. train = normal images only (888); test = normal + anomalous (176 normal + 282 anomalous = 458). No separate validation split. Standard unsupervised one-class protocol.

Query text — pooled paraphrases (v2)

Every record's query is drawn from common/vision_query_pools.json[F3/verdict_word], a pool of 40 gate-verified paraphrases of the shipped wording (this repository draws from the 8-template family of the ask it shipped; the other families describe inputs of a different shape), assigned by a stable hash of the source image path and recorded as metadata.query_template (8 templates in use, top share 13.7%).

The opening role sentence is drawn separately (metadata.query_role, a 10-way hand-written pool _role/sentence; index 0 is this repository's own sentence, index 1 is none); the subject sentence is this repository's own, verbatim, on every record. Role and ask are hashed independently.

⚠ Approved deviation — no answer-format directive in v1. v1's query gave no answer-format directive; from v2 every query states it (Answer with a single word: good or anomalous.). The gold was always the single word.

Template ↔ gold independence on this build: 1,346 records, 8 templates, worst template p = 0.14, alpha 1.3e-03, 0 flagged; 10 roles, worst role p = 0.132, 0 flagged → PASS.

Frame-size floor (common/lazy_floors.py, the standing (width, height)-only row): vacuous by construction — all 1,346 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).

Provenance

Underlying dataset: MPDD. Upstream license: CC BY-NC-SA 4.0 (this card is license: other; respect the upstream terms). Converted read-only from the raw source into the unified schema; conversion code under 187/ (with publish/push_to_hf.py) in AI4Manufacturing/forge_model.

Overlap / de-duplication (§8)

None notable.

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,346
distinct by decoded pixels	1,346
images carrying more than one record	0
images on both sides of the split	0

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.

Coordinates are native pixels of the image in that record (coords_frame: "record_image"). scale is 1.0 throughout — this repo publishes at source resolution, nothing was downscaled at publish time.

"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`	`dilate_cc`
`binarisation`	`gt:0`
`connectivity`	`4`
`merge`	`mask_dilate:1pct`
`min_area_px`	`15`
`max_instances`	`None`
`artifact`	`fine`
`fill_floor`	`None`
`legibility_floor_px`	`None`
`min_side_floor_px`	`None`
`spec_sha`	`dc1010954934ae75`

Provenance and verification


records	1,346
carrying a geometry block	1,346 / 1,346
instances per record	`0`: 1,064, `1`: 190, `2`: 56, `3`: 24, `4`: 8, `5+`: 4
total instances	426
image dimensions	1024×1024 (1,346)
`scale` values present	[1.0]

Computed from this repo's own 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)	1024×1024 → 1036×1036
shipped boxes	426
legible at that render (>=16px there)	386 (90.6%)

⚠ 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 1024×1024 is rendered 1036×1036 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.

Downloads last month: 71

Total file size:

1.77 GB

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