Computer Vision Development: Face Recognition, OCR and Document Parsing

• Companies whose product needs to recognise people: access control, attendance, security linkage - face recognition built into their own system rather than rented from a third-party cloud API.

• Businesses with large volumes of documents: layout parsing and structuring of patents, receipts and reports, where the cost of manual entry will not come down.

• Teams that need algorithms running inside their own platform: recognition integrated as a service or SDK into existing Java or PHP systems.

• Clients whose data cannot leave the internal network: recognition must be deployed on-premises, with cameras and database in their own server room.

Two directions have real deliveries: face recognition (several projects; this page lists two representatives - a recognition platform on OpenCV and Dlib, and a recognition service on Java/Tomcat) and document intelligence (the patent layout parsing system, with OCR and layout analysis). Object detection (applications of YOLO-family models) is within the service scope. This page's rule: only what has actually been delivered is written up, and nothing we have not done is dressed up as a case.

The face recognition platform uses OpenCV and Dlib for face detection and feature extraction, shape_predictor_68_face_landmarks (the 68-point facial landmark model) for landmark localisation, an OV2710 USB camera for image capture, and a PHP backend for data management. The challenges were high-precision feature extraction and matching against a large face database - the first sets the false recognition rate, the second sets matching time. The whole pipeline runs locally with no dependence on external cloud APIs, which suits deployments where data cannot leave the internal network.

The face recognition system runs on a Java web architecture: Tomcat hosts the service, the recognition algorithm is integrated into the web application, and a partials module manages page components. The challenge was keeping the recognition service fast inside Tomcat - the web container's threading model and the algorithm's compute cost have to be tuned together. The delivery model this project shows: recognition is not a standalone demo but a service running inside the client's existing technology stack (the Java ecosystem).

The patent layout parsing system targets patent documents: beyond recognising text with OCR, it performs layout analysis and formula detection - patents mix formulas, tables and paragraphs, and one wrong layer of parsing breaks everything after it. The implementation combines Python, PHP and C/C++, uses image detection algorithms to identify layout elements, applies training data to optimise the model, converts PST to email output formats, and provides a web UI for operation. The difficulty in document intelligence is never OCR alone: understanding layout structure is what decides the quality of the structured result.

With a small face database anyone can do it; engineering skill shows once it grows. As the database goes from thousands to hundreds of thousands, matching time, memory use and incremental enrolment all need redesigning. That is exactly the face recognition platform's challenge - high-precision feature extraction controls the false recognition rate, the matching structure controls query time, and both have to hold at once. Accuracy without scale is meaningless, so at assessment please state the target database size and concurrency, and we design against the real constraints.

Why the patent layout parsing system is hard: patent layouts are complex and irregular, and formula recognition involves converting two-dimensional structures (sub- and superscripts, roots, fractions) into a linear representation. The solution uses image detection algorithms to identify layout elements and dedicated logic for formula detection. Honestly, recognition of complex formulas is never 100% - the engineering goal is keeping errors within what human review can handle, and flagging low-confidence results so proofreaders only look at the suspect parts.

The patent layout parsing system used training data to optimise its model - the general rule of vision projects: algorithm frameworks are public, data quality is private. Data work on a project includes setting labelling standards, cleaning dirty data, and feeding error cases back into retraining. Assessing a vision project's feasibility starts with the data: does it exist, how much, of what quality, and can more be obtained continuously? When the data is not good enough, we say plainly that it needs building up first, rather than signing a contract and discovering the problem later.

The patent layout parsing system uses three languages: Python for algorithms and prototyping, PHP for the web layer and C/C++ for performance-sensitive parts. The cost of a multi-language stack is added build and integration complexity; the benefit is the most suitable tool at every layer. Such trade-offs are decided at the design stage and each layer's responsibilities are documented, so whoever takes over later does not have to reverse-engineer the architectural intent from the code.

Vision running on the device rather than in the cloud is within this service: on-device inference is bound by compute and memory, and models need pruning, quantisation and adaptation to the hardware - work that connects naturally to XTELL's embedded firmware capability. On-device LLM deployment is a direction we can assess: matching model size to hardware compute varies enormously between projects, so this page invents no cases, and feasibility is checked against the specific hardware and model at assessment.

What the two recognition projects share: recognition was not delivered on its own but integrated into a larger system - the face recognition platform with a PHP data management backend, and the face recognition system inside a Java/Tomcat web application. Wrapping recognition as a callable interface or SDK and connecting it to existing account systems and business processes is the form XTELL has actually delivered. Pure algorithm research (reproducing papers, model innovation) is not what this page offers - we do engineering deployment.

1. Requirements review: provide a description of the application, sample data and the target system environment (Java, PHP or other), and we confirm the technical route and feasibility.

2. Proposal and contract: algorithm selection, system architecture and milestones are written down. Whether models, source code and SDK are delivered, and under an open or closed model, is agreed item by item in the contract. Nothing on this page constitutes a blanket commitment.

3. Development and optimisation: algorithm implementation, system integration and tuning on real data, version by version.

4. Delivery: scope follows the contract. Timeline and price are given after assessment; this page does not fix numbers.

XTELL (Shenzhen XTELL Future Technology) was founded in Shenzhen in 2016. Over the ten years since, it has delivered more than 100 projects, with clients predominantly western B2B companies. Its work covers every layer from circuit board to cloud: PCB design, FPGA, embedded firmware, Linux BSP, device interfaces, mobile apps, backends and IoT platforms.