What Is Image Recognition?
Image recognition is software automatically determining what is in a photo or video frame. Computer vision is the broader field: extracting usable data such as classes, locations, measurements, text or codes from images. Pattern recognition is the wider family of methods for finding regularities in data and underpins image recognition. At Hatson Tech we turn these methods into software a business can use, connecting images from cameras, scanners or existing archives to a decision or a record.
Which Vision Task Fits Your Problem?
"Image recognition" is not a single technique. Choosing the right task sets data, labelling and acceptance testing needs from the start.
| Task | What it produces | Typical use |
|---|---|---|
| Classification | One label for the whole image | Is the product good or defective, what type of document is this |
| Object detection | Location (box) and class of objects | Counting products on a shelf, finding parts on a line, protective equipment checks |
| Segmentation | Pixel-level region mask | Measuring the area of defects such as scratches or stains |
| OCR and document field extraction | Text and structured fields | Reading invoices, delivery notes, forms, labels |
| Barcode and QR code reading | Code content | Reading codes in difficult light, angles or on damaged labels |
| Anomaly detection | A "different from normal" flag | Quality control where defect examples are scarce |
For barcode reading, standard scanners are enough in most cases; computer vision adds value when the code's location is unknown, several codes appear in one frame, or labels are damaged. For fixed printed documents, standard OCR may be sufficient; multimodal models help interpret variable documents, but their outputs must be checked against the source image. See our multimodal AI guide for the strengths and limits of these models.
Deep Learning Is Not Always Needed
Some problems are solved more cheaply and predictably with classical image processing and pattern recognition. Checking the dimensions of a part held in a fixed position under controlled lighting, or catching an obvious colour difference, may only need thresholding, edge detection and template matching. These methods work with little data and their decisions are easy to explain. As imaging conditions vary, objects diversify and defects become fine-grained, learned models gain the advantage. Before development we compare these options against latency, privacy and maintenance requirements and recommend the simplest method that does the job.
What the Service Includes
- Problem definition, task selection and agreeing the cost of each error type.
- Assessment of cameras, lighting and capture conditions, and a data collection plan where needed.
- A labelling guide, the labelling process and its quality control.
- Adapting a pre-trained model or training a custom one.
- An inference service running on edge devices, on-premises servers or in the cloud.
- Integration of results into your existing application, PLC, ERP or data pipeline.
- Post-launch monitoring, a correction loop and retraining.
Data and Labelling Needs
Before choosing a model, we review representative images from the real camera or scanner. Lighting, angle, motion blur, resolution, rare defect types and changing document templates can decide the result. The data must cover difficult cases, not only clean examples. Label consistency matters as much as volume: if two people label the same image differently, a model cannot be expected to be consistent. So before labelling starts, we settle how borderline examples are labelled in a written guide. For the broader picture, see our data readiness guide.
Edge or Cloud?
- Edge device: Suitable when low latency is required, connectivity is unreliable, or images must not leave the site; hardware and model size impose limits.
- On-premises server: Preferred when several cameras are processed centrally and data must stay on the corporate network.
- Cloud: Offers flexibility for batch-processed documents and images, variable load and work where latency is not critical.
For images containing personal data (faces, licence plates, ID documents), retention periods, masking and access rules are part of this decision; our data privacy guide summarises the key questions.
From Pilot to a Working System
- Define the decision: What will the system find or extract, and who acts on the result?
- Collect data: Prepare representative examples that reflect real conditions and a separate held-out test set.
- Write acceptance criteria: Set thresholds for missed items, false alarms, speed and human review load.
- Run the pilot: Report results separately by defect type, product type and operating condition.
- Integrate: Connect the output to your existing application or data flow, with a human review path for uncertain results.
- Monitor: After launch, track data drift and correction rates.
In production inspection, acceptance testing should report results by defect type and operating condition rather than a single accuracy number. Our visual quality control guide covers camera placement, false alarms and review workflow in more detail, and our pilot to production guide covers the move to live use.
How Acceptance Testing Is Set Up
To say an image recognition system "works", what will be measured has to be written down at the start. The main points we check in acceptance testing are:
- A separate test set: Images never used in training, taken on different days, shifts and conditions.
- Measurement by error type: A missed defect and a false alarm do not cost the same; they are measured separately with separate thresholds.
- Results by subgroup: Separate results by product type, defect type, lighting condition or document template, which exposes systems that look good on average but are weak in one subgroup.
- Speed and resource use: Processing time per frame against line speed or workload.
- Human review load: The share of examples the system is unsure about and routes to a person.
For a broader framework on model evaluation, see our AI evaluation guide.
What Drives Cost and Timeline?
- The task type and number of classes; how small and fine-grained the defects or objects are.
- Whether suitable data already exists and how much labelling is needed.
- Whether cameras and lighting must be installed or changed.
- Latency and throughput expectations, and edge hardware limits.
- Systems to integrate and the need for a human review screen.
- Privacy and hosting requirements.
What We Need From You
For a first conversation, sample images captured in real conditions, a short summary of today's manual process and a list of the most expensive errors are enough. As the project progresses, we need a domain expert to decide labelling rules, access to the site or camera feeds, and users to take part in acceptance testing.