Depth noise removal filter not supported: fix the startup loop

A depth camera that logs a missing noise removal filter on every init attempt is not broken. The launch file or config you are running asks the device to enable an on-camera post-processing stage that this firmware and SDK combination simply does not carry, so the driver retries, fails and loops forever. In this guide you will confirm that diagnosis in minutes, learn why the failure happens even when the log says the filter is being switched off, and get three working paths to frames on your topic again: drop the request, align versions, or filter on the host.

Symptom: the init loop that never converges

The pattern is easy to recognize. The driver connects to the device, applies exposure, gain, flip and sync settings without complaint, then fails while setting up the frame pipeline with an error of the form "config item NoiseRemovalFilter#1 doesn't exist". It retries a fixed number of times, reports "Device initialization failed after 3 attempts", resets the device uid, and starts over.

The confusing part for most engineers: the log also prints "Setting noise removal filter: OFF" right before the error. The driver believes it has disabled the filter, yet the pipeline setup still carries a reference to it. That means the filter node exists in the processing graph the driver builds, not merely as a toggle. When the device-side frame processor has no such node, connecting the graph fails regardless of the on/off value.

Likely causes, in order of probability

Work through these in order; the first two account for most cases.

1. SDK and firmware version mismatch. Your driver version builds a pipeline that includes the noise removal stage; your camera firmware is older or a different variant that never shipped that stage. The versions work separately but not together.
2. Config file written for different hardware. A launch file or YAML copied from another camera model or another branch requests a stage this device family does not provide at all.
3. Duplicated installs. Two SDK versions installed side by side, with the node loading a library from the wrong one. The loaded code and the firmware you believe you flashed disagree.
4. Partially applied firmware update. An interrupted flash leaves the device reporting a version it does not fully implement.

Causes 3 and 4 are rarer, but worth ten seconds of checking before you re-flash anything: list your installed SDK paths and confirm which one the node actually loads, and read the reported firmware version back from the device.

Step 1: stop the loop and get a clean baseline

Disable the noise removal filter request entirely, at the source of the setting, and restart. On most drivers this is a launch-file parameter or config key such as enable_noise_removal_filter: false; remove or comment out any related filter-order settings too, not just the on/off switch. If the camera comes up and streams raw depth, the diagnosis is confirmed: the pipeline graph, not the device, was the problem.

If it still fails with the same error, a config file you did not edit is still injecting the filter, or the driver hard-codes the stage in this release. In that case move to the version check.

Step 2: query the capability list before enabling anything

Any filter you enable by name must appear in the device's property or frame-processor capability list. The robust habit is to query first, enable second:

1. Open the camera with a minimal example that only reads properties and never writes filter settings.
2. Enumerate the available frame processor items or filter properties and record the names exactly as printed.
3. Only reference names that appear in that list in your launch file or config.

This costs one minute per camera model and prevents the entire class of failure. Do it whenever you change firmware, not only when something breaks: the capability list can grow or shrink between releases.

Step 3: align SDK and firmware versions

On-camera post-processing stages are implemented jointly by firmware and SDK, so these two must match. The general procedure is the one described in the article on camera firmware version mismatch: fix detection failures safely: read both versions from the device and host tools, get the matching pair from the camera manufacturer's official download channel, and update firmware first, then SDK.

When the versions differ by a major number, expect exactly this kind of gap: new filter nodes, renamed config items, changed pipeline graphs. The related failure mode after swapping hardware is covered in the article on a depth camera firmware mismatch after a shared camera swap, and header-level mismatches between SDK and device are treated in the guide to 3D camera header version mismatch: fix firmware and SDK alignment.

Step 4: fall back to host-side depth filtering

If you cannot upgrade, or the firmware genuinely lacks the stage, move the filtering to the host. This is often the better design anyway, because it keeps the filter version under your control and independent of camera firmware.

Typical host-side options, cheapest first:

• Temporal averaging over 3 to 9 frames: strong noise reduction, but only for static or slow scenes.
• Median filter over a 3x3 or 5x5 window: removes salt-and-pepper depth outliers while preserving edges.
• Validity-mask erosion: drop depth pixels adjacent to holes, which cleans the flying pixels at silhouette edges.

For a timing example at 30 fps, the frame interval is 1,000 ms / 30, or about 33 ms. A causal, equally weighted 3-frame average spans about 67 ms and has a mean sample age of 33 ms. A 9-frame average spans about 267 ms and has a mean sample age of 133 ms. These values describe the sampling window, not processing time; measure computation and buffering separately.

The CPU cost is modest at depth resolutions of a few hundred thousand pixels per frame. As a rough planning number, a 5x5 median on a 640x480 depth map at 30 fps is a few hundred million operations per second, which one modern core handles. Budget a dedicated core per filtered camera and you will rarely be wrong. For the noise side of the physics, the article on IR depth image noise in bright light: autoexposure floor explains why some noise cannot be filtered away at all, and the guide on black shadows on fast-moving objects in depth maps covers a failure that filtering makes worse, not better.

Structured-light depth cameras of this class run their own onboard processing pipeline, so which stages the firmware exposes varies by series and release. Check the capability list as in step 2 before your integration code assumes a filter exists. If you are selecting hardware for a new cell, the 3D sensors category page and its camera finder let you filter by profiler, stereo and ToF types so you can shortlist devices whose documented pipeline matches what your software expects.

Choosing hardware that matches your pipeline

The failure above is ultimately a systems-integration problem: the processing you request must exist where you request it. When you build a multi-camera cell, decide up front which stages run in the camera and which on the host, then size the host accordingly. A fanless vision controller with several GigE ports and built-in light channels keeps capture, filtering and inspection in one enclosure; start with the vision controllers category, then use the system configurator to plan the rest of the vision system.

Both of the controllers above carry multiple LAN ports and built-in light outputs; the card values show the port counts, memory and processor families so you can match them to your camera count before quoting.

Checks before your next deployment

Run this list whenever a depth camera config changes hands:

• [ ] Every filter name in the launch file appears in the device's capability list.
• [ ] SDK version and firmware version are a documented matching pair.
• [ ] Exactly one SDK installation is on the library path.
• [ ] The camera streams raw depth with all filters disabled, as a known-good baseline.
• [ ] Host-side filters, if any, are benchmarked at your frame rate on the target machine.

The baseline check is the one that saves the most time later: with a raw stream proven working, any later failure isolates to the stage you just added.

When the usual answer is wrong

Sometimes neither version alignment nor disabling the filter helps, because the error text was never about the noise filter. A config item index such as #1 means the driver builds a graph with several processors; the first missing item aborts setup and masks the rest. After aligning versions, rerun the capability enumeration once more: the next missing stage may have a different name. Also verify the basics before deep diagnosis, following the camera trigger common reference: diagnose missing responses checklist for wiring, and confirm your capture settings are within the device with the procedure in change 3D camera depth resolution and field of view at capture time. Finally, if the stream comes up but your measurements look wrong, follow 3D ROI coordinate frame: diagnose an inverted point cloud to check coordinate conventions before changing filter settings.

Next step

Start from the capability list, not from the config file: enumerate what your camera's firmware actually supports, strip the launch file back to a raw depth stream, then add stages one at a time. If you are shortlisting depth cameras or a controller to run the filtering host-side, browse the 3D sensors and vision controllers categories, or contact our applications team with your camera count and frame rate for help sizing the pipeline.