Morph kernel corrupted image artifacts: transfer fault or kernel bug

You run a 3 × 3 morph — a Laplacian sharpen — and the output fills with small rectangles that are not in the scene. Two suspects stand out: the morph kernel itself, or the frame transfer between the sensor and memory. The difference decides where you work next, because a kernel fault is in your code and a transfer fault is in firmware you cannot patch from a script. What follows is the one test that splits the two in about a minute, the arithmetic that explains why a sharpen kernel draws these rectangles at all, the cause traced in one embedded camera firmware, and the fixes in the order worth trying.

The symptom and the one-minute decision

Repeating rectangular blocks, bands spanning whole rows, tiles of an earlier frame: corruption like this shows up after processing, tracks a frame-size or clock setting, and repeats the same way frame after frame. Treat it as a transfer fault until a saved frame proves otherwise. That is the decision, and it costs one file write.

Split the pipeline at the point of capture. Save the frame exactly as it left the camera, before any filter runs:

# kernel_size: int = 1; kernel: a list of nine ints, as in the reported script
kernel_size = 1
kernel = [-1, -1, -1,
          -1, +8, -1,
          -1, -1, -1]

img = sensor.snapshot()
# write this frame to a file here, with your library's image-save call
img.morph(kernel_size, kernel)

Rectangles already in the raw frame: the acquisition path corrupted the image, and the kernel only made it visible, because a sharpen kernel turns value steps into lines. Clean raw frame with rectangles only after the morph: the fault is in the kernel call, its scale and offset, or the buffer handling around it. In the reported case the raw frame was already corrupt: the driver's copy engine was losing a race on a shared line buffer, and a later firmware revision fixed it.

The four likely causes, ranked

Ordered by how often each explains row-aligned rectangles after a morph. Test in this order and you will usually stop at the first row.

Row two has its own walkthrough in heap corruption in vision software: fix image buffer lifetime. Row three is covered in the kernel section below. The rest of this guide is row one, because the frame-size clue points straight at it.

Worked example: a 3 × 3 Laplacian turns stale blocks into outlined rectangles

Inputs, each with its source:

• Kernel: 3 × 3, kernel size 1, taps of −1 on eight positions and +8 at the centre — the script from the reported case.
• Pixel format: 8-bit grayscale, one byte per pixel, range 0–255 DN (digital numbers).
• Test values, chosen for clean arithmetic: a fresh background of 100 DN and one stale block of 180 DN — the values an overwritten line carries wherever scene brightness differs from the previous frame.

In words: each output pixel is eight times the centre minus the sum of its eight neighbours, clamped to the 8-bit range. Now the four pixels that matter:

• Fresh interior: 8 × 100 − (8 × 100) = 800 − 800 = 0 DN. The kernel is blind on uniform ground.
• Stale interior: 8 × 180 − (8 × 180) = 1440 − 1440 = 0 DN. The middle of a stale block renders exactly like background, which is why you see outlines, not filled blocks.
• Stale edge: 8 × 180 − (4 × 180 + 4 × 100) = 1440 − (720 + 400) = 1440 − 1120 = 320 DN, clamped to 255 DN.
• Fresh pixel touching the block: 8 × 100 − (4 × 180 + 4 × 100) = 800 − 1120 = −320 DN, clamped to 0 DN.

Result: every stale block becomes a bright one-pixel outline at 255 DN with a dark rim at 0 DN, interior unchanged. Count the rectangles and you have counted the overwritten regions.

Decision, with its threshold: outlines whose edges sit on row boundaries and hold the same position frame after frame are stale data from the transfer path — stop tuning the kernel. A pattern that repeats every 3 pixels, the window width, or one confined to the outer pixel rows, is a kernel-code fault.

Why one frame size shows it and another does not

The resolution clue is the strongest evidence for the transfer path. Kernel arithmetic does not change with frame size — nine taps are nine taps at any resolution. The driver's copy plan does. In the affected firmware, the full-offload path moved every sensor line through one shared line buffer: the camera-interface DMA writes a line, a second DMA channel copies it into the frame in memory, and the next line immediately reuses the same buffer. With full offload off, the driver kept two line buffers and took one interrupt per line — slower, but a line could never be overwritten mid-copy.

Frame-size and clock settings move the timing on both sides of that race. When the copy channel cannot drain its queue before the next line lands, the frame receives a mix of fresh and stale lines, and the blocks appear. A capture-mode change that shifts line timing can therefore turn a clean stream into a tiled one with no change on your side.

Fixes on the acquisition side, in order

1. Update the camera firmware first. The reported fault sat in the full-offload copy path and was fixed in a later revision; on a board whose driver you did not write, the update is the whole fix.
2. If you build the firmware yourself, turn the full copy-offload build option off and rebuild. The partial path keeps the second line buffer and pays one interrupt per line — a fair price until the image is clean.
3. Lengthen the line window: drop the sensor pixel clock, or raise horizontal blanking if the driver exposes it. Either gives the copy engine more time per line.
4. If the driver is yours, use two line buffers or a ring of them and accept the per-line interrupt. Correct frames first, offload second.

When the acquisition path has to be replaced

When the firmware can be neither updated nor rebuilt, replace the transfer path, not the kernel. Standard machine-vision interfaces carry delivery checks of their own: a GigE Vision camera resends missing packets before the frame completes, and USB3 checks every packet with retry at the link layer, so a frame your software holds arrived whole. The sensor-to-memory line buffer then lives behind a standards-compliant cable instead of inside your driver.

For embedded builds, these board-level cameras span the mounts and transports worth shortlisting:

Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The LS-BCM-0020 suits a CS-mount optics path on GigE; the MV-CB016-10GM-M-W puts a global shutter behind an M12 lens; the LS-BCM-0003 takes the USB3 route at 120 fps. When the processing already runs on a PC, an area scan camera is the simpler swap: the LS-CMR-0053 is a 12 MP GigE area scan camera with an IMX226 sensor, a 1/1.7" rolling shutter, 9 fps and a C-mount.

A smart camera collapses capture and processing into one maker-maintained stack, so a fault of this class becomes a firmware ticket instead of your driver work. The LS-SMC-0063 pairs a 1.6 MP sensor with a 16 mm lens and runs 60 fps.

Filter by interface in the camera finder, or start a matched set at the camera step of the system configurator. The broader families are area scan cameras and smart cameras. If your board revision is involved, the fastest route to a straight answer is the contact page.

When it really is the kernel

Acquit the transfer path and the work moves into your code, where two faults cover most cases. First, border handling: a 3 × 3 window reads one pixel outside the image at every edge, and a wrapper that does not clamp its indices paints garbage into the outer rows. Second, scale and offset: a convolution kernel maps many inputs outside 0–255, and what happens next is down to the library. An 8-bit wrap instead of a clamp turns the −320 DN result above into −320 + 2 × 256 = 192 DN — a bright line exactly where the clamped version shows black. If your rectangles invert when you change the kernel offset, this is your bug.

The confirmation test is free: run the same morph on a stored, known-good image. A kernel fault follows the kernel; the Laplacian and smoothing convolution kernel crash guide walks those failure modes, and debug packed Bayer acquisition before image processing applies the same split on the capture side. One more angle: if you resized buffers around a changed frame format, check the multi-channel image buffer size before processing — row-stride mismatches produce bands too.

Checklist before you change anything

• Raw frame saved before the morph, and the rectangles are already in it → transfer fault; start at the firmware fixes.
• Outlines row-aligned, positions stable frame after frame → stale lines; the count of rectangles is the count of overwritten regions.
• Only one frame size or clock setting shows it → transfer timing, not kernel math.
• Same morph on a stored clean image is clean → kernel acquitted twice over.
• Frame copied out before its buffer returns to the camera → rules out buffer reuse; see push the camera buffer back only after copying your frame data.
• Firmware revision current → rules out the known, already-fixed offload fault.
• Pixel clock halved and the artifacts thin out → the copy engine was losing the line race; hold the slower clock until the firmware fix lands.

Work the list top to bottom and the third item settles most cases: rectangles in the raw frame are never a kernel problem, and no amount of morph tuning will move them.