A camera that returns from a relocation with full-height blank columns, or with a mirror-image view of a web you know is running, usually carries two faults at once: a flip setting the camera never supported, and an orientation the new web path reversed. This guide separates them. You will see what a flip or tap-reversal flag actually does to a line scan or area scan image, run a short test sequence that rules wiring and power in or out, and choose between the two fixes that hold up in production: defaults restored, and the camera rotated 180 degrees. The coordinate arithmetic a rotation creates is worked through on a 2K, 7 μm line scan camera.
What a flip setting actually reverses
Line sensors read their pixels through one or more output taps, and the camera firmware stitches those taps into a single line in a fixed order. A reverse feature the camera implements reorders pixels inside that line, cleanly, in the buffer. A flip flag inside an application's configuration file is a different animal: it is written per camera model, and on models where nobody implemented it, the reversal can reach the tap stitching instead. Whole segments of the line land in the wrong slots or are left unwritten, the frame buffer keeps zeros there, and zeros display as full-height black columns at fixed pixel positions.
One print inspection package shows the whole failure chain. Its camera settings sit in a configuration file under a [Camera] section, and one of the entries reads Flip=1. The flag worked on exactly one 4K camera model in that software's supported list. A technician rebuilding a relocated press set it on a different camera, the tap readout reversed, and every frame came up with vertical blank bands.
Back at Flip=0, the bands vanished and exposed the reason the flag had been tried: the rebuilt press now ran the web in the opposite direction, so the entire image was mirrored. The cure was mechanical, rotating the camera 180 degrees about its optical axis, and the flag stayed off for good.
Read the artifact's orientation first
Before touching a setting, read what the artifact says. The axis of the defect maps to the axis of the fault, and that mapping does most of the diagnostic work: a column fault cannot come from a trigger, and a row fault cannot come from a flip setting.
| Artifact in the image | Fault axis | First suspects |
|---|---|---|
| Full-height black columns, fixed positions, identical every frame | Cross-web (columns) | Flip or tap-order setting, dead tap, sensor column defect |
| Missing, duplicated or streaked rows along travel | Scan direction (rows) | Trigger wiring, packet loss, line rate wrong for the web speed |
| Whole image mirrored or reversed | Mounting orientation | Camera or web direction after a move |
| Dark band with soft edges, moves with cleaning or focus | Optics | Dust, shadow, damaged filter |
Two look-alikes are worth ruling out early. Gray, displaced segments in a GigE area scan frame are network packet loss, not a sensor fault; GigE Vision packet loss: horizontal lines in live images covers that case. And stripes that appear on screen but not in a saved raw file belong to the display path, which is its own fault with its own write-up on vertical lines from the display path.
Likely causes, most common first
- A flip or reverse flag the model never implemented. Copied configurations spread these. Test: list every flip-style entry in the application's camera section, return each to its default, power-cycle, and compare raw frames. The fix costs nothing and takes minutes.
- A configuration carried over from the previous station. Beyond flip flags, settings applied before the camera finished starting are silently dropped, the same trap that hides gain changes until auto gain is off and exposure limits until the startup order is fixed. Test: diff the live configuration against your saved baseline and reapply entries one at a time.
- A dead tap or a column defect in the sensor. Test: cap the lens and capture at normal exposure. Bands still present at exactly the same columns, with no light reaching the sensor, point at the readout rather than the scene; a swap to a twin camera settles it.
- Cable, connector or supply fault. Test: flex the interface and power cables at the camera during live capture. Bands that flicker, widen or wander are wiring; check the supply voltage at the camera connector while it runs.
- Optics. Test: a band with soft edges that moves when you clean the front element or change the aperture is dirt or shadow, and no setting will remove it.
The ten-minute diagnostic
Run the sequence in order and stop at the first branch:
- Save the live camera and application configuration to a file you keep. You will diff against it later.
- Return every flip, reverse, mirror and invert entry in the camera section to its default, then power-cycle the camera so nothing stale survives in memory.
- Capture with the lens capped at normal exposure. Bands gone: the flag was the cause; jump to step 7. Bands present: continue.
- Flex the interface and power cables at the camera while watching live frames. Movement or flicker means wiring; re-terminate and re-test.
- Open the camera's feature list in your acquisition software, the GenICam list on GigE Vision and CoaXPress cameras, and look for a reverse or mirror feature for this exact model. Enable it only if it is listed, one change per capture.
- Swap in a known-good camera of the same model. Bands that persist across the swap implicate the cable, the supply or the application configuration; bands that vanish implicate the first camera.
- If the image is now clean but mirrored, name the axis before fixing anything: features backwards across the web is a cross-web mirror; content arriving in reverse line order is a travel-direction reversal. The fixes differ.
- Apply the matching fix from the next section, capture a printed target with known content, and only then release the line.
A blank image rather than a banded one after all this means the acquisition chain itself is down; probing the pipeline stage by stage is the fastest route out.
Worked example: cross-web remap on a 2K, 7 μm line after a 180-degree rotation
A typical camera for this kind of web station is a 2K GigE line scan camera with TDI transfer and an M42 mount:
- Lens mount
- M42
- Interface
- GigE
- Line length
- 2K
- Pixel size
- 7 μm
Its printed line length, 2K, is 2,048 pixels, its printed pixel size is 7 μm, and its line rate is 58 kHz. Three inputs, all from the camera's own data:
- Line length N = 2,048 pixels
- Pixel pitch = 7 μm
- Line rate = 58 kHz
A 180-degree rotation about the optical axis mirrors the sensor line: pixel x reappears at x' = (N - 1) - x. With N = 2,048 pixels, column 0 moves to column 2047, column 2047 moves to column 0, and the middle pair, columns 1023 and 1024, swap places. In physical units the line runs L = 2,048 px x 7 μm/px = 14,336 μm, about 14.3 mm, so a feature at distance p from the left edge lands at p' = 14.3 mm - p from it.
Timing does not move at all. At the 58 kHz line rate one line still takes 1/58,000 s, about 17.2 μs, and the camera still delivers 58,000 lines per second; the rotation turns the cross-web axis around and touches nothing else.
The decision: rotate whenever the mount gives you the room, keep Flip off, and re-map the recipe's cross-web coordinates with x' = 2047 - x, or re-calibrate on a printed target, before you trust a defect position again. Where the mount forbids rotation, the camera's own reverse feature, for models that list one, lands pixels in identical places inside the firmware and leaves your recipe untouched.
Rotate, don't flip
Rotation wins on every axis that matters in production. It is model-independent, it adds zero processing to any line, it survives a camera or software change, and the remap it demands is the one-line formula above. Print webs are the classic habitat for line scan cameras, and 4K-class color models are typical there: the MV-CL042-91GC-V2 is a 4K GigE color line scan camera with 7 μm pixels and an M42 mount.
- Lens mount
- M42
- Interface
- GigE
- Line length
- 4K
- Pixel size
- 7 μm
Two mirrors exist, and they take different fixes:
- Backwards across the web: text reads mirrored and features sit on the wrong side of a datum. Rotate the camera 180 degrees about its optical axis, re-route cabling for the new connector side, and apply the coordinate remap.
- Reversed along travel: the image scrolls the wrong way and leading and trailing edges swap line by line. Rotating about the optical axis does nothing to the time axis. Reverse the acquisition direction instead, by swapping the encoder direction or the line order where the acquisition stage allows it, and re-check encoder ticks per pixel while you are there. The line scan mode of an area scan camera carries the same travel-direction choice in its set-up.
Where rotation is impossible, fall back to software in this order: the camera's own reverse feature for your exact model first, a flip in your own processing second, and never a generic configuration flag. A TDI camera whose web reversed needs re-orientation rather than a mirror patch, because TDI integrates charge along a fixed transfer direction and a mismatch costs sharpness along travel first.
The same logic covers area scan cameras: a mirrored view of a static scene is again best cured by rotating the camera, with a software flip as the fallback. A feed that arrives rotated by 90 degrees instead of mirrored is sensor orientation, a different fault with its own fix in sensor transpose and dropped lines; when measurement frames need a permanent software rotation, the 90-degree image rotation before measurement case shows how to keep coordinates honest.
Checks before you restart the line
- Orientation against a reference. Capture the printed target used at commissioning and compare against the saved reference image, not memory.
- Coordinate endpoints. On the remapped recipe, a feature that logged at column 0 must now log at column 2047 on a 2K camera, and a mid-line feature must sit within a pixel or two of its old position, because the middle pair barely moves.
- Configuration diff. Live settings against the saved baseline, with no flip-style flag enabled anywhere in the camera section.
- Encoder direction and scale. Ticks-per-pixel must still match the web after the re-route; the calculation lives in the encoder article linked above.
- Line rate against the new speed. A relocated web often runs at a different speed; set it with the line rate method for line scan cameras and re-check exposure while you are in there.
- TDI direction. Confirm the transfer direction still runs with travel.
When the obvious answer is wrong
- Bands that move or breathe are never a setting. They are wiring, supply or vibration, and they need the cable test from the diagnostic, not a configuration edit.
- A mirror along travel cannot be fixed by rotating about the optical axis; the time axis belongs to the encoder and the acquisition direction.
- Clearing the flag and leaving the mirror in place is not a fix either. The bands were the flag's damage; the mirror was the reason someone reached for it. Fix both, in that order.
- Vertical stripes that survive in the raw file on every machine, at fixed pixel positions with the lens capped, are sensor or settings. The same stripes that vanish in raw files were never the camera's fault.
If the station stays down after the diagnostic, the contact page reaches the applications team; attach the saved configuration and two raw frames, one capped and one live. To specify a camera for a rebuilt web line, the camera finder filters by line length, pixel size and interface, and the camera step of the configurator assembles camera, lens and light together.
Questions
Should I rotate the camera or flip the image in software?
Rotate when the mount gives you clearance and the cabling can be re-routed: the fix is immediate, model-independent and adds no processing to any line. Flip in software only when the camera's feature list shows a reverse feature for your exact model, or as a transform in your own code when mechanical rotation is impossible. Either way, re-map cross-web coordinates before trusting defect positions again.
How do I tell flip artifacts from a cable or power fault?
Flip and tap artifacts are digital and frozen: full-height columns at fixed pixel positions, identical on every frame, present even with the lens capped. Cable and supply faults usually flicker, widen or wander when you flex the cable at the camera, and they often track vibration or a specific line rate. Static bands that survive a power-cycle point at settings or sensor; anything that moves is wiring.
Does rotating a line scan camera 180 degrees change its calibration?
Scale survives the rotation: the same lens, the same 7 μm sampling and the same line rate all still apply. What changes is direction along the sensor line, so a feature that logged at column 0 on a 2,048-pixel camera now logs at column 2047. Re-map the recipe with x' = 2047 - x or re-calibrate on a printed target before trusting positions again.
What changes on a TDI camera when the web direction reverses?
TDI sensors sum charge along a fixed transfer direction, so a TDI camera is built for one travel direction. If the web reverses, integration no longer matches the motion and sharpness along travel falls first. Re-orient or re-mount the camera so the transfer direction runs with the web again, and use a direction setting only where the camera's feature list provides one.
What should I check after relocating a web inspection station?
Capture a printed target and compare orientation against the commissioning reference, diff the live camera configuration against the saved baseline, and confirm encoder direction and ticks-per-pixel still match the new web path. Re-check the line rate against the new speed, confirm a TDI camera's transfer direction, and run a known defect under the camera before releasing the line.

