EAN-13 traceability: camera sampling

Purpose and operating boundary

Capture the entire declared EAN-13 label with usable bars and surrounding blank space before treating a decoder result as traceability evidence.

This tutorial defines an engineering evaluation, not a ready-to-run product certification. The current Deyi Vision public PC example covers an EAN-13 workflow on confirmed sample images. Native OCR and detection work in the engineering code must be checked against the installed runtime, bound models and job before use. A browser template does not prove browser execution: the planned OpenCV.js backend needs separate verification. Cloud recognition requires explicit approval of the image scope, provider, model and cost. A review archive is not an executable release package. Camera, firmware and driver compatibility require their own check. All worksheet values below are hypothetical; they are not Deyi Vision measurements or customer results.

Prepare the evidence

Use real print stock, curved labels and both good and damaged symbols. Declare the supported EAN-13 workflow; other symbologies and reader interfaces require separate evidence. Before reusing the capture configuration, check that the stored pixel format and active region still match the saved recipe. Record any binning, resizing or image conversion because the object scale calculated from source pixels no longer applies unchanged after those operations. Compare the archived frame with the frame passed into the first processing node. If they differ, retain both identities and explain the conversion. During a reconnect trial, distinguish a new exposure from a repeated buffered frame. Disable automatic pass-through while acquisition identity is uncertain, and retain the event that caused the mismatch rather than silently resetting the counter. Keep decoding, identity validation, print verification and unit tracking as separate records. The EAN-13 value identifies a trade item and is normally shared by multiple physical units; it is not a per-frame sequence number or a unique serial. A successful decode does not prove print-quality compliance, correct product master data or successful downstream rejection. This series uses EAN-13 as its bounded example because that is the confirmed public PC evaluation scope. Other symbologies, QR, direct-part marks and reader hardware require their own confirmed integration. The original source image must retain bars, spaces and quiet zones; a cropped display or cleaned binary image alone is insufficient failure evidence. Specify how a missing frame and an unreadable code differ in the traceability database. Begin with an acquisition record rather than a displayed preview. A preview may be resized, sharpened or reused after the input has stopped. Save the unmodified frame, image dimensions, pixel format, exposure, gain, lens setting, working distance, trigger identity and acquisition time. Include the smallest relevant feature and the largest allowed position variation in the same test. First capture a stationary sample to separate focus from motion blur; then repeat at the actual movement conditions without changing the optical geometry. Link every saved image to the physical sample or event. A missing or stale frame is an acquisition failure even when the last visible image looks good. Compare a Deyi Vision 2D camera with separately verified PC decoding against a project-confirmed smart-camera or barcode-reader route. Keep this software example within EAN-13; confirm the selected device's decoder, firmware and interface rather than assuming equivalent support. Include the complete symbol and quiet zones at every allowed label position, and test focus and exposure on the narrowest bars. Verify actual trigger readiness, result timing, digital I/O or host handshake, and request identity with the controller. Record missing capture and no-read separately; a camera category or decoded value does not prove successful physical rejection.

Procedure

1. Measure the narrowest module in source pixels and include the complete symbol and quiet zones at every permitted position.
2. Focus across label height and compare stopped and moving items with unchanged gain and lighting.
3. Calculate motion blur from object sampling and conveyor speed, then inspect bar merging on the saved original.
4. Record source ID, label orientation and actual decoder configuration; never infer compatibility from the camera connection alone.

Interpret the trial

The hypothetical scale is 0.05 mm/px. A 0.25 mm module occupies 5 px, while 1000 mm/s at 50 µs moves 1 px. These are trial values, not a GS1 resolution requirement or a decoding guarantee. Passing image geometry does not establish print verification.

Recording worksheet

s = 100 / 2000 = 0.05 mm/px
module = 0.25 / 0.05 = 5 px
blur = 1000 * 0.00005 / 0.05 = 1 px

Two engineering views

Failure diagnosis

• Bars that merge only while moving indicate blur or timing rather than an invalid identifier.
• A clipped quiet zone requires recapture or a larger field; a successful read cannot restore the missing evidence.

Acceptance and handover

Accept the declared optical range only after saved originals retain modules and complete label margins. Hand over no-read originals as well as reads, and evaluate decoder and print-quality outcomes separately.

Keep the source images, the expected decision, the exact revision and the complete result record together. Freeze the evaluation set before selecting the final parameters. If those answers are later used to tune the workflow, mark that set as development data and obtain a new independent acceptance set. Keep Review, NoResult, execution error and missing acquisition visible in the denominator; do not turn them into passes by filtering rows. Save a reproducible failure alongside the successful sample. The handover should identify who may change the recipe, how a prior approved revision is restored and which device output remains inhibited until acceptance. A software result alone does not establish that a moving physical part reached the correct destination.