feat(transforms): add close-point filtering transform

[medar6]

Context

• Feature

TLDR

Adds a close point filtering transform that filters points that are too close in x and y coordinates (disregarding z) .This PR fixes #118 .

Explanation

The nuScenes devkit removes LiDAR points close to the sensor origin when loading point clouds. This filters ego-vehicle self-returns that would otherwise remain in the point cloud and potentially contaminate downstream model inputs. Until now, NuScenes3D intentionally disabled this behavior when comparing its output against the devkit because vision3d did not provide an equivalent reusable transform. Now this will provide the needed functionality 🥳 .

This PR adds the following public transform:

vision3d.transforms.ClosePointFilter

The transform accepts a configurable radius, which defaults to the nuScenes devkit value of 1.0 (Maybe default can be changed/remvoed):

from vision3d.transforms import ClosePointFilter

transform = ClosePointFilter(radius=1.0)

To match the nuScenes devkit exactly, a point is removed when both of the following conditions are true (we disregard z):

abs(x) < radius
abs(y) < radius

This defines an open square exclusion region in the XY plane. The z coordinate and any additional point features do not affect filtering. Points located exactly on the boundary are retained. The transform operates on PointCloud3D inputs through the transform kernel registry. Other elements of a sample, such as images, camera parameters, bounding boxes, and labels, pass through unchanged.

Motivation

Close LiDAR returns commonly originate from the ego vehicle or sensor platform itself. It can even just be the LiDAr cabs or similar. These points do not describe the surrounding scene and can introduce unwanted noise into training and inference data.

Additional changes

• Exports the transform and functionals from their public namespaces
• Rejects negative radius values
• Removes the previous close-point filtering TODO from the nuScenes tests
• Adds tests covering (XY-only filtering, feature preservation, emplty point clouds, ...)

Bonus

The developper had not a real understanding how dispatchers are used in the torch style and also not very clearly what the importance of torch kernels are. Now much clearer. 🐐

Testing

This was only tested on CPU due to missing hardware for GPU testing. Following checks were run:

uv run ruff check
uv run ruff format
uv run pyrefly check
uv run pytest -m cpu
uv run pytest -m "not cuda"
CUDA_VISIBLE_DEVICES="" uv run pytest -m cpu

FYI: @yeetypete

[medar6]

@yeetypete or @simonschlaepfer could you please take a look at the PR and review it or let me know what is missing or how I misunderstood the task?

[simonschlaepfer]

Yes, I will review it. But we have to wait until @yeetypete 's refactoring #152 for the transforms landed.

[yeetypete]

Yes, I will review it. But we have to wait until @yeetypete 's refactoring #152 for the transforms landed.

Yep need to split that PR up because its just a draft cleanup and too big to review...