Short answer
Category-level recognition asks what kind of thing an object is; instance-level recognition asks which exact one it is, such as a specific SKU. Category data needs breadth across appearance within a class. Instance data needs many views of each item, packaging variants and links to catalog identifiers. Choose the level from the decision the robot must make.
Start from the decision, not the dataset
Teams often say "object recognition" and mean different things. A robot that tidies a room needs to know that something is a mug and where it can be grasped. A robot that restocks a store must know that this is the 500 ml variant of one specific product, because the planogram, the price and the destination shelf depend on it. The first is category recognition; the second is instance recognition.
The data differs accordingly. Buying category data for an instance problem produces a model that finds products and cannot tell them apart. Buying instance data for a category problem spends money on identifiers that may never be used. This page helps set the level before a supplier is approached; the supplier-side material on catalogs is in product catalog data for robot perception.
What each level means
| Aspect | Category-level | Instance-level (SKU) |
|---|---|---|
| Question | "What kind of object?" | "Which exact item?" |
| Example (synthetic) | bottle, box, can | sku_00417, 500 ml, flavor B |
| Label | Class from a taxonomy | Catalog ID, often with parent classes |
| Variation to cover | Shapes, materials, colors within the class | Each item's views, packaging variants and states |
| Failure that matters | Unseen kinds of object | Look-alike items, redesigns, small text differences |
| Main data risk | Narrow class coverage | Missing SKUs and stale appearance |
Fine-grained product recognition sits between the two: separating variants within a category, often by small differences in print or size. It behaves like instance-level work for data purposes.
What published datasets show
Products-10K is a human-labeled dataset of 10,000 SKU-level products frequently bought on JD.com. It includes in-shop and customer images and a hierarchical label graph spanning fashion, 3C, food, healthcare and household (Bai et al., 2020). Three features are worth copying into a specification: labels are SKUs, not just classes; two image sources (professional in-shop and customer-taken) are included; and a hierarchy lets a model be trained and scored at several levels. The paper's dataset is e-commerce imagery, and a buyer should not assume it matches a physical store's camera or lighting.
For robotics, the YCB object and model set addresses a different goal: a shared physical set of everyday objects, varying in shape, size, texture, weight and rigidity, with high-resolution RGB-D scans, physical properties and geometric models, plus benchmarking protocols for manipulation (Calli et al., 2015). Its value is that every lab can hold the same instances. Instance identity there serves repeatable testing, not retail recognition. It also shows how recognition and handling data can be linked by instance, which a catalog-only purchase would not provide.
Data needs by level
Category-level. Breadth usually matters more than depth. Many examples across materials, colors, sizes and conditions; clean class definitions; negative examples of near classes; backgrounds and clutter like deployment. A taxonomy matters: if two classes overlap, annotators are likely to disagree. See product taxonomies.
Instance-level. Each instance needs:
- multiple viewpoints, including top and back where labels live;
- all active packaging variants and promotional versions, with dates;
- in-situ images (shelves, bins, hands) as well as studio packshots, since packshot and in-situ images show different things;
- stable identifiers linked to a catalog or master record, so labels survive renaming;
- coverage of look-alike pairs, which is where errors concentrate.
Instance recognition also carries a maintenance cost. SKUs change faster than classes; see SKU churn and catalog refresh.
Illustrative recognition specification
# Illustrative only - synthetic values; adapt to your deployment
recognition_level: instance # or: category
label_schema:
instance_id: catalog_sku
parents: [brand, product_family, category]
images_per_instance:
studio_views: "set by buyer, covering all faces"
in_situ: "set by buyer, across shelf positions and lighting"
variants:
packaging_revisions: all active, with start and end dates
size_variants: required
look_alike_sets: "supplier flags visually similar SKUs"
unknown_policy: "model must output 'unknown' rather than nearest SKU"
evaluation:
heldout_by: [store_site, camera, month]
slices: [look_alike, new_packaging, partial_occlusion]
novel_instance_test: "SKUs absent from training"
The unknown_policy and novel-instance test are the parts people forget. A closed-set instance model is only correct as long as the catalog is stable. How to design a test for unseen items is in novel-object generalization evaluation.
When to choose which
- Choose category when the robot handles whatever it finds: general tidying, sorting waste, clearing tables, or any task where the response depends on type, not identity.
- Choose instance when downstream systems key on identifiers: inventory, restocking, order assembly, planogram checks. See grocery and retail product recognition.
- Choose both, linked, when you need robust fallback: recognize the exact SKU when it is known, and fall back to category when it is not. The hierarchy in the label schema makes this possible.
- Plan for a long tail. Many inventories have many items with few images; see long-tail object coverage.
Cost and maintenance considerations
Instance-level data has a recurring cost that category-level data mostly avoids. Each new SKU needs images, and each packaging revision may need new images with an effective date so that old and new looks are both recognized during the transition. Ask whether the supplier can provide refreshes, and under what license terms, rather than treating the first delivery as final. See packaging variants and SKU appearance for how appearance changes show up in data.
Category-level programs have a different recurring cost: the taxonomy. Classes that seemed clear at the start blur when new kinds of objects arrive, and relabeling is expensive. Record the taxonomy version in the data package.
Limitations
Recognition labels at either level say nothing about handling. A SKU identifier tells you what the object is, not how to grasp it, how heavy it is or whether it deforms. Those require physical-property and grasp data, and object recognition data vs manipulation training data sets out the distinction.
Catalog images may not match the robot's sensors, and customer-taken images differ from deployment cameras. Counts of SKUs are not a measure of quality; one hundred SKUs with two images each can be worse than ten with a hundred. And instance labels are only as good as the supplier's master data, so an audit of the catalog itself is a sensible first step; see product master data quality audit.
Questions to ask suppliers
- Are labels at SKU, variant or category level, and which identifier scheme do they use?
- How many images per SKU, and how many viewpoints and capture conditions?
- Are packaging revisions included, with effective dates?
- Which images are studio and which are in situ or customer-taken?
- Can you flag look-alike SKUs or known confusions?
- Is there a hierarchy from SKU to family to category, and who maintains it?
- How were labels verified, and what is the observed error rate?
- How often does the catalog change, and can updated images be licensed later?
- Who owns the images and the product identifiers, and may both be licensed for training?
Discuss your requirements
If you know which recognition level your robot needs and want to find out whether suitable images exist, describe the products, image types and permitted uses to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. A request does not guarantee a match; SourceX follows up about potential sources. Start at the humanoid training data guide or the objects hub, and see the site's page on product catalogs and descriptions.
Discuss your humanoid training-data requirements with SourceX
Sources
- Products-10K: A Large-scale Product Recognition Dataset — SKU-level labels, two image sources and a label hierarchy.
- Benchmarking in Manipulation Research: The YCB Object and Model Set and Benchmarking Protocols — shared physical object set with scans, properties and models.