Short answer
Multi-view inspection imagery shows the same physical part from several fixed or rotated viewpoints, so a defect hidden in one view can appear in another. Source it from manufacturers whose machine-vision stations already capture multiple angles, and insist on unit identifiers, view metadata and splits made by unit rather than by image. It supports inspection models, not robot manipulation.
Why multi-view data is a different purchase
A single top-down photograph of a machined housing misses the bore wall, the underside lip and the side flange. Plants that care about those surfaces add cameras, rotate the part on a turntable, or pass it through several stations, and the resulting archive looks different from a pile of unrelated defect photos. Every image now belongs to a unit, and every unit has several images that are strongly correlated.
That structure changes three decisions: how defects are labeled, how the archive is split into training and test sets, and what metadata must travel with each file. Get any of them wrong and a model looks excellent in validation because it has already seen the same part from another angle. The general version of that problem is covered in leakage in defect datasets; this page applies it to multi-angle capture.
What public multi-view work tells you
Real-IAD is a useful reference for what a multi-view industrial set looks like: about 150K high-resolution images of 30 objects of varied materials, captured from multiple views (Wang et al., 2024). The authors also propose a fully unsupervised setting in which the training data may contain defective images, which matches what a plant archive really is: nobody curates the line into a defect-free training folder.
Treat it as a reference for structure and evaluation framing only. A commercial archive will have different parts, lighting and defect definitions, and a public benchmark number says little about performance on your product. Buyers who need a broader grounding in what defect archives contain can start with sourcing defect image datasets.
Where the images come from
| Supplier type | Typical multi-view setup | What to watch |
|---|---|---|
| Machined-part and casting manufacturers | Several fixed cameras plus ring lighting at one station | Per-camera calibration drift; views stored in separate folders |
| Assembly lines with multi-station vision | A different camera at each station, parts tracked by serial | Defect may arise between stations, so the same unit differs across views |
| Electronics and small-part producers | Turntable or multi-axis rig capturing many angles | Rotation angle stored only in file names |
| Contract inspection houses | Operator-driven photography of several faces | View choice varies by operator |
Most of this exists as in-line machine-vision archives, retained for traceability rather than for training. Where the goal is a reconstructed shape rather than separate photographs, see 3D surface inspection data. Retention is often short and storage tiering is uneven, so ask early what actually survives.
Labels: per view, per unit, or both
Three label granularities are common, and a multi-view package should state which it carries.
- Per-unit disposition. The unit passed, was reworked or was scrapped. This is what plants record, and it is the label most easily linked to outcomes.
- Per-view presence. The defect is visible in view 3 and not in views 1, 2 and 4. Plants rarely hold this; it usually has to be added by relabeling.
- Per-view localization. Boxes, polygons or masks in each view where the defect appears. This is the most expensive layer; see pixel-level defect segmentation.
A per-unit label attached to every image of a failed unit is a weak label: most of those views may show clean surface. Models trained on it learn noise unless the loss is built for it. Ask the supplier whether the label was assigned to the unit or to the image, and sample both.
Splitting multi-view data without leakage
The splitting unit must be the physical part, never the image. If views of one part land on both sides of the split, the test set is contaminated. Where the claim needs it, split higher: by lot, by line, by production week or by camera station, so the test set resembles a future shipment rather than a shuffled sample of the past.
Also keep the same defect event together. Parts re-inspected after rework may appear twice under one serial number; decide whether they are one unit or two before splitting.
Illustrative multi-view package manifest
# Illustrative only - field names and values are synthetic examples
package: multiview_inspection_v0
unit_table:
unit_id: unit_000417
lot_id: lot_A12
line_id: line_03
disposition: rework # pass | rework | scrap
disposition_source: mes_record
images:
- file: unit_000417_v1.png
view_id: v1 # fixed camera, top
station: st_2
camera_id: cam_B
pose_note: "part at 0 degrees on fixture"
lighting: ring_white
label_level: view # unit | view
defect_visible: false
- file: unit_000417_v3.png
view_id: v3
station: st_2
camera_id: cam_D
lighting: ring_white
label_level: view
defect_visible: true
mask_file: unit_000417_v3_mask.png
calibration: per-camera intrinsics file, dated
split_key: lot_id # split unit chosen by buyer
excluded: robot actions, joint states, forces
Every field above is something a buyer sets. The point is that view identity, station and calibration are columns, not folder names someone has to decode. The imaging conditions metadata page lists what else to capture, and documentation in the style of Datasheets for Datasets is a sensible way to ask a supplier to describe composition and collection process.
Quality and acceptance pointers
- Completeness per unit. Check what fraction of units has the full view set; partial sets bias what the model sees.
- View consistency. Confirm that view "v2" means the same pose across the archive, not whatever the operator chose that day.
- Label agreement across views. If a defect is marked in one view, a reviewer should be able to find or explain its absence in neighboring views.
- Temporal span. Images from one week of one lot say little about drift across months.
- Duplicate and near-duplicate units. Re-photographed parts should be linked, not hidden.
Set the acceptance thresholds yourself against your own tolerance for missing views; none of these checks has a universal pass mark.
What multi-view inspection imagery cannot support
This data records how parts looked under a fixed camera arrangement. It does not contain robot actions, joint states, force signals or the motion of a person picking a part up to turn it over, so it cannot train manipulation or humanoid control. Control learning needs robot or teleoperation data; see humanoid active inspection for how inspection and physical interaction differ.
It also does not transfer for free to a moving camera. A fixed multi-camera rig and a camera carried by a robot see different distances, angles and blur. Multi-view data helps most where the deployment keeps the rig, or where the buyer wants evaluation sets with known viewpoints. Finally, viewpoint coverage is only what the plant chose to capture: surfaces nobody photographed are absent, and rare defects remain rare, which rare defects and class imbalance addresses.
Questions to ask suppliers
- Is each image tied to a unit serial, and can units be traced to lot, line and shift?
- How many views does a complete unit have, and what share of units is complete?
- Are view definitions stable across the archive, or did the camera layout change over time?
- Were labels assigned to the unit, the image, or the defect region, and by whom?
- Is calibration or at least camera and lens identity stored per view?
- Were any views compressed, cropped or resized before retention?
- Do parts re-inspected after rework appear as separate units?
- Does the archive include borderline or later-overturned calls, and are they flagged?
- Which customer parts or design features appear, and who can authorize licensing?
Permissions and provenance
Parts on the line may embody a customer's design or proprietary geometry, so images can carry third-party rights as well as the supplier's own. Ask who owns the part designs, whether customer agreements restrict use of inspection records, and whether serial numbers or markings identify customers. This is not legal advice; a buyer's counsel should review any license, and redaction of markings does not by itself settle permission questions.
Discuss your requirements
If you need multi-angle inspection images, describe the part types, views, label level and permitted uses to SourceX. SourceX reviews the requirement and follows up about whether US businesses may hold suitable material; a request does not guarantee a match. For more on this area, see the inspection data hub and the humanoid training data guide, or the catalog entry for images and inspection photos.
Tell SourceX what your evaluation set needs to cover
Sources
- Real-IAD: A Real-World Multi-View Dataset for Benchmarking Versatile Industrial Anomaly Detection — public multi-view industrial anomaly set and its unsupervised setting with defective training images.
- Datasheets for Datasets — model for documenting dataset composition and collection process.