Software barcode decode in your own camera app: build or buy a reader

A camera and a decode library can read anything a dedicated scanner can, which makes the software route tempting right up to the licence wall: decode engines for embedding are not distributed as downloads. This guide is for engineers choosing between compiling a licensed decode engine into their own camera app and mounting a dedicated fixed code reader on the line. You will work out the pixels a barcode needs, size the field of view and the lens, estimate the read rate your host sustains, and finish with a decision per station: phone app, smart camera, fixed reader or handheld. Every calculation is shown with its arithmetic, so you can re-run it with your own label width and line speed.

Where do you get a decode engine licence for Android and iOS?

You do not download it: commercial decode engines are delivered as a build compiled for your exact host CPU, OS and camera interface, and you get that build through the engine vendor's OEM sales channel after a signed licence agreement.

That is not gatekeeping for its own sake. The engine ships as a native library tuned to an instruction set — an ARM64 Android build and an x86-64 Windows build are different artefacts from the same engine — and the keys activate per device or per platform, so the vendor needs your host specification before anything compiles. Bring four things to the first conversation: CPU architecture, OS version, the camera API you will pull frames from, and the read volume you expect. The channel returns a licensed library, sample integration code and activation keys, and it can issue an evaluation build on the same target so you measure before you commit. Android and iOS are quoted as separate platform builds; embedded Linux and Windows hosts are quoted separately again.

Decision: ask for the evaluation build on your production device, not a desktop PC — decode speed moves with the compile target, and your measurement sizes the licence order, not the brochure.

What does building decode into your own app really take?

Budget the effort in integration weeks, not downloads: you compile the licensed library for each host, wire camera frames in as raw pixels, and tune per symbology, which for a two-platform Android and iOS rollout means two builds, two licence pools and one shared tuning pass.

Three integration facts dominate the schedule. First, the decoder wants pixel buffers: hand it the frame straight from the camera — the QR code decoding in .NET guide shows the pattern for a desktop stack — and never a saved file wrapper that re-encodes the image on the way in. Second, keep the buffer alive until the decode call returns, because engines read asynchronously; the buffer-decoding guide covers the failure mode and the fix. Third, build a test matrix of your real labels rotated, defocused and glare-struck, and score each run with a read-confidence measure rather than pass/fail, which is how the read-confidence guide judges whether a decode is trustworthy.

The licence arithmetic you control: one key per activated device on each platform you ship. Before spending the engineering time, apply the same evaluation you would to any plant software — this build-versus-buy checklist for shop-floor software is the discipline, pointed at code you would own.

Decision: build when the app is the product and reads are operator-paced; stop and buy hardware when a station must hold a cycle time.

How many pixels does a barcode need to decode?

Design for three pixels across the narrowest bar or module: a 0.25 mm Code 128 narrow bar then needs 0.75 mm of image per module, and that number drives the sensor choice before anything else on the station.

The basis: decoders locate bar edges in the pixel profile, and one pixel per module collapses as soon as print gain closes a bar or the code tilts off axis. Two pixels is the floor, three is the working target, and curved or flexible packaging wants four to five. The Code 128 module-size guide walks the same logic from the label side.

Worked example: a Code 128 label with a 0.25 mm narrow bar in a 40 mm wide field of view spans 40 / 0.25 = 160 modules, so the sensor needs 160 × 3 = 480 pixels of width. Give the label ±10 mm of position tolerance and the field grows to 60 mm, which is 240 modules and 720 pixels. Past roughly six pixels per module the extra resolution mostly costs decode time rather than reads, so 720 pixels is a floor with a ceiling close behind it.

Decision: set the pixel floor from your narrowest module and tolerance; any 1.3 MP-or-larger reader sensor clears it, so the field of view and the rate pick the part, not the sensor.

What field of view and lens does the label set?

Size the field of view to the label plus its position tolerance, then let working distance and sensor pick the lens: a 40 mm label with ±10 mm tolerance needs a 60 mm field, which at 150 mm working distance on a 1/1.7-inch sensor means a lens near 18.5 mm.

X is the narrow bar or module width and WD the working distance. Run the inverse example through: 150 mm × 7.4 mm / 60 mm = 18.5 mm, so an 18 mm lens is the pick, while the same sensor behind an 8 mm lens opens a 139 mm field for wide labels or loose tolerance.

Now the reader version of the same station. The LS-CRD-0028 pairs a 2560 x 2048 global-shutter sensor with an 8 mm lens and is rated 30 fps and 60 codes/s. A 1/1.7-inch optical format is about 7.4 mm wide, so at 150 mm working distance the field is about 150 × 7.4 / 8 = 139 mm. The 0.25 mm code then spans 139 / 0.25 = 556 modules, and 2560 pixels over 556 modules gives 4.6 pixels per module — 50% margin above the three-pixel target, which you spend on tilt, motion blur and print gain.

Decision: fix the field from label plus tolerance, compute the lens from it, then check pixels per module; if the number lands under 3, tighten the field or lengthen the lens and run the calculation again.

When does decode software in your own host win?

Build the decode into your own app when the host already exists and the read is occasional: a phone in a technician's hand, a panel PC at a kiosk, an HMI station reading one label per operator action, where one licensed engine per device beats adding dedicated hardware.

The rate check is one measurement and one division. Measure the decode pass on the target device with your worst label — say 15 ms. Sustained reads per second are the smaller of the camera frame rate and 1000 / decode time: a 30 fps camera frames every 33.3 ms, so a 15 ms decode holds 30 reads/s, while a 40 ms decode caps the loop at 1000 / 40 = 25 reads/s however fast the camera runs. Operator-paced stations never approach either number, which is why phones and kiosks are the natural home for this route. For the phone case, the Android preview-loop guide shows the full pattern — your own camera frames into a decoder, no scanner app in between. On a bench the same engine runs on an x86 smart camera, with the LS-SMC-0017 listed on an X86 platform with an 8.8 MP global-shutter sensor, or on a PC-class host such as the industrial panel PCs already running the bench software.

The middle case is a station that needs programmed logic, integrated lighting and no PC box: smart cameras decode on the device and pass the string to the PLC over Ethernet. The LS-SMC-0063 is that shape of part: a 1.6 MP smart camera shooting 60 fps through a 16 mm lens with integrated white light over GigE.

When the label needs colour separation — red print on kraft board, a code over a coloured fill — the MV-SC3050XC-16M-ATN-H is a 5 MP colour vision sensor on Fast Ethernet that decodes on the device.

Decision: build on hosts you already own when reads are operator-paced or below a few per second; the engine licence is the only hardware you add.

When should you buy a dedicated fixed code reader instead?

Buy a dedicated reader for any fixed station with a trigger and a cycle time to hold: the rating that matters prints in codes per second — 60 codes/s at 30 fps on the reader below — and the strobe and trigger come with the housing, not as your integration project.

What the hardware adds: light matched to the optics and strobed, so short exposures come without gain; a hardware trigger that fires per part; decode firmware tuned on production image libraries; and a housing built for the line. The fixed code readers shop spans compact M12 units to high-resolution logistics readers, and the MV-ID3013PM-12M-WBN is the compact form of that package: a 1.3 MP global-shutter reader with a 12 mm lens on an M12 mount and Fast Ethernet.

Wire the station in this order. Choose the trigger mode — sensor, serial or free-run, as the trigger-modes guide sets out — because it decides the cabling. Agree the handshake, where the client-or-listener guide sorts out which side opens the TCP connection, and store the string in agreed PLC memory. Run the first-connection and readback checks before the panel closes. Quality gets the picture too: readers return the image beside the string, and the archiving guide covers where it goes next. Rate, honestly: 40 parts/min with one code each is 40 / 60 = 0.67 reads/s and any triggered reader clears it; a continuous web at line speed is where the codes/s rating earns its keep. More reader-to-PLC wiring sits in the code-reading guides.

Decision: buy the reader whenever the station has a trigger, a cycle time and an owner on the line; the strobe, the trigger input and the rated codes-per-second are what general-purpose software re-creates only with effort.

Do manual stations still justify a handheld reader?

Keep a handheld for stations a person visits: rework benches, receiving, tool crib check-out, where the operator aims the reader and the string lands in the same flow as the keystroke, which is the job a 1.0 MP USB 2.0 handheld such as the LS-HCR-0001 covers.

Same engine class, different job. A handheld aims where the operator looks, fires from the grip, and injects the string through USB, serial or Ethernet — the scanner input guide lists the paths — while a phone app wins only when the app itself is the workflow and the phone is already in the hand. Aim and trigger feel like details until an operator makes two thousand scans a shift; then grip, aim and instant feedback are what keep the station's pace.

Decision: equip those stations from the handheld code readers shop; embed the engine in your app only where the app is the workflow.

What do you check before you order?

Order against the station's numbers, not the catalogue's: the worst label, the fastest part rate and the PLC handshake decide the part, and every item below is checkable in an afternoon with a sample label and a stopwatch.

• The worst label, in hand. Decode margin lives on the lowest-grade, smallest-module, lowest-contrast label you ship; test that one, not a fresh chart, because every number above assumes it.
• Pixels per module at the final field. Hold 3 to 6 with the field formula above: under 3 fails on tilt and print gain, far above 6 spends decode time on pixels no decoder uses.
• Rate against rating. Parts per minute times codes per part sets the reader side (40 parts/min × 1 code = 0.67 reads/s); measured decode milliseconds set the app side.
• A trigger plan before the bracket. Sensor, serial or free-run changes cabling and light duty cycle; deciding it after mounting reworks both.
• Licence targets on one sheet. CPU architecture, OS version, camera API and key count per platform, so the OEM conversation closes in one pass.
• A 30° tilt for marked metal. Printed labels read face-on; direct part marks read best about 30° off the code normal, where the glare lobe leaves the lens.
• The PLC handshake on paper. String length, terminator and who clears the buffer between reads; the ASCII storage guide makes the agreement short.

Bring the label, the rate and the host spec and we will scope the route with you; the camera side starts fastest in the configurator below, and the camera finder filters readers and cameras by resolution and interface.