In brief

German agritech start-up Alpha‑Protein worked with EDIH‑AICS and the FZI research centre to test computer vision for counting mealworm larvae and estimating their weight from images. The company is designing industrial protein production, so it chose to test data collection and modelling before scaling the line, while camera, annotation, and methodology mistakes were still inexpensive to correct.

The pilot produced acceptable initial results, but quantitative evaluation was not yet possible because the data set was too small. The model recognised most objects while struggling when larvae overlapped closely. This is not a weakness of the publication. It is a valuable example for smaller companies: a convincing demonstration was not declared production-ready without evidence.

The business problem was larger than one model

Alpha‑Protein is developing an automated factory concept for growing mealworms and producing protein ingredients. During plant design, the company needs to understand which parameters influence growth, how structured process data should be captured, and where analytics can reduce manual work. Counting and weighing laboratory samples was one candidate operation.

Manual counting is repetitive, tiring, and difficult to scale. Yet this is harder than simply detecting an object in a photograph. Larvae touch and partly cover one another, change position, appear on different backgrounds, and vary in size. Estimating weight requires more than drawing a box around a cluster: the system must separate individual instances or derive a robust signal from area and shape.

The team first ran a workshop, developed several data-driven scenarios, and ranked them by feasibility, benefit, innovation, and sustainability. Only then did it select laboratory counting and weight prediction.

What the pilot did

A DSLR camera was fixed above a laboratory surface. Alpha‑Protein captured several dozen photographs with different arrangements of larvae and backgrounds including colours, sand, and dirt. The images were annotated with classes, bounding boxes, and masks using AI-assisted tools named in the case study, including Segment Anything and Labelbox.

In parallel, FZI built a machine-learning pipeline using public data sets and prepared several pre-trained models. These models were then fine-tuned on the company's own annotated images. Generative AI was also used to create additional synthetic training images.

Synthetic data supplemented rather than replaced real photographs. The holdout set should contain independent process images: variations of the same scene in training and testing will inflate the evaluation.

According to EDIH, FZI contributed about 20 working days. Alpha‑Protein expected to invest a comparable amount of its own time, including the continuing test phase. Even a compact experiment needs a process expert to define the target, capture images, annotate them, and review failures.

Why overlapping objects are the decisive test

The initial prototype correctly identified and estimated the weight of most larvae, but sometimes merged tightly intertwined objects or missed them. In computer-vision terms, this is an instance-segmentation problem: the system must identify not only the class of each pixel but also separate adjacent objects of the same class.

The open Segment Anything model can generate masks from points or boxes and accelerate annotation. It still requires domain validation on small homogeneous objects, glare, shadows, damp material, and different optics. Annotators correct boundaries, while the process owner defines acceptable error.

Business evaluation should examine slices rather than only one average score:

  • isolated versus overlapping objects;
  • clean versus contaminated backgrounds;
  • different batch density, size, and moisture;
  • stable versus changed lighting;
  • the normal camera position versus permitted movement;
  • routine samples versus rare edge cases.

If a model is strong on a clean tray and weak on real substrate, an average metric may hide exactly the failure that matters in operation.

A possible production architecture

The source describes a laboratory prototype. It does not claim that the model is already integrated into production or that it runs on premises. A practical production design could use the following flow.

1. A camera with controlled lighting captures a tray in fixed geometry. Each image receives a batch identifier, timestamp, line parameters, and a camera-configuration version.

2. A quality gate checks focus, exposure, and the expected region of interest. An invalid image is not passed to the model as if it were normal.

3. A local inference service creates masks, counts objects, and estimates weight. Along with the result, it reports confidence, the proportion of overlaps, and out-of-distribution warnings.

4. Process rules compare the result with an acceptable range. A borderline case goes to an operator together with the source image and mask overlay.

5. An approved result is written to the manufacturing system or laboratory record. An operator correction is stored separately and may enter the data set for the next model version.

6. Camera, data, model, and threshold versions are recorded. An update first runs in shadow mode and can be rolled back quickly.

Local inference is useful when the line must operate without internet dependency, images are sensitive process data, or cloud round-trip time interferes with cycle time. Deploying near the camera also makes it possible to retain only necessary evidence instead of an unlimited archive of raw frames. The source does not state where the Alpha‑Protein prototype ran, so it should not be described as an on-premises deployment.

Data matters more than model size

A feasibility pilot needs a representative sample collected against a predefined condition matrix. Several dozen photographs, as in this project, can test feasibility but cannot demonstrate industrial robustness.

A practical data set should include:

  • capture rules and a reference camera position;
  • a class dictionary and instructions for disputed cases;
  • double annotation for a subset to measure expert agreement;
  • separate batches and dates for training, validation, and final testing;
  • metadata for lighting, background, density, and sample condition;
  • a deliberately difficult edge-case set;
  • provenance records for synthetic images.

Splitting should be performed by batch or capture session rather than randomly across neighbouring frames. Otherwise, nearly identical images may appear on both sides of the test boundary and create an illusion of generalisation.

Economics without invented percentages

EDIH explicitly says that quantitative results are not yet available. The possible saving of several hours of manual counting per week remains an expectation, not a verified outcome. The budget should therefore be treated as a model with visible assumptions.

Suppose a laboratory performs 25 measurements per day, manual counting takes six minutes, and employees work 22 days per month: 55 hours. If a human-reviewed assistant saves four minutes on 70% of measurements, it releases about 25.7 hours. Subtract annotation, camera checks, maintenance, equipment, and mistakes.

An investment decision should use four measures:

  • operator time before and after the pilot;
  • counting and weight-estimation error on independent batches;
  • the share of frames escalated to a person because confidence is low;
  • cost per accepted measurement including maintenance.

If the operation is infrequent, a camera and assisted annotation may deliver more value than continuous model inference. If the measurement changes line settings and affects batch value, accuracy may be worth more than direct labour savings.

Risks and limitations

The primary risk is changing capture conditions. New substrate, a different lamp, lens replacement, camera height, or larva size may alter the image beyond the model's experience. Capture configuration therefore belongs in the versioned system definition rather than remaining an undocumented employee habit.

The second risk is an unreliable reference. People may also disagree when separating overlapping objects. The team should define a rule and measure annotator agreement before training. The third risk is automating action too early. Until the model has been evaluated on independent batches, it should advise rather than change production settings on its own.

Finally, an individual tool licence is not the licence for the entire solution. The Segment Anything repository uses Apache 2.0, but a company must separately verify the terms of every data set, model, library, and synthetic asset included in its build.

A practical four-week pilot

Week 1: select one measurement, define acceptable error and economic meaning, and lock camera, lighting, and the manual reference procedure.

Week 2: capture images across the condition matrix, annotate them, and reserve test batches that will not participate in training.

Week 3: train a baseline model and run it in shadow mode. The employee counts as usual, the system runs in parallel, and results are compared only after the manual answer has been recorded.

Week 4: analyse failures by slice, calculate cost per accepted measurement, and decide whether to expand the data, change the optics, retain a semi-automatic workflow, or stop the experiment.

Management takeaway

The Alpha‑Protein case demonstrates a useful order: select a measurable task, stabilise capture and data, then evaluate the model. No polished metric is needed if roughly 20 expert days reveal the decisive edge case before the line launches. The first management step is to give the process engineer 100 difficult images and agree on what a correct result means.