Public SKU datasets like SKU-110K give you one thing well: a detector that can find tightly-packed products as generic bounding boxes on a shelf. What they do not give you is fine-grained SKU identity, planogram context, or the lighting and occlusion behaviour of a specific retailer’s stores — which is why a public baseline is a starting point, not a deployment. What Does SKU-110K Actually Contain? SKU-110K is a dense object detection dataset. Its images are photographs of retail shelves packed with thousands of tightly arranged, visually similar products, and the annotations are class-agnostic bounding boxes — “there is a product here,” not “this is a 500ml bottle of brand X.” The dataset was assembled specifically to stress detectors on the small-object, high-density regime that ordinary detection benchmarks avoid. That density is the whole point. A single SKU-110K image can contain well over a hundred instances, sometimes into the low thousands, with heavy inter-object similarity and minimal spacing. This is a fundamentally different distribution from the object counts and object sizes in COCO-style data, and it is the reason a detector trained on generic imagery struggles when you point it at a shelf. Why Do COCO-Trained Detectors Underperform on Shelves? Because SKU-110K and its kin are built for dense object detection — thousands of tightly-packed, similar-looking products per image — a generic COCO-trained detector simply has not seen that regime. COCO scenes average a handful of objects per image at moderate size; a beverage aisle presents hundreds of small, near-identical boxes butted edge to edge. Non-maximum suppression tuned for sparse scenes merges neighbouring products, anchor and stride settings miss the small-object scale, and confidence thresholds calibrated on natural images produce a mess of dropped or fused detections. This is why a shelf-execution model needs training data that reflects that density and small-object regime. The gap is not a matter of a few percentage points of mAP — in the shelf imagery we’ve profiled, a stock COCO detector will routinely miss the majority of facings in a densely stocked bay, while a detector trained or fine-tuned on dense shelf data recovers most of them. The dataset choice is doing more work here than the architecture choice. Where Do Public SKU Datasets Fall Short of a Real Store? Public SKU datasets provide detection-of-a-product-as-an-object, but they rarely provide three things a production system needs. Here is the practical breakdown of what you get versus what a store deployment demands. What SKU-110K-style datasets give you: Class-agnostic product localisation trained on genuinely dense shelves — a strong “find every facing” detector. Robustness to the small-object, high-overlap regime that breaks generic detectors. A reusable backbone/baseline you do not have to build from scratch. What they do not give you, and why it matters: Fine-grained SKU identity. The boxes say “product,” not “which product.” Distinguishing a regular from a diet variant, or one flavour from its near-twin, is an identity problem the public labels never solve. Planogram context. There is no notion of where a SKU should sit, so the dataset cannot tell you about facing-count compliance or product-out-of-place drift on its own. Store-specific lighting and occlusion. Public images do not match a given retailer’s fixture lighting, glare, chiller reflections, shelf-edge labels, or the partial occlusion caused by shoppers’ hands and price rails. A model that never saw your stores’ conditions will degrade on them. That third row is the one teams underestimate. Two stores from the same chain can differ enough in colour temperature and shelf depth that a model tuned on one drops noticeably on the other. How Should You Combine Public Baselines With Store Data? Treat the public dataset as pre-training for the localisation task, then add a store-specific labelling and fine-tuning pass on top of it — this is almost always required for a production shelf-execution model. In practice we split the problem in two: a detector (largely transferable from public dense-shelf data) and a fine-grained classifier or embedding stage (almost entirely store- and catalogue-specific) that assigns SKU identity to each detected facing. The identity layer is where your labelling budget goes, because it encodes your actual product range, packaging refreshes, and the variant confusions that matter to your planogram. We usually scope a first labelling round around the SKUs and store formats that drive the compliance metrics the client actually reports on, rather than trying to label the entire catalogue at once. The planogram-drift and stock-out detection logic — the part that turns detections into an operational signal — is discussed in more depth in our overview of how shelf-execution AI catches stock-outs and planogram drift, and it sits downstream of both the detector and the identity classifier. If you are scoping this kind of build, our retail computer-vision practice is where we handle the store-specific data collection and fine-tuning side of it. A reasonable sequencing: start from a dense-shelf-pretrained detector, capture a representative sample of images from the target stores’ fixtures and lighting, label facings plus SKU identity on that sample, fine-tune, then measure on held-out stores — not on held-out crops from the same stores, which flatters the numbers. Frequently Asked Questions Is SKU-110K enough to build a shelf-execution product on its own? No. SKU-110K gives you a strong class-agnostic product detector for dense shelves, but it contains no SKU-level identity labels, no planogram context, and none of your specific stores’ lighting and occlusion conditions. You need a store-specific labelling and fine-tuning pass layered on top before it is production-grade. Why can’t I just fine-tune a COCO detector for shelves? You can start from COCO weights, but COCO’s object density and scale are far from a packed retail shelf, so the detector has not learned the small-object, high-overlap regime shelves present. Fine-tuning on dense shelf data (public or your own) is what closes that gap; the pre-training source matters less than exposure to the correct density distribution. Does a public SKU dataset help with planogram compliance? Only indirectly. It helps you locate facings reliably, which is a prerequisite, but planogram compliance also needs SKU identity and a model of expected placement — neither of which the public bounding boxes provide. Those layers are store- and catalogue-specific and have to be built on your own data. How much store-specific labelling is typically needed? It varies with catalogue size and how visually similar your variants are, so treat any single figure with caution. In the deployments we’ve profiled, the localisation detector transfers well from public data while most of the labelling effort goes into the fine-grained identity classifier for the SKUs that drive the reported compliance metrics. Scoping to those priority SKUs first keeps the initial labelling round tractable.
