What happened in the workshop

German micro-enterprise LIQRO Systems is developing coffee machines that use a liquid base rather than conventional beans or powder. Consistency matters for such a product: finding the right extraction settings takes trials, and coffee, water, and electricity used during those trials become part of production cost. The company worked with the European Digital Innovation Hub EDIH-AICS to test a narrow computer-vision task: assessing espresso extraction from an image of the crema, the foam on the drink's surface.

The published EDIH case describes the development and handover of a prototype to a young company, not a chain of cafés with proven revenue growth. The distinction matters. The measured technical result is that image segmentation fell from about 30 seconds to 0.2 seconds, while color clustering fell from six to four seconds. The source describes lower waste, higher sales, and happier customers as expected impacts, not as verified outcomes of routine operation.

The useful lesson for a small business is not that a camera can “understand taste.” The team selected an observable part of the process, controlled image capture, improved one analysis step, and left the harder business hypothesis for subsequent testing. That sequence makes for a better pilot than promising to automate “quality” all at once.

How the experiment works

The specialists first listed possible AI use cases with the company and compared their data needs and risks. They then selected an espresso-analysis method drawing on a 2024 paper by Choi and co-authors. They recorded videos and photographs of different extractions and crema appearances.

The software first separates the foam from the cup and background. With GrabCut, this step took about 30 seconds per image in the baseline approach — too slow to help adjust a machine promptly. In the EDIH prototype, Segment Anything Model reduced segmentation time to less than 0.2 seconds. The subsequent k-means algorithm grouped colors; the team proposed five color clusters and their shares for evaluation. Based on those features, the drink was assigned to under-, normal-, or over-extraction categories. Color-clustering time fell from six to four seconds.

It is easy to mistake the speed of one stage for the speed of the entire system. The source does not publish a reproducible measurement of the complete “photo to operator alert to machine adjustment” loop on production equipment. Thus the 0.2-second figure refers only to image segmentation. A robot may recognize foam instantly, but it still has to wait for a person to decide whether the drink itself is good.

What a small producer would need

A camera alone does not create a reliable quality-control system. Image capture must be repeatable: cup position, distance, angle, lighting, and the moment after preparation should be specified. The original scientific paper identifies camera angle, shadows, and reflections as significant obstacles. EDIH's lessons separately recommend collecting data only when equipment is operating, controlling lighting, and standardizing the capture location.

A minimal pilot architecture is:

  • a camera or phone photographs the cup at a defined point in the process;
  • local software rejects unusable frames and segments the crema;
  • an algorithm calculates color features and assigns a predefined category;
  • the operator sees the original image, batch parameters, and confidence alongside the category;
  • a log records the image, machine settings, human decision, and independent quality check.

Images need not necessarily be sent to an external service. They and their features can be processed on a local industrial PC or workstation near the equipment if it meets the required response time. Yet “local” does not mean maintenance-free: updates, storage, access control, and rollback still matter. No one can promise that this particular prototype will run on a given low-cost device: EDIH does not publish a complete memory, energy-use, and target-hardware test profile.

If the operator only needs to compare images from a few standard operating modes, neither an elaborate agent nor RAG nor a large language model is necessary. Test a simple fixed set of features and thresholds first. A language model might later explain deviations using an approved procedure, but it should not autonomously change temperature, dosage, or recipe.

Why crema color is not the same as taste

Optical assessment can be a useful indicator of process consistency, but it is a proxy. Crema color and structure depend on more than extraction settings: ingredients, age, roast, cup, lighting, and camera all matter. Research on espresso perception shows that crema appearance shapes consumer expectations; it does not prove that five color clusters objectively measure the taste of every drink.

Two separate hypotheses therefore need testing. First, the software reliably identifies visual categories in new images. Second, its signal helps people reduce unwanted deviations in the real process. The second requires blind tasting or an agreed internal quality standard, plus comparison of rework, ingredient use, and setup time before and after deployment. If a drink looks “right” but fails a taste check, a person should make the call.

The EDIH report does not publish an error matrix across batches, ingredients, and lighting conditions. Transfer to a different machine or input material has therefore not been demonstrated. A pilot sample should include ordinary shifts, different batches, and deliberately poor images, not only polished demonstration photos.

Economics without invented payback

The case confirms the timing of two computational stages, not the amount of money saved. A company can calculate its own effect through a short experiment. Suppose an operator spends 40 minutes per shift setting up and repeating test drinks, and an alert cuts that by ten minutes without worsening taste scores. Across 22 shifts, this frees about 3.7 hours a month. At an illustrative fully loaded labor cost of RUB 1,200 per hour, the labor-capacity effect is roughly RUB 4,400. Only ingredient savings that have actually been measured should be added.

This is a modeled calculation, not a LIQRO result. It implies an uncomfortable but useful conclusion: a small time saving may not pay for the camera, computing hardware, lighting, labeling, validation, and maintenance. The project pays back faster where rework is frequent, ingredients are expensive, and adjustment is repeated often. Elsewhere, operator training and a standardized process card may be enough. Vnutrik is, of course, willing to classify every cup; the budget may reasonably ask how many cups that actually saves.

A four-week pilot

In week one, fix one operating mode and one product line. Measure baseline setup time, repeat preparations, ingredient use, and an agreed quality score. In week two, install the camera and lighting, capture images without automated recommendations, and flag unusable frames. In week three, compare the algorithm against two responsible employees on new images not used for configuration. In week four, enable operator-only advice and measure the process again.

Agree on a stop threshold in advance. If the system frequently misses obviously poor drinks, worsens blind taste assessments, or takes more review time than it saves, do not scale it. Retain original images and human decisions to fix the cause of errors rather than merely tuning a model until the report looks good.

The LIQRO case demonstrates an appropriate first step: one observable signal, a bounded prototype, and a specific technical measurement. The next business step is to prove that the signal improves the process rather than simply appearing quickly on a screen.