Why a line-scan image is stretched or compressed, and what to check

In short

Photograph a known-distance target and measure both sampling pitches first. The cross-web pitch is the measured field divided by the pixels in the sensor line, the motion pitch the actual speed divided by the actual line rate. Subtract the first from the second and divide by the first: positive means too few lines and compression, negative means too many lines and stretch. That sign holds on ordinary display with equal on-screen pixel pitch on both axes, because software that rescales the view masks the effect or fakes one. The difference gives the direction and the size of the geometric error and no more, since the same ratio arises from different changes of the two axes. Which branch moved, the trigger chain, the encoder scaling or the optics, follows from the independent check of each axis below, and each stays a hypothesis until that check confirms it.

Working through the causes

1. The error follows conveyor speed while the cross-web scale holds. A fixed internal line rate, an inactive encoder trigger and a camera refusing triggers at the higher rate all fit. Divide actual speed by actual line rate at two speeds and read the trigger source with the accepted-trigger counters, then restore displacement-synchronous triggering (vendor guidance) or correct the commanded rate.
2. The error is the same proportion at every speed. Confirm on a known target that the cross-web pitch has not moved, then compare counted encoder travel over a known distance with the calculated counts per line. Pulses per revolution, decode factor, loaded wheel diameter, divider and a slipping wheel all give this symptom, so correct only the one that test contradicts.
3. The cross-web scale changed after optical work. A new lens, a refocus or a moved working distance changes the field while the encoder scaling stays put. Measure a known distance across the line and recompute the target travel per line and the divider from it.
4. Blur, missing or duplicated lines, or rejected triggers come with the distortion. Compare the requested exposure with the working line period and read the camera status counters, since an exposure that does not fit can cost triggers, rate or sharpness. Shorten it, add light or lower the commanded rate before judging any divider.

Whichever branch you close, image the target again and measure both axes.

Worked example: target pitch and encoder counts

The inputs are assumptions: a 500 mm field with 4096 pixels across it and transport at 2000 mm/s. The cross-web pitch is 0.12207 mm, and square sampling, where both pitches are equal, puts the required line rate at 16384 Hz (calculated). The 20% margin is a camera-selection reserve that raises the working rate to 19660.8 Hz (calculated), but the required rate is what makes pixels square.

Now assume an incremental encoder of 2048 periods per revolution, x4 decoding, a 100 mm effective wheel and no slip: 8192 counts per revolution, 0.038350 mm per count, 3.1831 counts per line and 52151.89 Hz of counts (calculated). Counts per line is not a whole number, so the frequency converter, the divider and multiplier chain that makes one line trigger from the counts, approximates it: pre-divider 1, multiplier 11, post-divider 35. The actual travel is then 0.12202 mm per line, a line pitch error of −0.0402% (calculated), a pitch slightly short and so a trace of stretch. Register names differ between models.

Calculate for your case

The prepared link opens the calculator with this example's width, speed, detection mode, square sampling, margin and duty, the share of the line period left for exposure. You pick the camera from the result rows; with no interface or pixel-format field there, check a format against the camera's datasheet modes or the documented API.

The page does take encoder inputs: pulses per revolution, wheel diameter and x1, x2 or x4 decoding. The 1024 pulses and x1 in the address are its defaults, so enter your own, here 2048 and x4. That panel works from the working rate: at margin 20 it returns 2.6526 counts per line and 0.10173 mm of target travel, the geometry for 19660.8 Hz (calculated). Set the margin to 0 to get the example above, its exposure figure moving from 40.69 to 48.83 µs (calculated). Choose the camera on the first pass and set the geometry on the second.

Do not put your own width there and read the answer as your scale, because the selector then asks for a different sensor. To express your geometry there, set the minimum feature to the measured field times the pixels per feature divided by the pixels in the line, and redo it whenever the width changes. The derivations sit on the line-scan calculator reference.

Common mistakes

• A stretched image is often read as proof that the line rate is too high; measure the travel per line first and let the sign of the pitch error give the direction.
• A line rate below the datasheet maximum is often taken as proof that the image is right; read both pitches and the trigger counters before trusting it.
• A connected encoder is often taken for displacement-synchronous acquisition. Verify counts, polarity, decode mode, divider and coupling before clearing that branch.

When this rule breaks

The arithmetic assumes one scale factor from a rigid, slip-free coupling with a steady wheel diameter and one trigger per line. Distortion that changes with position is not one scale factor and points to slip, vibration or speed ripple. Acceleration distorts nothing by itself while triggering follows displacement, and matters when it pushes the chain past those conditions.

Next step

Send us a frame of a known-distance target with the actual speed, the commanded and accepted line rates and the encoder parameters; we confirm the target pitch and the counts per line for your camera.

Related

• Setting the exposure for a moving part, and deciding whether the light should be pulsed
• Choosing a camera interface when more than one profile passes the bandwidth check

How this material was prepared

Prepared with MVisionPro AI agents from stated sources and the calculation core; MVisionPro retains editorial responsibility. A physical test or human engineering review is claimed only when explicitly stated. Read the editorial method.

Editorial status: verified. Content updated 2026-09-21.