Rotated barcode result points: map orientation back to the image

A decoder that finds a barcode in a turned frame reports what it saw — and that is not your image. The overlay lands beside the code, the archive crop misses, and the robot moves to the wrong pixel. The bug is common to any decoder build that auto-rotates internally: the decoded string is right, but the result points belong to a 90, 180 or 270 degree frame, not to the original image. The fix is one pass of arithmetic: read the orientation value the result metadata carries, invert that rotation about the frame centre, and every point lands back on the code. Here you get the test that detects the rotation, the formula with its centre trap, a worked example on a 2560 x 2048 frame, and the checks that prove the correction before it reaches the line.

Why do barcode result points land in the wrong place on the original image?

The points are correct but expressed in the decoder's internal frame: when auto-rotate turns the image by 90, 180 or 270 degrees to find the code, every result point comes back in that rotated frame, so your overlay lands somewhere else on the original image.

The decoder's contract is the string, not the geometry. To read a code at any angle, an auto-rotate path turns the frame, decodes the turned copy, and returns the hit points exactly as that pass saw them. Nothing in the result announces the swap: the points look plausible, fall inside the image, and simply belong to a different picture of the same scene.

It bites wherever the coordinates are used downstream: result rectangles drawn on operator views, archive crops around the hit, pass/fail geometry such as box position or tilt, and any hand-off to a robot or PLC. String-only logging never notices, which is why the bug passes integration tests and surfaces in the first week on the line. The trap also exists where the decode runs on the device itself — smart cameras and fixed code readers decode on board, and their result points obey the same rule.

A different fault looks similar but shifts for another reason: if the box is off by the same amount on every part, upright images included, the cause is reference or indexing drift, covered in barcode detection coordinate indexing: prevent overlay errors.

How do you tell that the decoder rotated the image?

Read the result metadata first: if the result carries an orientation entry and its value is 90, 180 or 270 degrees, the decoder found the code in a rotated frame, and every point it returned needs the inverse rotation before you draw anything.

The orientation entry is the decoder's own signal, so read it before drawing. A result without the entry decoded the frame as it arrived, and its points are already image coordinates. The geometry confirms the diagnosis: at 180 degrees the drawn box sits on the code but rotated with it, and at 90 and 270 degrees the box lands in a mirrored position, because the axes traded places.

A one-minute experiment settles the convention for your build: draw a barcode at a known spot in a test image, decode, rotate the image by a known angle, decode again, and compare where the points fall against where the code sits. Guessing from the points themselves — for a 1D code the two end points swap left and right at 180 degrees — works only for horizontal codes, so treat the metadata as the source and the geometry as confirmation.

What does the orientation value in the result metadata mean?

The orientation value is the rotation the decoder applied to the image before it found the code, reported in degrees and always a multiple of 90, so the values you will actually see are 90, 180 and 270.

Libraries expose it as an entry in the result metadata, commonly keyed ORIENTATION, alongside the decoded text and the raw points. In image coordinates — x right, y down — treat the value as the clockwise rotation that produced the frame your points live in: 90 means the decoder turned the content a quarter turn clockwise, so the fix turns the points a quarter turn back.

The value is an integer number of degrees, never an arbitrary angle. Decoders rotate by quarter turns mainly for 1D symbologies, which must run along the scan direction to decode; 2D codes carry finder patterns and are usually found at any angle without the extra passes. That is why the correction needs no general trigonometry in practice — three of the four cases collapse to axis swaps and mirrors.

Which formula maps rotated result points back to the original image?

The correction is a rotation by the inverse of the orientation angle about the frame centre, with one trap: for 90 and 270 degrees the frame the points live in has the original's width and height swapped, so it has a centre of its own.

Image y grows downward, so in these axes a positive angle turns clockwise on screen; the minus signs inside the trig functions apply the inverse rotation. The frame sizes follow one rule: at 90 and 270 degrees, W' = H and H' = W; at 180 degrees, W' = W and H' = H, and both centres coincide.

Because every sine and cosine is 0, 1 or -1 here, the general formula collapses exactly, and the collapsed forms are what you should ship: three branches, no trig call at runtime.

If your build reports the counter-clockwise angle, swap the 90 and 270 rows; the 180 row never changes, because a half turn is its own inverse.

What does the correction look like with real numbers?

Work the correction on a 2560 x 2048 frame with the orientation reported as 90: two raw points come back in a 2048 x 2560 frame, and a few lines of arithmetic put each point back on the code, exactly where the label sits in the original image.

The frame is the working size of a real fixed reader: the LS-CRD-0028 captures 2560 x 2048 frames.

Set the scene: original frame W = 2560, H = 2048, centre (cx, cy) = (1280, 1024); orientation 90, so the points come back in a 2048 x 2560 frame with centre (cx', cy') = (1024, 1280).

First point, raw: (x', y') = (944, 1244). Offsets from the rotated centre: dx = 944 - 1024 = -80 and dy = 1244 - 1280 = -36. The inverse angle is -90 degrees, with cos = 0 and sin = -1, so:

• x = 1280 + (-80)·0 - (-36)·(-1) = 1280 - 36 = 1244
• y = 1024 + (-80)·(-1) + (-36)·0 = 1024 + 80 = 1104

Corrected point: (1244, 1104). The collapsed 90 degree row agrees with no extra work: x = y' = 1244, and y = H - x' = 2048 - 944 = 1104.

Second point, raw: (1408, 1492). Here dx = 384 and dy = 212, so x = 1280 + 212 = 1492 and y = 1024 - 384 = 640, giving (1492, 640). Both corrected points sit inside the 2560 x 2048 frame.

Distance check: the raw pair spans 464 px by 248 px, length sqrt(464464 + 248248) = sqrt(276800), about 526.1 px; the corrected pair spans 248 px by -464 px, the same 526.1 px. A rotation preserves lengths, so any mismatch means a slipped sign or the wrong centre.

How do you check the corrected points before trusting them?

Three checks settle it in seconds: both corrected coordinates must fall inside the frame, the distance between two points must survive the rotation unchanged, and a drawn rectangle must sit on the code in a live preview, not beside it.

The bounds check is one comparison per point, 0 to W in x and 0 to H in y: a swapped centre pushes points outside the frame or bunches them into the mirrored corner, and the test catches it immediately. The distance check needs two points, which every 1D result provides as the two ends of the code; compute the length before and after and require agreement. The preview check closes it out: draw the corrected rectangle on a live view and present parts at every angle the cell allows — the box must track the code, not the orientation. A continuous preview harness like the one in continuous barcode detection with a live preview window makes this a five-minute bench test.

With points you can trust in image coordinates, the next mapping — pixels to robot or PLC offsets, with units — is its own step, laid out in apply camera XY offsets in a robot program with unit conversion.

When should you skip auto-rotate and pre-rotate the image instead?

On a fixed mount, skip auto-rotate: mounting the camera so the code runs square to the sensor, or pre-rotating the frame yourself, keeps the coordinate frame fixed and removes up to three extra decode passes that a four-orientation search can spend on every frame.

Auto-rotate is a search, and searches cost decode passes: a four-orientation loop can spend up to four passes on one frame before it finds the hit, while a known orientation spends exactly one. Two deterministic alternatives beat it on a fixed mount. Restrict decoding to an ROI around the region where the code always presents, which shrinks the image before the decoder starts — the method and its speed gains are set out in setting an ROI for inline code reading. Or rotate the frame yourself, once, in your own code, so the coordinate frame never changes hands — the rotation mechanics are in barcode image rotation: correct camera frames before decoding.

When presentation is uncontrolled, auto-rotate is the right answer. A handheld code reader such as the LS-HCR-0001 gets pointed at codes at whatever angle the operator holds, and quarter-turn searches belong inside that decode, not in a downstream overlay. On fixed mounts that see occasional rotated parts, keep auto-rotate enabled and keep the correction math with it — the two travel together.

How do you keep the bug from coming back on the line?

Log the orientation value with every read and assert the corrected points fall inside the frame: a two-line check in the result handler turns a silent coordinate-frame mismatch into an alarm the moment a code presents at a new angle.

Cover the correction in the decoder's unit test: three rotated copies of one golden image — the same code at 90, 180 and 270 degrees with hand-checked coordinates — keep the fix fixed across decoder library updates. Log orientation beside the decoded string and timestamp, and a week of line data tells you whether rotated reads are rare events or every read.

Other geometry faults share the symptom class and deserve their own guards: a bumped mount shifts every detection by the same few pixels until someone re-teaches the reference, a failure mode covered in why pixel shifts change detection results and how to stabilize them. Keep the guards separate — orientation metadata explains a rotation-shaped error, nothing else.

If you are choosing hardware as well as fixing geometry, the camera finder filters fixed readers by resolution, interface and shutter, the system configurator walks camera, lens, light and trigger in order, and the code reading guides collect the decode-side pages. For a specific station, contact us and we will check the presentation angles with you.