If invalid LiDAR coordinates remain after a PCL NaN-removal call, verify the incoming density flag before adjusting the next algorithm. In the PCL 1.15.1 implementation reviewed here, removeNaNFromPointCloud takes a copy path when the input cloud declares itself dense. A cloud containing invalid XYZ values while claiming is_dense=true therefore violates an assumption used by that implementation.
Treat this as a data-contract investigation. The flag does not prove that coordinates were examined, and the presence of a cleanup function in a pipeline does not prove which branch executed. Preserve the original message and inspect numerical values independently. Changing the flag alone also cannot repair malformed field decoding, units or a corrupted byte buffer.
Begin with the PointCloud2 layout diagnostic when coordinates may have been decoded incorrectly. Once field offsets, types and row strides are established, follow a bounded set of points through conversion, validity checking and output indexing. Keep the test reproducible without treating an attractive viewer display as evidence that every coordinate is usable.
Separate the flag from the numerical observation
The Jazzy PointCloud2 definition describes is_dense as true when there are no invalid points. Record that declaration alongside width, height, fields, point_step, row_step and data length. Also capture the original frame and timestamp. These observations describe one message; they do not establish that a later conversion preserves its content correctly.
Count finite and nonfinite XYZ coordinates with an independent reader that respects the message schema. Keep NaN and positive or negative infinity visible as separate categories in the diagnostic output. A zero coordinate is a finite number, so do not silently treat it as equivalent to NaN. Any application-specific invalid-range convention requires its own documented interpretation.
Create a comparison record containing the producer flag, the independent validity counts and the exact PCL point type. If the count contradicts the flag, identify the first producer or conversion boundary that introduced the disagreement. The driver regression checklist helps distinguish a changed producer contract from a downstream filtering change.
| Observation | Record | Decision |
|---|---|---|
| Producer declaration | Original is_dense value | Compare with examined coordinates |
| Numerical content | Finite, NaN and infinity counts | Separate data from metadata |
| Point representation | Fields and exact PCL type | Identify conversions and lost fields |
| Cleanup output | Dimensions and retained indices | Check compaction and correspondence |
| Consumer contract | Required fields and organization | Validate more than XYZ when needed |
Inspect the branch used by the installed cleanup function
Read the version actually deployed rather than assuming all releases or overloads behave identically. In the reviewed PCL 1.15.1 cleanup implementation, a dense input is copied and its output index mapping is filled sequentially. The alternative branch examines XYZ coordinates using finite-value checks before retaining a point.
That distinction explains why an incorrect dense declaration can survive a call whose name sounds corrective. Preserve the input flag before invoking the routine, then record the output count and indices. Do not infer execution from the function name or from a successful return. A wrapper may select another overload, convert to a different point type or skip the call entirely.
Repair the contract at its responsible boundary after confirming the values. Avoid a blanket flag assignment that declares unexamined data valid. If software must defensively validate an untrusted producer, make that examination explicit and measure its cost separately. The point-cloud processing overview places this validity stage before later geometric operations.
Define exactly which fields the validity test covers
The generic PCL point-validity helpers and the particular cleanup implementation must be examined together. The reviewed XYZ removal path tests x, y and z. That does not certify every additional field in a custom point record, such as intensity, ring identifier, normal or acquisition time.
Write the consumer’s requirements field by field. A mapping stage may require finite XYZ, while motion compensation additionally needs a meaningful per-point time and supported ordering. A point can satisfy one stage and fail another. Preserve those reasons rather than collapsing all rejection decisions into a single label called bad data.
Use the per-point timing preservation workflow before discarding or rebuilding custom fields. If a conversion retains only XYZ, a later validity check cannot recover lost timing or categorical information. Compare the complete schema before and after each conversion, and retain the original message for a controlled replay.
Keep index mapping and organization honest
The filter declarations and index contract distinguish a cleaned output from the indices connecting retained entries to their source. Keep that mapping when another array stores corresponding measurements. A compacted XYZ cloud and an unchanged time array must not be paired by their new positions without checking the relationship.
Removing entries can also change the organization expected by another consumer. Inspect output width and height rather than assuming the original image-like arrangement survives. In the reviewed nondense cleanup branch, the compacted output is represented as a single row. A consumer using row and column neighborhoods needs a deliberate policy for removed positions.
Distinguish density from organization. The reviewed PCL cloud container exposes separate dimensions and density information. A cloud can have valid coordinates without retaining a two-dimensional arrangement. State which property the next algorithm depends on before selecting compaction or a different supported representation.
Use small fixtures before returning to full captures
Construct a local, clearly synthetic fixture with valid coordinates and deliberately invalid XYZ values, then retain the expected source indices. Test the density declarations separately and record what the installed routine does. Include infinity as well as NaN because a finite-value requirement excludes both. Do not publish these artificial points as measured sensor failures.
Include an empty cloud and an input containing only invalid XYZ entries in the fixture set. Check the resulting count and mapping before asking another algorithm to consume the output. Do not index the first point unconditionally after cleanup. Keep an untouched copy of the expected result so that a later library upgrade can be checked against the same fixture instead of a newly regenerated capture.
Next replay a bounded real capture through the same conversion and cleanup path. Compare the independent counts, output dimensions, retained indices and downstream rejection reasons. Keep software revisions and actual point types with the results. A successful synthetic fixture verifies a narrow behavior; it does not establish the validity of an entire sensor deployment.
Prepare a reproducible support bundle if the producer still contradicts its metadata. Include a minimal original message, the decoding schema, the observed flag and the smallest code path that reproduces the disagreement. This gives the responsible engineer evidence to fix the first incorrect boundary without hiding the issue behind a later filter.
Frequently asked questions
Does is_dense mean the cloud is organized?
No. Density describes invalid-point expectations, while organization concerns the cloud’s dimensional arrangement. Inspect both. Do not infer an image-like layout from a true density flag, or numerical validity from the number of rows.
Should every cloud be forced to is_dense=false?
Do not apply a universal flag rewrite as a substitute for diagnosis. Establish what the producer emitted, which coordinates were examined and what the installed cleanup path expects. Correct metadata or add explicit defensive validation at the responsible boundary.
Does removing NaNs validate ring and timestamp fields?
Not automatically. The reviewed routine examines XYZ coordinates. Additional fields need their own type, units, meaning and correspondence checks. Keep the original full message and retained index mapping when those fields matter to the next consumer.
