Skip to content

Product Catalog Data for Robot Perception

By Noah Loul · Reviewed by Noah Loul · Updated

  1. 01Your data spec
  2. 02Matched to businesses
  3. 03Rights and samples reviewed
  4. 04Licensed delivery
How it works with SourceX: Your data spec → Matched to businesses → Rights and samples reviewed → Licensed delivery.Illustrative

Short answer

Product catalog data — packshot images, alternate views, attributes, dimensions, weights and descriptions keyed to SKUs or GTINs — can train and evaluate a robot's product recognition, attribute grounding and language grounding. Retailers, brands and distributors hold it, but image rights often sit with photographers or manufacturers. Catalog images rarely look like a robot's view, so plan in-situ images and handling data alongside.

When catalog data is the right purchase

A humanoid working in retail, grocery, fulfillment or hospitality has to tell thousands of products apart, read their attributes and follow instructions that name them. Catalogs already enumerate an assortment with images and structured fields, and they are refreshed as products change. When recognition across a large, shifting assortment is your bottleneck, a catalog is a sensible first buy.

It is the wrong buy when the bottleneck is grasping or handling. Catalog data sits on the recognition side of the line drawn in object recognition data vs manipulation training data.

What a catalog contains

FieldExamplePerception useCaveat
Primary packshotFront view on a white backgroundInstance recognition; retrieval galleryStudio light, no occlusion
Alternate views and spinsBack, side, top; turntable sequenceMulti-view recognition; 3D reconstructionCoverage varies by SKU
Lifestyle imagesProduct staged in a kitchenSome contextStaged; often separately licensed
IdentifiersGTIN, SKU, manufacturer part numberJoins to inventory, WMS and planogramsVariants coded inconsistently
Title and description"Stainless 10 in skillet"Language grounding; referring expressionsMarketing language
AttributesColor, material, capacityAttribute recognition and filteringIncomplete; mixed units
Dimensions and weightConsumer unit, case, palletPlanning priors; reach and payload checksOften copied from suppliers, not measured
TaxonomyCategory pathHierarchical labelsSpecific to each retailer
Version historyPack redesigns, size changesRobustness to packaging changeRarely retained

What published catalog datasets show

Depth is uneven across a catalog. ABO, built from Amazon catalog data, covers 147,702 product listings and 398,212 unique catalog images with up to 18 metadata attributes per product; only 8,222 products have 360-degree turntable views and 7,953 have artist-made 3D meshes (Collins et al., 2021). Expect the same in a commercial catalog: broad coverage of basic fields, rich assets for a minority.

Shop images differ from real-world images. Products-10K labels 10,000 SKU-level products with both in-shop and customer images under a hierarchical label graph (Bai et al., 2020). RPC pairs single-product images captured under controlled conditions with multi-product checkout images (Wei et al., 2019). The pattern to copy is clean reference images plus cluttered scenes of the same items.

Shelves are dense. SKU-110K targets tightly packed, often identical products on retail shelves (Goldman et al., 2019), which is what a robot's camera sees in a store and nothing like a packshot. Packshot vs in-situ images covers how to close that gap.

Measurements can follow a standard. The GS1 Package and Product Measurement Standard defines nominal measurement attributes from consumer unit to pallet, and GDSN lets trading partners share product master data through certified data pools (GS1, 2026). Ask whether a supplier's dimensions follow such rules or were typed in by hand; product dimensions and weights covers the checks.

Supplier types

SupplierTypically holdsRights positionBest for
Retailers and e-commerce operatorsBroad assortment, attributes, titles, imagesMany images supplied or licensed by brandsAssortment breadth
Brands and manufacturersOwn photography, packaging artwork, specs, sometimes CADUsually own their contentDepth per product; 3D
DistributorsLarge B2B catalogs, cross-referencesImages often supplied by manufacturersParts and commercial items
Product photography studiosMulti-view archives shot for clientsClient contracts govern reuseConsistent multi-view imagery

The trade-offs between the first two are covered in retailer vs manufacturer object data.

Illustrative package contents

# Illustrative only — field names and values are synthetic, not an available dataset
package: catalog_extract_supplier_058_v0
scope: 18,000 active SKUs in grocery and household categories, US assortment
per_sku:
  identifiers: {gtin: "00000000000000", sku: SKU-058-00123, variant_of: SKU-058-00120}
  images: primary packshot (2000 px), up to 6 alternate views, file-level rights flag
  text: title, description, ingredient or material statement
  attributes: color, material, net content, unit of measure, pack count
  measurements: {height_mm, width_mm, depth_mm, gross_weight_g, source: measured|supplier}
  taxonomy: category path (supplier scheme) + mapping table to buyer scheme
  history: packaging change dates where retained
excluded: customer-uploaded photos; lifestyle images with models; third-party marketplace listings
rights: training and internal evaluation; no redistribution of images; brand names retained in text

What catalog data cannot support

  • In-situ appearance. Occlusion, shelf clutter, tote packing, odd angles and store lighting are absent.
  • Physical behavior. Friction, stiffness, fill state and fragility rarely appear, and listed weights may be wrong.
  • Manipulation. No grasps, motions or contact outcomes.
  • Current packaging. Catalogs lag redesigns, and retired SKUs may be missing.
  • Back-of-house items. Supplies, tools and fixtures that are never sold have no catalog presence.

Preparation usually includes rights filtering per image, deduplication, variant mapping, attribute normalization, a taxonomy crosswalk, and a measurement spot-check.

Quality and acceptance criteria

  1. Coverage. The share of your target SKU list that matches catalog entries meets a threshold you set.
  2. Views. Images per SKU and the share of SKUs with more than a front view are reported.
  3. Attribute completeness. Fill rate is reported per field, not as an average.
  4. Measurement accuracy. A random sample measured physically agrees with listed values within your tolerance.
  5. Identifier integrity. GTIN check digits validate, and joins to your inventory succeed at a stated rate.
  6. Duplicates. Near-duplicate images and recycled packshots across variants are flagged.
  7. Rights flags. Every image carries an owner and a license flag.

Questions to ask suppliers

  1. Who shot each image: your studio, the brand, or a photographer under contract?
  2. What share of SKUs have more than one view, and which views?
  3. Are dimensions and weights measured in-house or taken from supplier feeds?
  4. How are variants, multipacks and packaging redesigns represented?
  5. Do you retain images of retired SKUs and older packaging?
  6. Do you hold any in-store, in-warehouse or customer images of the same products?
  7. Which fields come from GDSN or other data pools rather than your own team?
  8. Can the extract be limited to products whose images you own outright?

Permissions and provenance

Catalog images are often owned by brands or photographers and licensed to the retailer for selling, not for training. Packaging also carries trademarks and copyrighted artwork. Ask for the license under which each image was supplied; see product image rights for the diligence questions. This is not legal advice.

Discuss your requirements

If product recognition is your bottleneck, send SourceX your SKU scope, required views and fields. SourceX looks for US businesses that hold suitable catalog data, checks the data and the supplier's licensing permissions, and coordinates pricing, allowed uses and delivery in a license. It reviews the request and follows up about potential sources; a request does not guarantee a match.

For handling the same products, see each-picking demonstrations. For the rest of the section, see the product and object data hub, the humanoid training data guide and the catalog page on licensing product catalogs and descriptions.

Explore sourcing and licensing options with SourceX

Sources

Frequently asked questions

Which fields in product catalogs can help a robot recognize items?

Product catalog data includes packshot images, alternate views, attributes, dimensions, weights and descriptions keyed to SKUs or GTINs. It can train and evaluate product recognition, attribute grounding and language grounding, although catalog images rarely look like a robot's view.

Why are catalog dimensions and weights not always reliable for robot planning?

Dimensions and weights in catalogs are often copied from supplier data rather than measured, and listed weights may be wrong. Asking whether values follow the GS1 measurement standard, or were typed in by hand, helps a buyer judge how far to trust them.

Can a retailer license the product images it holds for training a robot model?

Catalog images are often owned by brands or photographers and licensed to the retailer for selling, not for training. Each image should come with the license under which it was supplied, and packaging can also carry trademarks and copyrighted artwork.

Describe the data your robots need

Describe the tasks, modalities and permitted uses you need. SourceX reviews the requirement and follows up about potential sources; a request does not guarantee a match.

Discuss your humanoid training-data requirements with SourceX
See if you qualify