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).

207

3C-electronics production-line anomaly detection over 8 manufactured parts (47 defect types; binary masks). 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

27,039 records (test=16546 · train=10493). 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: plain-text `{label, defect_type}` — `{good, null}` or `{anomalous, <defect>}`, where `<defect>` is the specific defect name from THAT category's own closed set (enumerated in the query), following D20/D22. `Multiple-defects` is a valid gold answer and is a meta-label, not a 48th defect type — see Task, mask & split below. The binary `mask` column is deferred localization GT
`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. 3CAD (Yang, Xing et al., "3CAD: A Large-Scale Real-World 3C Product Dataset for Unsupervised Anomaly Detection", AAAI 2025) — 27,039 images captured on real 3C (computer / communication / consumer- electronics) production lines across 8 manufactured parts: Aluminum_Camera_Cover, Aluminum_Ipad, Aluminum_Middle_Frame, Aluminum_New_Ipad, Aluminum_New_Middle_Frame, Aluminum_Pc, Copper_Stator, Iron_Stator. Standard unsupervised-AD layout: train = 10,493 good only; test = 16,546 (5,084 good + 11,462 defective). Image sizes vary by category (288x288 to 1024x1024) and are published at source resolution. All counts reproduce the paper's Table 1 exactly.

Task & answer. Anomaly detection with defect naming. query is our own template (the source ships no natural-language question): it names the part and asks whether it is good or anomalous and, if anomalous, for the defect type from that category's own closed set, which is enumerated in the query. annot is plain text {good, null} / {anomalous, <defect>}. The query does not ask for a mask.

⚠ Multiple-defects is a meta-label, not a defect type. Five of the eight categories carry a Multiple-defects folder for images showing several defect types at once, and it is a valid gold answer here because it is the label the authors assigned. It is not one of the paper's 47 types — confirmed by construction: the 8 categories hold 52 defect folders in total, 5 of them Multiple-defects, and 52 - 5 = 47. Its mask is the union of the regions of the types present, and the individual types are not recoverable from the release. Anyone training a pure defect-type classifier should keep it as its own class or drop those images; treating it as a 48th type is wrong.

Mask (deferred GT). Every one of the 11,462 defective images has a ground-truth mask (verified: zero missing). Masks are genuinely binary ({0, 255}) and pixel-aligned with the image. Good images carry mask = null.

⚠ Label-quality defect, upstream: 79 images carry contradictory labels. 79 image files appear byte-identically in both Copper_Stator and Iron_Stator while being labelled differently — 35 as {anomalous, wire damage} vs {anomalous, inner warping}, 30 as {good, null} vs {anomalous, inner warping}, and 14 as {anomalous, wire damage} vs {good, null}. These are ordinary images, not blanks or placeholders, so this is a folder-management error in the source, not a rendering artefact. 158 of 27,039 rows (0.58%) are affected. We publish the labels exactly as released rather than silently choosing a winner; use metadata.image_sha256 to find and drop them. 49 images appear in both the train and test splits — 44 of them are these same Copper_Stator / Iron_Stator pairs (one copy on each side), the other 5 are Aluminum_Camera_Cover / Aluminum_New_Ipad images shipped twice with agreeing labels (v2 correction, measured on the decoded pixels: the v1 text called the 49 unrelated to the label defect) — dedup by metadata.pixel_sha256 before evaluating.

Lazy-baseline floors (report accuracy against these, not against chance).

test question	n	majority answer	floor
binary good vs anomalous	16,546	`anomalous` (11,462)	69.3%
full `{label, defect_type}` (26 distinct answers)	16,546	`{good, null}` (5,084)	30.7%

The binary framing is close to saturated by guessing; the defect-naming framing is the informative one.

Provenance. The authors ship two releases: 3CAD (English defect names) and 3CAD-Pinyin (identical data, Pinyin folder names). This repo converts the English release.

Query text — pooled paraphrases (v2)

Every record's query is drawn from common/vision_query_pools.json[F2a/label_type], a pool of 39 gate-verified paraphrases of the shipped wording, assigned by a stable hash of the source image path and recorded as metadata.query_template (39 templates in use, top share 2.8%).

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.

Template 1 is v1's wording byte for byte (64 records keep it); the pass asserted that on every record before rewriting anything.

Template ↔ gold independence on this build: 27,039 records, 39 templates, worst template p = 0.0834, alpha 2.6e-04, 0 flagged; 10 roles, worst role p = 0.02, 0 flagged → PASS.

Frame-size floor (common/lazy_floors.py, the standing (width, height)-only row): balanced accuracy 0.550 vs 0.500 chance (plain 0.626 vs 0.693 majority; permutation p = 0.005, 200 shuffles), 234 distinct frame sizes — a shortcut of +5.0 pp balanced, report against it (5-fold within the test split because the training split holds a single class (all 10,493 records), so a train→test probe can only predict that class; not comparable to train→test rows on other cards).

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: 3CAD. Upstream license: not stated by the authors (public Google Drive release; research use — verify before redistribution) (this card is license: other; respect the upstream terms). Converted read-only from the raw source into the unified schema; conversion code under 207/ (with publish/push_to_hf.py) in AI4Manufacturing/forge_model.

Overlap / de-duplication (§8)

No overlap with any other dataset in this corpus. ⚠ 79 images appear in both Copper_Stator and Iron_Stator with contradictory labels upstream — see the label-quality note below.

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	27,039
distinct by decoded pixels	26,909
images carrying more than one record	120
images on both sides of the split	49

⚠ This dataset declares a exempt image-identity policy, so the row above is expected to be non-zero: UPSTREAM (3CAD release) — the same defect the geometry wave declared as geometry.duplicate_image and the label-quality note above describes, re-measured here on the decoded pixels: 120 images appear in more than one record (250 records; every copy byte-identical). 109 groups are a Copper_Stator / Iron_Stator pair — the same photograph released under both object names (218 records) — of which 79 carry contradictory annotations (44 good vs anomalous, 35 anomalous with different defect types) and 44 sit on both sides of the split; the other 11 groups are Aluminum_Camera_Cover (10) and Aluminum_New_Ipad (1) images shipped twice with agreeing labels, 5 of them across the split — 49 cross-split groups in all. Every record is kept exactly as published; any carving must drop or unify these groups (metadata.pixel_sha256). Recorded for the next data revision Images are still forbidden from crossing the split — and that rule too is exempted here, which is why the last row may be non-zero.

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`	`41752cc163907e90`

Provenance and verification


records	27,039
carrying a geometry block	27,039 / 27,039
instances per record	`0`: 15,577, `1`: 7,766, `2`: 2,533, `3`: 659, `4`: 266, `5+`: 238
total instances	17,336
image dimensions	1024×1024 (16,514), 800×1024 (2,338), 1024×910 (542)
`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)	205×1024 → 196×1036, 212×1024 → 224×1036, 223×1024 → 224×1036
shipped boxes	17,336
legible at that render (>=16px there)	13,239 (76.4%)

⚠ 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 205×1024 is rendered 196×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: 79

Total file size:

1.98 GB

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