Service detail

Computer Vision Systems Development

Pipelines that turn what a camera or scanner sees into a record you can query. The images stay on site; only the result leaves.

Done Dynamics builds computer vision systems: document extraction, production-line quality control, camera analytics and plate recognition. We combine classical computer vision with models that read images, and deploy on an edge device or a server inside the building. The result: the video twenty cameras produce never leaves the network — what leaves is the record made from it.

Four families of work

Reading, counting, judging, watching

We separate these four at the start of every project, because their costs are nothing alike.

Reading

Structured fields from invoices, delivery notes, identity documents, forms and technical drawings. A hundred suppliers send a hundred layouts; we build a pipeline that does not depend on templates.

Counting

How many items on the shelf, how many pallets came off the truck, how many parts per minute on the belt, how many millimetres long. In a controlled scene, classical methods answer in milliseconds.

Judging

Defective part, unacceptable weld, an object that should not be there. The hardest family — consistency is only possible once the decision boundary has been written down.

Watching

Zone violations, safety equipment checks, vehicle and plate tracking, occupancy measurement. Producing results instead of recordings keeps the retention burden low.

2 minutes · 4 questions

What would computer vision earn you on your floor?

Four questions to see whether there is a real use case. If there is not, we say so.

Do you have visual work checked by eye — documents, products, camera footage?

Question 1 / 4

Do you have visual work checked by eye — documents, products, camera footage?

How we build it

Images everywhere, data nowhere

The cameras run but nobody watches; the archive is full but cannot be searched. The job is closing that gap, not adding one more screen.

  • Images stay on site

    Deployment runs on an edge device or a server in the building. What leaves the network is not video but a result record of a few hundred bytes.

  • Measure first, deploy second

    A one to two week accuracy study reports what accuracy this job can reach with this method. If it falls short, the project stops there.

  • Classical methods and models together

    Classical computer vision is faster and cheaper in a controlled scene; a model wins in an uncontrolled one. Most pipelines end up with both layers.

  • The error balance is your call

    Passing a defect is not the same as rejecting a good part. The threshold is a business decision, set together and left adjustable.

  • Drift is monitored

    Lighting shifts with the season, a lens gathers dust, packaging changes. Periodic accuracy checks are part of maintenance.

  • Compliance built in

    Where staff appear in frame, notice obligations, retention period and access rights are defined with the deployment.

Use cases

Pipelines we have built on site

From accounting documents to the production belt, from warehouse counting to the front gate.

Invoice and Delivery Note Reading

From scanned page to accounting record: field extraction, total and tax consistency checks, uncertain records handed to a person.

Production Line Inspection

Where defects are rare, the system learns what normal looks like rather than what failure looks like. Every decision is stored with the frame behind it.

Warehouse and Dispatch Counting

Pallet, carton and label counting; missing-item detection before dispatch and automatic writing into the warehouse system.

Plate and Vehicle Tracking

Plate recognition at the gate, entry and exit records and barrier integration — the record stays on site.

Workplace Safety Monitoring

Helmet, vest and restricted-zone violation detection. The goal is an alert at the moment of the event, not tracking individuals.

Archive Digitisation

Turning a scanned but unsearchable archive into something queryable, classified and labelled by document type.

Anatomy of a pipeline

The model alone is not enough

Most of the accuracy is won before and after the model: preparation, type detection and consistency validation.

  • Image preparation: deskewing, noise removal and cropping the region of interest — skip it and the accuracy of every later step drops.
  • Determining the document or object type; searching for every field everywhere is both slow and error-prone.
  • Field extraction with a separate confidence value produced per field.
  • Consistency validation: do the line items sum to the total, is the date in a plausible range, does the tax rate hold.
  • Automatic routing of anything below the confidence threshold to a person.
  • Writing the result into the existing system and linking it back to its source — the document or the frame.
  • Periodic measurement against a held-out validation set, with drift tracked over time.
Our own measurements

The vision tower costs memory, not speed

We measured four vision-capable builds on the same machine. Generation throughput is almost identical to the text-only builds; the difference shows up in peak memory. What decides whether a machine can process images is memory rather than the processor — the first table we look at when planning hardware.

Build Generation Peak memory
4-bit38.9 tok/s19.2 GB
6-bit29.2 tok/s27.0 GB
8-bit23.1 tok/s34.7 GB
bf1613.2 tok/s55.8 GB

Vision-capable builds; Mac Studio M3 Ultra, 512 GB unified memory, a multimodal prompt. Single run — an order-of-magnitude guide, not a benchmark.

Process

Five stages from samples to production

Measurement comes before deployment; if the result falls short, the project stops there.

  1. 01

    Data Collection

    A sample from the real distribution: blurred, rotated and badly lit frames included. A study built on clean examples misleads in production.

  2. 02

    Accuracy Study

    A measurable result before any deployment. One to two weeks, ending in a report. If it falls short, those are the cheapest two weeks you will spend.

  3. 03

    Site Deployment

    Camera placement, lighting and processing hardware. The intervention that saves the most time is usually not software but a correctly placed lamp.

  4. 04

    Integration

    Where the result is written, who gets alerted, how long the record is kept. A system on its own screen goes unused.

  5. 05

    Monitoring and Maintenance

    Periodic accuracy checks, camera maintenance, tuning as new case types arrive, and reporting.

Commercial model

Accuracy report first, investment second

In vision projects, cameras, lighting and mounting are a real hardware investment. So we split the work in two: a fixed-price accuracy study first, then a deployment contract based on its result. The report states what accuracy this job can reach with this method, and the hardware decision follows that figure. Maintenance is written as a separate line, because without periodic accuracy checks a system degrades quietly over time.

Ready for your next software project?

Book a free 30-minute discovery call with our team.

Certifications

Our network and cyber security work is carried out by a team holding internationally recognised Cisco certification.

Cisco CyberOps Associate badge

Cisco CyberOps Associate

Issued by Cisco · Holder: Devrim Tunçer

A certification covering security operations centre (SOC) competency: security monitoring, incident response and analysis of network attacks. It is the foundation we rely on for intrusion detection, log correlation and post-incident response work.

Cisco CCNA Training

expired

Cisco training certificate · completed January 2023

Covers networking fundamentals: routing, switching, IP addressing and network security. The knowledge base we draw on for enterprise network setup and segmentation.

Computer vision systems: turning what the camera sees into a record

Images everywhere, data nowhere

Twenty cameras in a plant produce footage almost none of which is ever watched. Delivery notes are scanned into an archive that cannot be searched. Forms are filled in on paper, then typed into a system by hand. All three share one gap: there are images, and there is no data. Computer vision systems close that gap — turning what a camera or scanner sees into a record you can query.

This work used to be expensive and brittle: a separate model per use case, thousands of labelled examples, and a rebuild every time the lighting changed. Models that read images have changed that picture. Many jobs now start without training from scratch, which pulled the entry cost of these projects down sharply.

Three different jobs: reading, counting, judging

Reading means extracting structured fields from a document — amount, date, tax number, line items. The difficulty is not the document but the variety: a hundred suppliers send a hundred layouts, which is why template-based tools needed maintenance with every new supplier. Counting and measuring is where classical computer vision often still wins: fixed camera, fixed lighting, a result in milliseconds at almost no cost.

Judging is the hard family — is this part defective, is this weld acceptable. The decision boundary is frequently unclear even between two human inspectors, and where that is true, consistency from a system is only possible once the standard has been written down. We separate these three families at the start of every project because their costs are nothing alike.

Where the image is processed

Processing at the edge is best for bandwidth and latency: the footage never reaches the network, only a few hundred bytes of result do. In a plant streaming twenty cameras, that difference decides whether a network investment is needed at all — at the cost of a small device that can only host a small model.

Processing on a server inside the building is the middle path and our default: more capable hardware, a larger model, and the images still inside your network. For camera recordings that contain personal data, that is also the architecture easiest to defend under GDPR and KVKK. Processing in a remote datacentre is the most flexible option and the one most often ruled out first when workplace cameras, patient documents or identity photos are involved.

Accuracy: why one number is never enough

A claim of 95% accuracy says nothing on its own. Which five percent is wrong is the real question. On an inspection line, passing a defective part is not the same as rejecting a good one: the first reaches your customer, the second only costs money. Where that balance sits is a business decision, set through a technical threshold.

Measuring at all requires a held-out validation set: real examples with their correct answers, prepared before deployment and re-run after every change. Drift is the quiet risk — lighting shifts with the season, a lens gathers dust, a supplier changes its packaging. Without periodic re-measurement the system degrades silently, and the first to notice is usually the customer.

From samples to production

The first step is always data, and it has to be the real distribution rather than the easy cases — blurred, rotated and badly lit examples belong in the sample, because production will send them. The second step is an accuracy study before any deployment: one to two weeks, ending in a report that says what accuracy this job can reach with this method. If it falls short, the project stops there, and those are the cheapest two weeks you will spend.

Then comes deployment — hardware, camera placement, lighting — and integration. The intervention that saves the most time on site is usually not software but a correctly placed lamp. And a system that lives on its own screen goes unused; it earns its keep once it sits inside the existing workflow.

Frequently asked questions

We have no labelled data — can we still start?
In most cases yes. Models that read images can work from a description of what you are looking for, without training from scratch. You still need a small hand-prepared validation set to measure accuracy — usually between fifty and two hundred examples.
Will the images leave our site?
That is your choice, but our default is that they do not. Deployed at the edge or on a server in the building, the footage never leaves the network and only a result record is produced.
Can our existing cameras be used?
Usually, but it needs checking. Resolution, frame rate, angle and lighting all affect the result. The site survey reports whether the current setup is sufficient and what would need to change.
What happens when the system is wrong?
A confidence threshold sends uncertain cases to a person rather than guessing, and every human correction is logged so that clusters of error can be found and fixed.
How soon do we see a result?
One to two weeks for the accuracy study, which ends in a measured number rather than a demo. Deployment and integration run three to eight weeks depending on scope.
Can it run on live video?
Yes, but the target frame rate has to be agreed up front. A few frames per second runs on an edge device; high-rate lines use small purpose-trained networks and classical computer vision instead.
Our staff appear in the footage — is that a problem?
Not a blocker, but a topic to manage: notice obligations, retention period and access rights have to be defined. Keeping the footage inside the site, and storing only the result where a frame is not needed, are the two measures that work in practice.