Short answer
Label and print inspection data comes from packaging and labeling operations that photograph printed labels, codes and cartons on the line. Because the defects involve text, the useful labels include the expected string, the read string, and the fault type, not only a bounding box. Buyers should ask for artwork versions and verification outcomes. It supports inspection models, not robot control.
Why print inspection is not generic defect detection
A scratch is a scratch whatever it says on the box. A misprint is defined by what the label was supposed to say. If the lot code reads 2418 where the batch record says 2481, the print is crisp, correctly placed and wrong. A model that only looks for smudges and missing ink would pass it.
That is why this page treats label inspection as a pairing problem: an image on one side, an expected content record on the other, and a verdict between them. Datasets that omit the expected side can still train a fault detector for blur and voids, but not a verifier.
Fault families in label and print data
- Content faults. Wrong text, wrong date or lot, missing field, wrong language or version of artwork, swapped label on a variant.
- Print-quality faults. Faint or smeared characters, voids, banding, ink spread, low contrast, bleed.
- Placement faults. Skew, offset, wrinkled or lifted label, cut-off text, label on the wrong face.
- Code faults. Unreadable or low-grade barcodes and 2D codes, wrong encoded data, quiet-zone violations.
- Color and graphics faults. Wrong ink, registration shift, missing logo or symbol.
Each family needs different labels. Content faults need text; placement faults need geometry; code faults need the decoded payload and the grade the scanner produced.
OCR-aware labels
A useful package attaches three layers to each region of interest.
| Layer | What it holds | Source |
|---|---|---|
| Location | Box or quadrilateral around each text line, field or code | Annotators or the vision system |
| Expected content | The string the label should carry, per record | Artwork file, ERP or batch record |
| Observed content and verdict | OCR or decoder output, plus match / mismatch / unreadable | Vision system log, reviewed by a person |
When the expected string and the observed string are both stored, the dataset can support verification models, OCR error analysis and evaluation of a reader on degraded print. When only the verdict is stored, it supports classification but gives no way to audit it.
Note the bounds of the annotation vocabulary. Instance-annotated public datasets such as COCO contain 328k images and about 2.5 million labeled instances across 91 categories (Lin et al., 2014), but they are natural-scene imagery, not printed labels or text verification. Use COCO only as a reference for instance-level annotation. "COCO-style" JSON is a general practice with variants, so verify field conventions against the format's own documentation before writing them into a contract. How to package boxes, masks and attributes for delivery is covered in defect annotation formats and delivery.
Where the data comes from
| Supplier type | What they hold | Common gap |
|---|---|---|
| Contract packagers and co-packers | Line-camera images of cartons and labels | Expected content stored in the customer's system |
| Food, beverage and consumer-goods plants | Date-code and label verification captures | Only rejects retained |
| Regulated manufacturers (for example medical or pharmaceutical) | Label reconciliation records | Strict confidentiality; short retention rules |
| Label printers and converters | Press-inspection images | Little downstream outcome |
Regulated sectors typically have strong reconciliation records but the tightest restrictions on sharing. A requirement that names the sector helps narrow the search. Related packaging defects that are not text, such as seal failures, are covered in packaging and seal defects and fill-level and closure inspection.
Illustrative record for a label-verification package
# Illustrative only - synthetic values; text fields are made up
package: label_verification_v0
line_id: pack_line_09
record:
image: lbl_000812.png
artwork_version: art_v14
sku_variant: variant_B
regions:
- id: lot_field
box: [x, y, w, h]
expected_text: "LOT 0000-A"
observed_text: "LOT 0000-A"
verdict: match
- id: date_field
box: [x, y, w, h]
expected_text: "EXP 00/00"
observed_text: "unreadable"
verdict: unreadable
- id: barcode
payload_expected: "synthetic-payload"
grade: "scanner-reported"
placement: {skew_deg: "measured", offset_mm: "measured"}
disposition: reject
reviewer: reviewer_D
split_key: artwork_version + production_lot
excluded: robot actions, joint states, forces
Split by artwork version and lot as well as by time. A model that has seen every version of a label may only be memorizing layouts.
Quality and acceptance pointers
- Expected-content coverage. Check the share of images with a stored expected string; without it, content faults cannot be judged.
- OCR provenance. Know which engine produced observed text and whether it was corrected by a person.
- Variant coverage. Count artwork versions, languages and SKU variants in the set.
- Fault realism. Ask whether faults are real line events or staged samples; staged faults are useful but different.
- Image sharpness. Confirm resolution is enough to read the smallest text.
Thresholds are for the buyer to set against the application. For the general label-schema discipline, see defect taxonomy and label schema.
What this data cannot support
Print inspection images do not carry robot actions, joint states or forces. They cannot train a humanoid to apply a label, pick a carton or place a pallet tag, which needs robot or teleoperation data. They also say little about whether a label survives later handling unless outcomes are joined.
The data is also narrow: a model verifying one customer's labels does not generalize to arbitrary documents, and OCR performance on printed labels differs from performance on handwriting or scene text. Rejected labels are rare, so fault classes will be sparse; see inspection images linked to outcomes for how to join images to decisions. For the object-recognition side of the same cartons, the page on product catalog data for robot perception explains why recognition data differs from handling data.
Questions to ask suppliers
- Are expected text, artwork versions and SKU variants stored alongside each image?
- Which OCR or decoding engine produced observed values, and were they human-reviewed?
- Were faults real line events, injected test samples, or both?
- Which fault types are present, and how many are content faults versus print-quality faults?
- How were unreadable cases labeled?
- Are false rejects and false accepts identifiable?
- What sectors and regulatory regimes govern the labels, and do they restrict retention or sharing?
- Does the artwork belong to the supplier or to its customers?
- Are images retained at full resolution, or only as cropped regions?
Permissions and provenance
Label images can contain brand artwork, ingredient or formula information, lot and expiry data, regulatory claims and sometimes customer names. Ask who owns the artwork, whether supply contracts restrict records, and whether any text identifies customers or patients. This is not legal advice, and blurring a field does not by itself resolve a rights question.
Discuss your requirements
If you need label or print inspection data, describe the label types, fault classes, text-labeling needs and permitted uses to SourceX. SourceX reviews the requirement and follows up about potential sources among US businesses; a request does not guarantee a match. For more, visit the inspection data hub, the humanoid training data guide, or the catalog entry for inspection reports.
Explore sourcing and licensing options with SourceX
Sources
- Microsoft COCO: Common Objects in Context — scale and instance-level annotation of a public natural-scene dataset, used as an annotation reference only.