On-device recognition means the interpretation of the image happens inside the camera itself, so the reading is produced at the instrument rather than by a server that has been sent the pictures.
Need product specifications, use cases or references?
Call +86 130 4890 6506 to discuss selection and site conditions Email usA camera pointed at a gauge has to turn a picture of a dial into a number. There are two places that step can happen.
On a server. The camera streams images or video to a central system, and the recognition runs there. This concentrates the processing, and it means the images exist somewhere central — which is sometimes wanted and sometimes not.
On the device. Recognition runs locally, on the camera's own processor, and the device makes the resulting reading available over its data interface for a collector to poll. The image is an intermediate step inside the device; it does not have to leave it.
The difference is not primarily about processing power. It is about what crosses the network boundary:
A practical consequence worth noting: on-device recognition also means the recognition library is a property of the device, which is why "library upgrade" is a maintenance activity rather than a server deployment.
⚠️ What this page is and is not claiming. It describes the difference between the two architectures. It is not a statement about what any particular device outputs beyond its documented behaviour: the camera documented in this site samples and recognises locally and makes readings available over its documented data interface. Whether a given device can also output images or a video stream is a separate capability question — not documented here, and not to be assumed in either direction. Ask us what the device makes available over its documented interface, and we will say which parts are documented and which we still have to confirm.
Edge computing is the broader idea — processing placed near where data is produced rather than in a central facility. On-device recognition is the specific case where the processing sits inside the sensing device itself, with no separate edge box in between. (In our own offering each reading device observes its own instrument — the edge box below is the general architecture being contrasted, not our form factor.)
An edge box or gateway is an intermediate: it sits near the instruments and runs the processing for several of them. It is closer than a server, but it is still a separate piece of equipment to power, house and maintain. Here it is the general aggregating case being contrasted, not our form factor: our own edge computing box is itself a reading device for its own instrument.
Cloud or server-side video analytics is the centralised model. It suits cases where many streams are correlated together, or where the operator already runs that infrastructure.
Reading a dial is image analysis — detecting the needle and interpreting it against the scale; on a digital display the same step is character recognition (OCR). On-device recognition is where that step runs, not what the step is.
"On-device means less capable." It means a fixed processing budget on the device rather than an elastic one on a server. For a bounded task like reading a gauge face, that is usually a good trade — the task does not become easier with more servers.
"The camera must stream video to be useful." It does not have to. What a monitoring or energy platform consumes is the reading, made available over the device's data interface to be collected. Whether images are additionally available is a separate question — useful for a human checking a disputed value, but not what makes the reading usable.
"It still sends images when it is unsure." That is a design choice, not a property of the term. Whether a device escalates a low-confidence image, and to where, is worth asking us about directly, because it determines what actually leaves the site — and it is one of the points we have to confirm rather than assert.
"Cloud recognition is more accurate." Accuracy depends on the model and the data, not on where the computation runs. A server can run a larger model on the same image, while a device works to a fixed budget — that is the real trade, not a better view of the dial.
"Fewer servers means fewer things to maintain." Usually true, but it moves the maintenance to the devices: recognition libraries have to be updated on each one. That is a real operational cost and worth asking about.
We can provide: selection guidance · integration and network design guidance · product documentation on request
Call +86 130 4890 6506 to discuss selection and site conditions Email usTell us your site conditions and what the data needs to connect to — we reply within one business day.
On-device recognition fits when the readings are the product and the images are not — which is the usual case for instrument monitoring. It particularly suits sites with many instruments, constrained networks, or a preference for keeping images on site, and it does not depend on a server being reachable in order to recognise a reading.
It fits less well when the images themselves are wanted centrally — for operator review, for evidence, or for correlating many views — or when the recognition task is large enough that a device cannot host it. In those cases the centralised model is the right one, and the question becomes how to get the images there acceptably.
That the camera itself turns the image of the instrument face into a reading. The recognition step happens inside the device, so the number is produced at the instrument rather than by a system that has been sent the pictures.
Recognising the reading does not require sending images anywhere — the recognition happens on the device. Whether a given device also offers images, and whether any are retained or escalated, is a capability and configuration question worth asking us directly, because it determines what data leaves the site. We will tell you what the documentation covers and where the open questions are.
Accuracy comes from the model and the data behind it, not from where the processing is hosted. A server can run a larger model on the same image; a device works to a fixed budget. That is the trade, not a better view of the dial.
Recognition itself is unaffected, because it does not depend on a server being reachable. What an outage affects is delivery of the readings. Whether readings taken during the outage are held for later delivery or lost is device-specific — ask us, because it changes how much history you would actually have after an incident.
As a device-level maintenance activity, since the library lives on the device. That is a genuine operational difference from server-side recognition, where an update is deployed once centrally.
It is one form of it. Edge computing places processing near the data; on-device recognition places it inside the sensing device, without a separate edge box in between. In our own offering each reading device observes its own instrument.
Yes — the readings have to go somewhere. The device makes them available over a serial or Ethernet interface for polling, and whatever already collects data on site can take them from there.
If you need to know what data would actually leave your site, ask us what the device makes available over its documented interface. We will tell you what is documented and what we still have to confirm — and we will not guess at the rest.
Call +86 130 4890 6506 · export@rebe-tec.cn