We build camera-based visual inspection on the production line: surface defects, colour and shade variation, missing parts, label verification and dimensional checks. The work does not begin as a software installation — it begins with feasibility and sample testing.
In most factories, visual quality control is the job of one person standing at the end of the line. The method works for a long time, but it has two limits. The first is consistency: the same person cannot look with the same precision at the start and end of the day, and two different people will judge the same defect differently. The second is records: inspection by eye leaves no data behind, so nobody knows which defect occurs how often, or in which shift it increases.
Camera-based inspection can overcome both limits — but this work needs to be described honestly. What decides the success of computer vision projects is usually not the software but the quality of the image. The angle and colour of the lighting, the camera's position and resolution, the lens choice, line vibration and how the product passes in front of the camera directly determine the outcome. No model can extract good results from a badly lit image; in a well-built rig, most of the problem is already solved.
That is why we state our boundary plainly: a significant part of this work is a lighting and optics hardware job. Pan does the software and integration side, and works with a hardware partner on lighting and optics selection. We prefer to say this upfront, because in proposals that claim the whole job single-handedly, this part is usually handled last and in a hurry — and that is where the project gets stuck.
We structure the work accordingly. Feasibility comes first: whether the defect can be distinguished by camera is tested on real samples. If it cannot, we say so early and the work stops there — that is budget not spent. If it can, a sample set is collected, the rig is designed and installed on the line. This sequence prevents the project's most expensive mistake: discovering that the results fall short after the installation is already done.
Plants producing carpet, fabric, board, profiles and coatings. In these products, defects are scattered and continuous across the surface; full inspection by eye at line speed is practically impossible.
Textile, paint and plastics manufacturers where shade variation between batches turns into customer complaints. Shade variation is the inspection item where the human eye tires fastest — and where arguments start most often.
Businesses exposed to missing parts, wrong labels and faulty packaging. These checks are usually the easiest to automate and the quickest to pay off.
Manufacturers for whom the accuracy of barcodes, QR codes and label data on the product is critical. A batch shipped with the wrong label can create a bigger problem than a defective product.
Whether the defect can be distinguished by camera is tested on real defective and good samples. If the result is negative, we say so plainly. This stage is where the go/no-go decision is made, and it runs on a fixed scope.
Lighting type and angle, camera position, lens and resolution selection, and matching the product's line speed are decided together. Hardware is selected with our partner; the software side is designed around that rig.
Surface defects, colour and shade deviations, missing parts, positional drift and label errors are defined as distinct types. The acceptance limit for each type is tuned to your quality standard — your quality team sets the limit, not the model.
Measurable characteristics such as size, edge straightness, hole position and assembly alignment are checked. These checks usually deliver the most stable results, because the criterion is objective.
The decision is passed to the line's control system; the defective product is marked, diverted or reported to the operator. If a rejection mechanism exists, we connect to it. Whether the line is stopped is a rule you define.
Every decision is stored together with its image; reports show which defect is rising in which shift and which batch. This record is the one piece of hard evidence you can go back to when a customer complaint arrives.
Which defects should be caught is defined one by one, together with your quality team. This step usually reveals that the defects have no written definition — the acceptance limit lives in the master operator's judgement. Putting the definition in writing is the work's first gain.
Defective and good samples are collected, imaged under laboratory conditions, and distinguishability is tested. The result is delivered as a written feasibility report; the go/no-go decision is based on it.
The lighting and camera rig is designed together with the hardware partner and installed on the line as a pilot. During the pilot the system makes no decisions — it only observes; its output is compared with your existing inspection.
Acceptance limits and sensitivity are tuned on real production. Two opposing errors are balanced here: flagging good product as defective versus missing defective product. Your quality policy decides which is the more costly.
The decision output is connected to the line, and the operator interface and reports are opened up. The system is handed over to your team, with written guidance on how to update thresholds and how to add a new defect type.
For lighting and optics hardware selection we work with a hardware partner; we do not claim to do that part alone. The software, integration and decision side is ours. We say this upfront because this is usually where projects get stuck, and it serves the work for responsibility to be clearly placed.
We do not answer that with a guess; we answer it with a feasibility study. It is tested on real samples and the result is shared in writing. If the defect cannot be distinguished, we say so plainly and stop the work there. Projects that skip this stage and go straight to installation make the most expensive mistake there is.
It depends on the defect type and its variety; collecting enough examples of a rare defect can take time. During feasibility we determine together how many samples are needed. Sample collection appears as its own line in the project plan; hiding it produces an unrealistic schedule.
The pilot installation can usually be done without stopping production; at the start the system only observes. If a mechanical rejection mechanism is to be added, a short stop may be needed, done in a planned window. Whether the line stops during go-live is a rule you define.
There are two kinds of error: flagging good product as defective, and missing defective product. Both cannot be driven to zero at once; threshold tuning strikes a balance between them. We determine together which is more costly for you and set the threshold accordingly. Because decisions are stored with their images, later review is always possible.
A written feasibility report; an imaging rig and decision system installed on the line; defined defect types and tuned acceptance limits; an operator interface; quality records stored with their images, and batch-level defect reports. Everything produced on the software side, source code included, belongs to you.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We generate demand forecasts from order history, seasonality and stock data, and link that forecast to your production and purchasing plans. We sequence work under capacity constraints, calculate safety stock and measure how accurate the forecast actually was.
Details →We build a system that collects labour data from the shift plan to the time-and-attendance terminal, from overtime to piece-rate incentives, and prepares the file that goes to payroll matched against production records. Who has earned what is visible clearly enough that objections become unnecessary.
Details →We build a system that collects meter and field data and allocates energy to lines, machines and products. The basis for your annual declaration is ready, and a product's true energy cost stops being an estimate.
Details →Off-the-shelf CRM packages do not recognise the real sales flow of industry and export. We develop a custom CRM that talks to your ERP, modelling the long sales cycle, the sample-proforma-order chain, dealer management and quotation tracking around your own process.
Details →We develop custom payment software that unites virtual POS, digital wallet, reconciliation and invoicing flows in a single secure system, built on iyzico, PayTR and bank POS infrastructures.
Details →We build a system that shows you the true cost at quotation stage: raw material, scrap, labour, energy, tooling, packaging, freight, customs and payment-term costs gathered per product; currency and payment-term scenarios; a price band set against your target margin; and the win rate of past quotations.
Details →
