ISP default settings that look like compression artifacts

A low-light evaluation of a new camera module comes back covered in tiny blocks, mosquito edges around every wire, and watercolor-smoothed patches where texture should be. The usual verdict is compression, and the next hour disappears into stream settings and transport questions. On embedded and board-level modules the likelier culprit sits in plain sight: the on-sensor image signal processor (ISP) ships with sharpening and denoise enabled, and the combination mimics a lossy encoder almost pixel for pixel. This guide shows why that happens, gives tests that separate the two in minutes, and walks a two-frame flat-field check with the arithmetic written out. You finish with a settings order that makes the next sensor evaluation trustworthy.

The symptom: blocky edges and smeared patches that are not compression

True compression artifacts have a geometry. JPEG-type encoders cut the frame into fixed blocks, so ringing repeats on a grid and block boundaries stay faintly visible even where brightness is flat. The ISP version looks similar at a glance but follows content instead of a grid. Sharpening adds overshoot and halos that hug every edge. Luma denoise wipes fine texture into patches of slightly different smoothness. Chroma denoise smears color across boundaries the way chroma subsampling does. All three strengthen in low light, because the ISP's internal noise estimate rises exactly when you are trying to judge the sensor.

The fastest discriminator: artifacts that move with the part are content-driven and point at the ISP; artifacts that hold a fixed grid while the part moves point at an encoder.

Why the defaults mimic a lossy encoder

Denoise is averaging. It replaces each pixel with a blend of its neighbours, which lowers variance and flattens whatever texture the scene carried. Sharpening is the opposite operator, a high-boost filter that exaggerates local contrast, and its side effect is amplifying whatever noise survives denoise near edges. Run both, add chroma smoothing, and the frame acquires the two signatures people read as lossy compression: quantized-looking flat patches and ringing at edges.

The transport can be lossless the whole time, which is why file-size clues mislead. The pixels were reworked before the frame left the module, so no amount of stream tuning brings the texture back.

Where the processing hides: raw and processed outputs

Most embedded camera SDKs expose two families of output from one sensor. The raw path carries Bayer or mono values straight from the analog-to-digital converter. The ISP path runs demosaic, white balance, gamma, sharpening and denoise, then splits into named streams for video, preview and still capture, each with its own scaling.

The three controls to look for live on the camera node: sharpness, chroma denoise and luma denoise. On consumer-derived modules they typically ship enabled, at a strength that reworks a dim frame. Newer SDK generations sometimes drop the plain raw output and expose the full-resolution frame only through an explicit request, and some modules cannot deliver pre-debayer raw at all. Check the pixel format while you are there, because a processed 8-bit stream reaches your code even when the sensor is deeper, as why 10-bit sensors ship 8-bit images explains.

Likely causes, in order of probability

1. ISP defaults on the module. Open the camera node's properties, find sharpness, chroma denoise and luma denoise, set each to its minimum or off, and re-shoot the same scene at the same exposure. Artifacts replaced by honest speckle closes the case.
2. Compression added after the sensor. A recording stage saving JPEG, or an MJPEG or H.264 hop through an intermediate device, produces the same look. Capture the exact buffer your algorithm reads; the raw Bayer stream check gives the pixel-level proof of what you actually hold.
3. A setting that never reached the hardware. Some drivers accept the write and ignore it, so the frames look identical before and after. Measure the flat-field standard deviation on both sides of the change; if the variance does not move, the setting went nowhere. The exposure and gain settings a sensor driver ignores article walks that failure in detail.
4. Display-side processing. A viewer that rescales and oversharpens on display makes edges look machine-made. Read the numbers in code instead of on screen.
5. A genuine sensor or illumination fault. Column fixed-pattern noise stays in the same columns frame after frame, and flickering light lays bands that shift with exposure. Average 32 frames: fixed pattern survives averaging, while ISP-style artifacts track content instead.

The fix and the settings order

The repair is three controls and one output choice, in this order:

1. Set exposure, gain and gamma to manual and write the values down.
2. Set sharpness, chroma denoise and luma denoise to minimum or off on the camera node.
3. Take the raw or full-resolution output instead of the preview stream, which may scale on its own.
4. Light a uniformly lit flat target and capture at least two frames at each of 3-5 brightness levels across the working range.
5. Run the two-frame check in the next section and compare the measured standard deviation with the expected one.
6. Record noise numbers only after steps 1-5, and only from the raw or ISP-off stream.

Exposure, gain and the noise you measure interact; industrial camera image quality settings: exposure, gain, balance covers how to set the three for a stable evaluation.

Worked example: two flat fields on a dim bench at 2,000 DN

Suppose a bench evaluation of a board module gives these flat-field measurements (illustrative pairs — your frames supply their own numbers; the method is what transfers):

• Pair 1, dimmer light: mean M1 = 1,000 DN, standard deviation σ1 = 16 DN.
• Pair 2, brighter light: mean M2 = 4,000 DN, standard deviation σ2 = 32 DN.
• Working point to judge, defaults on: mean M = 2,000 DN, measured σ = 9 DN.

The physics: photon shot noise follows Poisson statistics, so the standard deviation grows with the square root of signal. Fitting the variance-versus-mean slope over two points cancels the constant read-noise floor and returns the conversion gain K in electrons per DN — the flat-field logic the EMVA 1288 standard formalizes.

Arithmetic:

• σ2^2 - σ1^2 = 32^2 - 16^2 = 1,024 - 256 = 768 DN^2
• K = (4,000 - 1,000) / 768 = 3,000 / 768 = 3.9 e-/DN
• σ_exp = sqrt(2,000 / 3.9) = sqrt(513) ≈ 22.6 DN

The measured 9 DN at the 2,000 DN working point is 9 / 22.6 = 0.4 times the expected value: roughly 60 percent of the noise amplitude was removed before you ever saw the frame. Decision, with ±20 percent slack allowed on the gain estimate for illumination unevenness: measured σ between 0.8 and 1.2 times σ_exp means you are looking at true raw; below 0.6 times means a denoise stage is active; above 1.5 times means sharpening or a lossy step is inflating contrast. At 0.4 times, the verdict is denoise, unambiguous. Turn sharpness, chroma denoise and luma denoise off, re-shoot, and the flat fields should land near 22.6 DN — the sensor's real low-light number, finally on the table. If they still come in low, the smoothing lives downstream of the camera.

Hardware that hands you true raw

For a bench evaluation of the sensor itself, keep the chain short: a mono area scan camera streams raw frames your code reads directly. Mono also skips the Bayer color filters, so the same exposure lands more electrons and chroma denoise has nothing left to average. The MV-CS200-10UM puts a 20 MP IMX183 mono sensor behind a C-mount on USB3 — enough sensor for flat-field and dark measurements at full format.

For builds where the camera must live inside the machine, board-level cameras are the short path:

The MV-CB060-10UM-B ships as a bare board around a 6 MP IMX178 mono sensor on USB3, so you build the processing chain around it yourself. Where the part moves, shutter choice matters more than format: the MV-CB016-10GM-M-W pairs an IMX296 mono sensor with a global shutter on GigE, and the LS-BCM-0003 specifies 120 fps from a global-shutter IMX252. Whichever module you choose, run the board camera evaluation checklist before comparing noise numbers, so the settings above are pinned first.

When it really is compression

Some paths compress by design. A smart camera that serves JPEG over HTTP, a network hop that re-encodes to MJPEG or H.264, a still branch that saves compressed files — each imprints the fixed grid from the table above. The tell is position: block boundaries hold their place while the part moves. Fix it at the source by requesting the uncompressed output, because re-encoding a decoded frame cannot restore what the encoder discarded. That is also why machine-vision cameras stream raw as a design choice; why machine-vision cameras stay raw covers what in-camera compression would cost a measurement system.

Prevention: the order of operations for a sensor evaluation

• First contact with any new module: manual exposure, gain and gamma; sharpness, chroma denoise and luma denoise off; raw or full-resolution output requested — all before the first judgment.
• Quote noise only from raw or ISP-off frames; a sharpened stream inflates the number and a denoised stream deflates it.
• Compare cameras at a matched mean level; 2,000 DN against 1,000 DN is not a comparison.
• Save the pixel format with every capture set, so an 8-bit processed stream never masquerades as a sensor measurement.
• Validate any focus metric on an ISP-off stream, because sharpening flatters focus scores.
• Keep denoising downstream of measurement, on a display or archive branch only.

If you are choosing the evaluation platform itself, the camera finder filters by interface, shutter and spectrum, and the camera configurator walks sensor to cable in order. If the two-frame check refuses to settle on your bench, send the images to our team through the contact page.