How many classes can a smart camera handle: the memory limit

Classification jobs grow. A line starts with twelve classes at commissioning, carries sixty after the second product family arrives, and needs a hundred by year end. On a smart camera trained by example-based (edge) learning, every one of those training images is stored on the device, and past a few hundred images the training tool starts crashing — usually right when you add pictures. The class count in a datasheet is a format limit, not a fitted-in-memory promise. This guide gives you the one multiplication that predicts the failure, a worked example at 100 classes, and the decision for each platform: trim the job, step up to an x86 smart camera, or train on a PC and run on a vision controller.

The decision, up front

The limit is stored bytes, not classes. Example-based classification keeps every labeled training image in the job, so the memory bill is:

Budget 0.5-1 MB per stored image for 1-2 MP color captures: the compressed file is 0.3-0.6 MB, and libraries add thumbnails, feature caches and filesystem overhead on top.

Keep the whole library under about 200 MB on a compact smart camera. At twenty-five images per class, that is eight classes at 1 MB per image and eighty classes at 0.1 MB. Up to about 2 GB, a large-memory or x86-platform smart camera copes, with slow re-trains and job switches. Above 2 GB — exactly where 100 classes × 25 images × 1 MB lands, at 2.5 GB — stop fighting the camera: train on a PC and run the classifier on a vision controller.

Half of free storage stays free on purpose. Re-training allocates scratch space at roughly twice the stored size, and a crash on add is what working without headroom looks like.

Why the camera runs out: the library, not the classes

Example-based tools classify by comparing a new image against stored exemplars, so the images — or per-image feature records that grow with them — live in the job on the device. A trained deep-learning classifier behaves differently: training distills the whole library into a fixed model file, typically 5-100 MB for the compact backbones that run on embedded devices, whatever the class count. Runtime memory stops growing with the training set. That single difference is the whole upgrade argument, and it is the same trade behind choosing AI versus rule-based tools on a smart camera.

Two costs scale with the library on the example-based side. Training scratch runs at roughly twice the stored bytes while the tool re-extracts features over every image. And inference searches the exemplar set, so frame time and job-switch time grow with library size well before anything crashes — a job that takes minutes to switch is telling you what a crash will confirm later.

Adding a picture re-runs the extraction pass over the whole library, which is the moment of peak allocation. Near the ceiling that allocation fails, intermittently, because logs, image buffers and other jobs compete for the same space. A job that finished training can therefore run fine and still crash on the next add.

What one stored image costs

Bytes per image is width × height × bytes per pixel, before compression — 3 bytes per pixel for color, 1 for mono:

The compression column is what JPEG-class encoding achieves on typical industrial scenes; lossless PNG on flat scenes compresses less. Two levers beat compression outright: mono instead of color divides raw bytes by three, and cropping to the classifier's region of interest divides them by the area ratio.

Worked example: 100 classes at 25 images each

The job that breaks cameras: 100 classes, 25 images per class, captured on a 1.6 MP color camera at 1440 × 1080.

• Stored files: 100 × 25 = 2,500 images × 0.8 MB = 2,000 MB = 2.0 GB.
• Raw size of the same library: 2,500 × 4.7 MB = 11,750 MB = 11.75 GB, the worst case if the tool decodes everything while re-training.
• Re-train scratch at twice the stored bytes: about 4 GB on top of the 2 GB library.

A compact smart camera with a few GB of free user storage fails this job on storage alone, and its RAM never covers the decode-all case. The failure lands where these jobs fail in the field: around a hundred classes, crashing on add.

Trim it on-camera instead. Crop to a 400 × 400 mono ROI, about 0.08 MB stored; at 15 images per class the library is 100 × 15 × 0.08 MB = 120 MB, inside the 200 MB budget with headroom. This works only if your classes are visually distinct, because fifteen images per class is the working range for example-based learning on well-separated classes.

Or move it off the camera. The same 2.5 GB library is routine on a controller with a 128 GB SSD, and training on a GPU-class PC then deploying the fixed model removes the library from the device entirely. Why GPUs beat CPUs for deep-learning training covers where that training pass belongs.

Where each platform lands

Tier by stored-library budget, with class counts computed at 25 images per class:

The controller row is computed on a 128 GB SSD; the class counts are the budget divided by 25 images times the per-image bytes.

The smart cameras line spans simple vision sensors up to multi-megapixel devices with onboard training. The MV-SC5060XM-08M-WBN is a 6 MP smart camera with an 8 mm M12-mount lens and a 1/2.4-inch sensor.

An x86-platform camera closes most of the gap: PC-class memory and storage with the sensor, lens mount and lighting attached. The LS-SMC-0017 is an 8.8 MP smart camera on an x86 platform, with a 1-inch sensor and a C-mount.

The full escape is a vision controller: the library and the classifier live on the controller, and the camera becomes a sensor. The MV-VC3301H-128G66 carries 8 GB of memory and a 128 GB SSD behind a Core i3 processor. Pair it with an area scan camera such as the MV-CS200-10UM, a 20 MP USB3.0 camera on the IMX183 sensor.

Controllers in the category scale from 8 GB to 32 GB of memory, so the decode-all case of a big library stops being the constraint. Browse both in the camera and controller finder, or start the system configurator at the camera step.

Keep the classes, cut the bytes

Four cuts, in order of payback:

1. Crop to the ROI. The classifier needs the part, not the frame. Cropping 1440 × 1080 to 400 × 400 divides stored bytes by about ten; with mono, by about thirty.
2. Go mono where color is not the feature. Raw bytes divide by three. Keep color only when the class signal is colored print, caps or coatings.
3. Match resolution to the feature. Shape and texture classification needs roughly 200-400 pixels across the part. Capturing 1,400 pixels across wastes memory and re-train time in proportion.
4. Cap images per class. Fifteen to thirty per class is the working range for example-based learning; past fifty, accuracy flattens while the bill grows linearly. Spend extra images only on the pairs the confusion matrix actually confuses — the same discipline as training images per class in object detection and sizing defect-inspection sample counts.

Then housekeeping: purge near-duplicates (same part, same pose, seconds apart), and split the job by product family if the classes group naturally. Note that a large library makes every job switch slower, not just the training.

When to move off the camera

Committed decisions by case:

• Library ≤ 200 MB: stay on a compact smart camera. Roughly twenty to eighty classes at twenty-five images per class, set by your image size. Nothing downstream buys you anything here.
• Library 200 MB to 2 GB, classes visually distinct: trim with ROI and mono first. If it still does not fit, an x86-platform smart camera is the on-device answer; expect re-trains of minutes and job switches of seconds.
• Library > 2 GB, or 100+ classes, or a demand for 300 images per class: train on a PC — GPU-class for preference — and deploy the fixed 5-100 MB model file to a vision controller. The model replaces the multi-gigabyte library at runtime.
• Crashes at a modest library: read the last section before buying anything, because memory may not be the fault.

Moving also pays when device re-train time reaches minutes per added batch, or when operators wait on job switches. Both scale with the library, and both disappear with a deployed model.

Checks before you commit to a class count

Run these before the purchase order, not after the first crash:

1. Multiply target classes × images per class × bytes per image at your capture settings, and write the product down; it is the library.
2. Read the free user storage off the device's specification page — free, not total, since the OS and resident jobs already hold part of it — then halve it for the ceiling.
3. Measure re-train time at half the target library and double it. The pass touches every image, so the linear extrapolation is close.
4. Measure job-switch time with the full library resident.
5. Hold 30-40 % headroom under the ceiling. A crash on add is the signature of zero headroom.
6. Cap log retention and image archiving on the device, or storage fills underneath the library — the failure looks identical. Embedded log storage filling up is the same disease on 3D cameras.
7. Validate per class with a confusion matrix on held-out parts before freezing the class count. A class that never recognizes is worse than a class that never trained.

For fitting the classifier's own working memory into an embedded budget, fitting vision algorithms into fast frame-buffer memory is the companion read.

When the crash is not memory

Memory failures are consistent: the tool crashes at nearly the same image count every time. Random crashes with a small library point elsewhere:

• Power. A strobed light sharing the supply dips the rail at full load. Measure at the camera connector, under strobe, not on the bench supply.
• Link. A training library syncs over the network while you add images; a cable or switch that drops under burst traffic kills the add, not the runtime.
• Storage already full. Logs and saved inspection images consumed the space the library needs. Check free space before blaming classes.
• Software revision. If crashes began after an update or sit on an old release, move to the current release and retest before redesigning the job around a fault that is already fixed.

One consistent number separates them: crash-at-a-count is memory; crash-at-random is power, link or storage.

Sizing the whole station — camera, lens, light and the controller that carries the classifier — takes a few minutes in the system configurator. Or send the class count and capture settings through the contact page, and we will run the arithmetic with you before you commit.