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

This repository is publicly accessible, but you have to accept the conditions to access its files and content.

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

Log in or Sign Up to review the conditions and access this dataset content.

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

212

Texture-surface anomaly detection over 39 cloth / wafer / metal products (binary; anonymous defect class). 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

43,555 records (test=6904 · train=36651). Pixel masks are embedded as a mask image column.

(2026-09-25, stated) Re-split: 7,678 evaluation records moved to train. They are the evaluation anomalies the re-split moves (with any good in the same identity group), one record per image; they now live in the new train shards data/train-00010-of-00013.parquet, data/train-00011-of-00013.parquet, data/train-00012-of-00013.parquet. On each, metadata.split is now train and metadata.eval_lock was re-computed by common/overlap.py (locked: false; manifest revision fe6e286912b0 unchanged). Every other cell of every column, and every other record, is byte-identical to the parent revision 0593c0238427. Splits: test 14,582 → 6,904; train 28,973 → 36,651. Basis: the user's ruling resplit: r 70, floor 100, N max (typed 2026-09-25 08:29 UTC), executed from the plan 212.json.gz (payload sha16 818a6df784e72498) written by tools/resplit_analyze.py; the method and every figure are in reports/ad_good_only_splits/resplit_tool_2026-09-25/. Statements elsewhere on this card that describe the split (counts, which images each split holds, test-split baselines) describe the layout before this revision. (measured on the live records, 2026-09-25) 2026-09-25: section Records rewritten in this revision; the previous text is superseded (1 of 1 lines replaced).

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. Every category ships a single defect folder named 0 — an anonymous class id, not a defect name — so, as with DAGM (181) and Severstal (193), the id is not asked of the model; it is preserved in metadata.anonymous_defect_class. The binary mask column is deferred localization GT (8 defective images have none — see 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. Texture-AD (Lei, Wang, Chen, Cao, Zou, "Texture-AD: An Anomaly Detection Dataset and Benchmark for Real Algorithm Development", arXiv:2409.06367) — 43,555 images of manufactured texture surfaces in three material families: cloth (15 products), wafer (14) and metal (10), 39 categories in all. Each image is a 512x512 patch cropped from a larger captured surface. Standard unsupervised-AD layout: train = 28,973 good only; test = 7,653 good + 6,929 defective.

Task & answer. Binary image-level anomaly detection. query is our own template (the source ships no natural-language question): it names the material and asks whether the surface is good or anomalous. Why binary: each category ships exactly one defect folder, named 0. That is an anonymous class id carrying no semantics, not a defect name — so no defect-type task is derivable from this release and none is invented here. The id is kept in metadata.anonymous_defect_class. This is the same rule we apply to DAGM (181) and Severstal (193).

⚠ Patches share source images — and for two of the three families the official split does not respect that. Filenames encode the crop (<source>_sx<X>_sy<Y>_ps512.png), so many patches descend from one captured surface. Share of source images having patches in both train and test, measured over the release:

family source images in both splits
cloth 322 0.0% — split respects the source
wafer 532 89.3%
metal 891 89.1%

On wafer and metal a model can memorise a surface from its training patches and then be scored on different patches of that same surface, which inflates any number computed on the official split. We publish the official splits unchanged and expose metadata.source_image (plus metadata.grouped_split_required) so a consumer can regroup: evaluate wafer and metal with a source-wise (grouped) split, not the shipped one. Cloth needs no such care.

Mask (deferred GT). Binary masks are embedded in the mask column for defective images. 8 defective cloth images have no mask upstream; they are kept because the image-level label is still valid, with mask = null — locate them by annot == "anomalous" and mask is null and drop them if you are training localization.

Lazy-baseline floor. The published test split is nearly balanced — 7,653 good vs 6,929 anomalous — so the majority-class floor is 52.5%. Report binary accuracy against that, and against a source-wise split for wafer and metal.

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 11-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 (11 templates in use, top share 9.4%).

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: 43,555 records, 11 templates, worst template p = 0.125, alpha 9.1e-04, 0 flagged; 10 roles, worst role p = 0.212, 0 flagged → PASS.

Frame-size floor (common/lazy_floors.py, the standing (width, height)-only row): vacuous by construction — all 43,555 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_stream.py), not rebuilt from source, and the pixel-identity guard ran on the embedded images (§8 below).

Provenance

Underlying dataset: Texture-AD. Upstream license: Apache-2.0 (HuggingFace texture-ad/Texture-AD-Benchmark) (this card is license: other; respect the upstream terms). Converted read-only from the raw source into the unified schema; conversion code under 212/ (with publish/push_to_hf.py) in AI4Manufacturing/forge_model.

Overlap / de-duplication (§8)

No overlap with any other dataset in this corpus. ⚠ Patches share source images, and for the wafer and metal families ~89% of source images have patches in both train and test — see the split 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 43,555
distinct by decoded pixels 43,555
images carrying more than one record 0
images on both sides of the split 0

Cross-family evaluation lock — metadata.eval_lock (stamped 2026-09-20; manifest revision fe6e286912b0, generated 2026-09-08). Every record of this repository, locked or not, carries metadata.eval_lock, computed by forge_model/common/overlap.py::Overlap.stamp_for against common/overlap_manifest.json at that revision — so within this repository the absence of the key cannot occur. Shape: {"locked": bool, "against": [{"repo": …, "split": …}, …], "own_split": …, "manifest_revision": …, "manifest_generated": …}. locked is true when the image is evaluation material anywhere in the corpus; against names every repository and split in which it is (sorted; [] when not locked; it includes the record's own family where that is so); own_split marks a record locked by its own split. The per-record field is the authority — the count here is quoted once, at this revision, and a later manifest may change it: 14,582 of 43,555 records (14,582 distinct images) are locked — by column: 0 by the cross-family manifest, 14,582 by their own split, 0 both ways and counted once; counterparts (records per counterpart; a record can appear under several): none — every lock here is by the record's own split; 14,582 locked by their own split: test. In words: 14,582 of the 43,555 records in this repository are evaluation material by their own metadata.split (test: 14,582) and sit inside the HF split named test / train — under the uniform-split convention the HF split name is a container name, and metadata.split together with metadata.eval_lock carries the truth; a train pool must exclude them. A stamp whose manifest_revision differs from the current manifest is stale, not wrong — recompute it (Overlap.stamp_is_current); a record with no stamp has not been checked against the corpus as it now is. Overlap.partition / assert_train_pool_clean read the field: a train pool built from this repository must exclude every locked record.

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 97d4e9935d82349d

Provenance and verification

records 43,555
carrying a geometry block 43,555 / 43,555
instances per record 0: 36,634, 1: 4,259, 2: 1,712, 3: 557, 4: 212, 5+: 181
total instances 11,327
image dimensions 512×512 (43,555)
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) 512×512 → 504×504
shipped boxes 11,327
legible at that render (>=16px there) 10,481 (92.5%)

⚠ 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 512×512 is rendered 504×504 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
191

Paper for AI4Manufacturing/212