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

179-region

Region-conditioned defect typing on aero-engine blades — 3634 items, derived deterministically from the binary segmentation masks of AI4Manufacturing/179. Exact-match gradable (closed type list + no defect) → SFT and RLVR-ready.

Task

"An operator points at a region — what defect, if any, is there?" One item per defect instance (2048 positives: breakdown 953, groove 466, fracture 389, ablation 240) plus 1586 clean-region negatives teaching rejection (every good record + ~half of defective records). The region is conveyed in one of two modes (metadata.region_mode; overlay 1806 / bbox_text 1828):

overlay — a red rectangular ring drawn on the image around the region.
bbox_text — the raw image plus the region as a pixel box [x, y, w, h] in the query text.

Clean boxes sample size AND position from the emitted positive population, so box geometry separates nothing. Instance boxes containing another instance's pixels are skipped in bbox-text mode. Gold = the type name exactly as in the query's closed list, or no defect. Verified: zero defect pixels inside any clean box.

field	type	meaning
`query`	str	16 variants per mode; closed class list
`image`	Image	blade photo, or blade with ONE red rectangular ring (overlay mode)
`annot`	str	`ablation` / `breakdown` / `fracture` / `groove` / `no defect`
`reasoning`	null	none — deterministic derivation
`cate` / `task`	str	`B` / `T-B2`
`metadata`	str (JSON)	source, `image_sha256`, `image_wh`, `region_mode`, `bbox_xywh`, `instance_index`, `gold`

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.

Provenance

Built deterministically (no LLM/teacher; reasoning is null) from AI4Manufacturing/179 — AeBAD (Aero-engine Blade Anomaly Detection, AeBAD_S subset; Zhang et al., "Industrial Anomaly Detection with Domain Shift"): 2,160 aero-engine-blade surface photos, 4 defect types (ablation, breakdown, fracture, groove) + good, each anomalous image with a paired binary pixel segmentation mask (binarized here at gray>40, which reproduces the source defect_area_fraction exactly). Generator: annotate/179/build_179_derived.py in forge_model; machine gates: annotate/179/verify_179.py (all green at build time).

Resolution. Source photos are 3024×3024. Every image here is downscaled to a 1024 long side (LANCZOS; masks NEAREST) and all coordinates are in that pixel space — see metadata.image_wh. This matches common VLM input sizes and keeps the repo compact; a native-resolution rebuild is a deterministic option (DOWNSCALE=None).

Query diversity. The query field is drawn from a fixed pool of surface variants for this task (paraphrases preserving the task and answer format), selected by an independent per-record hash. A machine gate checks that no template correlates with the gold (worst z-scores reported above).

The repository name is an internal task code (the source dataset's code is 179).

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. 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:40`
`connectivity`	`4`
`merge`	`mask_dilate:1pct`
`min_area_px`	`15`
`max_instances`	`8`
`artifact`	`fine`
`fill_floor`	`None`
`legibility_floor_px`	`None`
`min_side_floor_px`	`None`
`spec_sha`	`ff6b39fac2294808`

Provenance and verification


records	3,639
carrying a geometry block	3,639 / 3,639
instances per record	`0`: 1,011, `1`: 1,069, `2`: 441, `3`: 252, `4`: 844, `5+`: 22
total instances	6,193
image dimensions	3024×3024 (3,639)
`scale` values present	[1.0]

Derived from the AI4Manufacturing/193 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 floor is measured at NATIVE; the model renders smaller

min_side_px is in native pixels, and the legibility floor is stated against native. A patch-based VLM does not render at native size, and not only because of the megapixel cap: Qwen2-VL's processor also snaps each dimension to a multiple of 28. Measured on this repo:


native → rendered (qwen2_vl @ 2.36MP)	3024×3024 → 1512×1512
shipped boxes	6,193
clear 16px at native but FAIL it at the render	850 (13.7%)

Those boxes carry a legibility guarantee that does not hold for the image the model actually sees. Nothing in the data is wrong — the geometry is native and complete — but a consumer computing legibility as min_side_px >= 16 will disagree with the render on exactly those. Use forge_model/<family>/adapt.py, which applies the floor at the target size.

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 a 1600×256 strip is rendered 1596×252 and native-pixel boxes are then wrong by a few pixels. forge_model/193/adapt.py regenerates coordinates for a target render size, re-derives counts, and drops records whose gold no longer holds there. {MARK_B}

Geometry (`metadata.geometry`)

Coordinates are native pixels of the image in that record. 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
}

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:40`
`connectivity`	`4`
`merge`	`mask_dilate:1pct`
`min_area_px`	`15`
`max_instances`	`8`
`artifact`	`fine`
`fill_floor`	`None`
`legibility_floor_px`	`None`
`min_side_floor_px`	`None`
`spec_sha`	`ff6b39fac2294808`

Provenance and verification


records	3,639
carrying a geometry block	3,639 / 3,639
instances per record	`0`: 1,011, `1`: 1,069, `2`: 441, `3`: 252, `4`: 844, `5+`: 22
total instances	6,193
image dimensions	3024×3024 (3,639)
`scale` values present	[1.0]

⚠ 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)	3024×3024 → 1512×1512
shipped boxes	6,193
legible at that render (>=16px there)	5,282 (85.3%)

⚠ 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/<family>/adapt.py, which applies the floor at whatever size the consumer renders.

Using it

Downloads last month: 33

Total file size:

2.62 GB

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

179-region

Task

Roles

Provenance

Geometry (metadata.geometry)

Conventions used to derive it

Provenance and verification

⚠ The floor is measured at NATIVE; the model renders smaller

Using it

Geometry (metadata.geometry)

Conventions used to derive it

Provenance and verification

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

Using it

Geometry (`metadata.geometry`)

Geometry (`metadata.geometry`)