Filter invalid texture coordinates in a point cloud

A point cloud can contain valid geometry outside the color camera’s view. If the exporter clamps or wraps texture coordinates, those points acquire plausible-looking colors that were never measured there. A preview can hide the same points while the saved file retains them.

For developers exporting textured depth data, the fix is an explicit validity policy shared by preview and export. You will separate geometric validity from color coverage, reject unsupported samples, and verify the saved file. Depth-to-color alignment provides an alternative workflow, but it does not remove the need for validity checks.

Choose what your export promises

First decide whether the output represents all measured geometry or only geometry with valid color. Both are useful, but they require different handling of untextured points.

For a colored inspection dataset, rejecting unsupported points is often the clearest contract. For dimensional measurements, removing valid geometry merely because color is unavailable may discard useful information. Keep a geometry-first export alongside the colored subset when that distinction matters.

The guide to full-resolution color with a depth point cloud explains the relationship between the color image and depth geometry. Here, the task is narrower: deciding which projected color samples your exporter may actually use.

Freeze the inputs before comparing processing paths

Use a saved capture or a stationary target so scene motion does not obscure the comparison. Preserve the original depth and color frames rather than comparing screenshots from separate acquisitions.

1. Record frame identifiers, timestamps, image dimensions, calibration, and active processing settings.
2. Confirm that each texture coordinate corresponds to the same vertex index in the cloud.
3. Disable automatic exposure changes during the comparison, or record them if they cannot be disabled.
4. Export the same captured frames through each processing path and compare validity masks, not just appearance.

Cropping, resizing, decimation, and image rotation can change the coordinate mapping. Texture coordinates generated for one image size must not silently address another image. Check the intrinsic parameter conversion guide when the texture image has been resized or cropped.

For moving scenes, frame pairing is another independent requirement. The timestamp-based frame matching workflow helps separate stale color frames from projection errors. Correct coordinates cannot compensate for color captured at the wrong instant.

Validate geometry and texture coordinates separately

A point needs several checks before it receives color:

• Its depth measurement is valid under the acquisition API’s documented rules.
• Its position is finite and lies within your accepted measurement region.
• Its texture coordinates are finite and follow the documented normalization convention.
• The selected color sample, including any interpolation neighbors, exists.
• The surface point is visible from the color camera under your visibility policy.

Do not treat a coordinate pair of zero values as universally invalid. Depending on the API, it could identify a real image location or represent a failed projection. Use the documented validity indicator and depth mask rather than guessing from that pair alone.

Define the sampling convention explicitly

For this example, assume normalized, edge-based texture coordinates and a cell lookup. The accepted domain is half-open: zero is included, but one is excluded.

Here, W and H are the color image width and height in pixels. This is an exporter convention, not a universal SDK rule. Some APIs normalize against the last pixel center, allow an endpoint of one, or specify different rounding. Convert their output into your chosen convention before applying this test.

Bilinear interpolation needs a separate support check. An implementation that always reads four neighboring pixels must keep all four addresses inside the image. Checking only the central coordinate is insufficient near the last row or column.

Apply one mask to positions and colors

The following Python example assumes array-like inputs, positive-forward depth-camera coordinates, and the half-open convention above. The visible mask must come from a visibility check or an explicitly limited test scene. The color_ok mask identifies usable color pixels, including any invalid regions introduced by earlier processing.

from math import floor, isfinite


def exportable_points(xyz, uv, depth_ok, visible, rgb, color_ok):
    n = len(xyz)
    if not (len(uv) == len(depth_ok) == len(visible) == n):
        raise ValueError("Point attribute lengths differ")

    height, width = rgb.shape[:2]
    if color_ok.shape != (height, width):
        raise ValueError("Color validity dimensions differ")

    positions = []
    colors = []
    source_indices = []

    for i in range(n):
        X, Y, Z = xyz[i]
        u, v = uv[i]

        if not depth_ok[i] or not visible[i]:
            continue
        if not all(isfinite(t) for t in (X, Y, Z, u, v)):
            continue
        if Z <= 0:
            continue
        if not (0 <= u < 1 and 0 <= v < 1):
            continue

        x = floor(u * width)
        y = floor(v * height)
        if not color_ok[y, x]:
            continue

        positions.append((X, Y, Z))
        colors.append(rgb[y, x])
        source_indices.append(i)

    return positions, colors, source_indices

If your cloud has already been transformed into another coordinate frame, replace the positive-Z test with the appropriate geometric rule. A valid world-frame point can have a negative Z coordinate.

Keep the returned source indices when you also export confidence, normals, labels, or intensity. Every point attribute must use the same selection. For invalid geometry before texturing, follow the depth deprojection validity checks.

Check visibility before assigning color

An in-bounds projection does not prove that the color pixel depicts the depth point. With separated depth and color viewpoints, a foreground object can hide a background surface from the color camera. Both surfaces may still project inside the color image.

For a general scene, transform accepted depth points into the color-camera coordinate frame. Reject points behind that camera before projection. Then use a visibility method, such as a projected depth buffer that retains the nearest surface at each color location.

Compare candidate depths using a tolerance justified by measurement noise, calibration error, and sampling footprint. There is no universal distance threshold suitable for every camera and working range.

A depth buffer built from an incomplete cloud cannot detect an occluder that was never measured. Treat that limitation explicitly if your application requires strict color correspondence.

For an initial test, use a flat target visible to both cameras. Then introduce a foreground edge and inspect the background behind it. A mask that passes the flat target can still fail at occlusion boundaries.

Work through the boundary arithmetic

Consider a hypothetical color image measuring 1920 × 1080 pixels. These are application example dimensions, not specifications for a listed product.

Using the half-open cell lookup:

The first coordinate selects the final column. The second addresses a column outside the image and must be rejected under this convention. A coordinate slightly below zero is also rejected before sampling; it must not become a border pixel through clamping.

Now suppose a capture contains 100,000 geometrically valid points. Of those, 8,000 fail the texture-domain check. A further 2,000 of the remaining points fail visibility or color-validity checks.

These counts are illustrative and sequential, so no rejection is counted twice. A smaller colored cloud is expected here. It does not mean the missing geometry was invalid; it means color was unsupported under the export contract.

Compare UV filtering with depth-to-color alignment

Direct UV filtering preserves the original depth sampling. Depth-to-color alignment instead represents depth on the color image grid, typically involving projection, collision handling, and resampling rules.

Alignment can simplify indexing because depth and color share image dimensions. However, shared dimensions alone do not establish valid depth or visible color at every pixel. Preserve the aligned depth validity mask and inspect how empty pixels and projection collisions are handled.

When deprojecting aligned depth, use the calibration and depth semantics documented for that aligned output. Do not automatically reuse the original depth-camera intrinsics.

Compare both workflows on a common target region. Examine color correspondence, depth differences, retained coverage, and edge behavior rather than demanding identical point counts. If alignment fails before export, the depth-to-color processing troubleshooting guide addresses that separate failure stage.

Verify the saved file independently

Reopen the exported file through an independent reader or inspect its parsed arrays. Checking only the original viewer leaves room for display filtering to conceal an export problem.

Use these acceptance tests:

• Count: The saved vertex count equals the accepted-mask count.
• Attribute pairing: Every saved position has its corresponding color and other attributes.
• Finite geometry: No accepted coordinate contains a non-finite value.
• Boundary behavior: Deliberately invalid UV values are rejected rather than clamped or wrapped.
• Color correspondence: Distinct patches on a test target remain attached to the correct surfaces.
• Occlusion behavior: Background points do not inherit foreground colors across a depth discontinuity.

Include test inputs just below zero, exactly zero, just below one, exactly one, and non-finite coordinates. Write expected outcomes against the documented sampling convention before running the exporter.

For PLY output, declare the retained vertex count in the header and use consistent color property types. Confirm channel order and numeric encoding on reopening. If exporting mesh faces as well, removing vertices also requires remapping face indices or discarding affected faces.

Check acquisition requirements before selecting hardware

Software filtering cannot create overlap between camera views. Before choosing 3D sensors, establish the working region, expected surfaces, acquisition timing, and required access to calibration and validity information. The 3D camera positioning guide helps assess the physical coverage first.

The catalog identifies MV-DPS200P-02 as a projected structured-light camera. Confirm its available image streams and export interfaces against your application requirements.

A separate color camera is another acquisition architecture, not an automatic texture source. The catalog identifies MV-CU020-90GC as a color area scan camera with GigE and a global shutter.

These products are not presented as a validated matched pair. The supplied catalog information does not establish synchronized operation, shared calibration, or a combined texture-export workflow.

Compare area scan cameras through the camera finder when independent color acquisition is appropriate. Any separate-camera solution needs verified timing, calibration, overlapping views, and an integration path that exposes the required data.

Release the exporter with an explicit checklist

Before using the output downstream, record the following alongside a representative capture:

• The geometry validity rules and coordinate frame.
• The UV convention, sampling method, and boundary policy.
• The visibility method and known occlusion limitations.
• Counts for each rejection stage and the final saved count.
• Frame identities, calibration version, and processing settings.
• Whether uncolored geometry is discarded, flagged, or exported separately.

Keep the original geometry available when color coverage is not a measurement requirement. Conversely, do not fill missing color merely to make a colored export look complete.

For an existing system, bring a saved frame pair, calibration details, and rejection counts to applications support. For a new acquisition setup, start with the camera configurator after defining the overlap and validity requirements.