· 3 min read · Gaia Lab

Trees one by one from LiDAR point clouds: splitting the forest into individuals

To estimate a forest's biomass you need to know where each tree begins and ends. The line compares three deep learning architectures on point clouds, with ten seeds, and measures what colour, intensity and point density contribute to the segmentation.

Three trees drawn as teal point clouds with some red points and grey trunks
Illustration generated for the series: three trees as point clouds.

Fifth instalment of Cluster X-ray. After the proteins , another line unrelated to language: forests.

The question #

A LiDAR scan of a forest plot returns millions of unlabelled points. To estimate above-ground biomass, and with it the stored carbon, you need to know which points belong to which tree: splitting the forest into individuals. It is a 3D instance segmentation problem, hard wherever the crowns touch. The line asks which architecture does it best, how much the result depends on the luck of the initialisation, and which information in the cloud really matters.

How it is approached #

On the Pointcept framework, three reference architectures for point clouds are compared: PTv3 (Point Transformer v3), OA-CNN and SpUNet (sparse-convolution U-Net). The main dataset is the group’s own, plots with labelled trees; an inference script also targets the public FOR-instance benchmark.

The experimental design is that of a rigorous study:

  • Ten seeds per architecture, so that the comparison does not hinge on one lucky run.
  • Input attribute ablation: coordinates only, plus colour, plus return intensity, plus number of returns. It says which sensor channels are worth keeping.
  • Density ablation: the cloud is resampled to grids of 0.05, 0.10, 0.20 and 0.40 metres. It says how much segmentation degrades with cheaper sensors or higher flights.
  • Ensemble at inference: weighted fusion of the masks of two architectures, without retraining, to see whether their errors are complementary.

What is learned #

The scripts do not contain the final metrics, but they do contain the shape of the result: a table per architecture, seed and condition, aggregated into curves with their variance. The decisions that can be read in the diffs are eloquent. PTv3, the transformer, is the one that demands the most memory and the one that exhausted the 141 GB of an H200 with the finest grid; it was isolated in its own jobs and retried. The ablations were done with a single seed and at a fixed density, “pinned to one label-quality tier”, to isolate each variable. And the density baseline was reused from the ensemble experiment instead of retraining it: same protocol, same seeds, paired comparison.

On the cluster #

176jobs320 hGPU hours reserved7,867 hCPU hours reserved19 May – 28 Julperiod (2026)
Figures for the line, between May and July. Two people share the pipeline.

The big sweep (three architectures by ten seeds by condition) was split into two 41-hour jobs on the H200, each with five seeds and resumable by progress. The July ablations are jobs of one to ten hours on the generic partition, with the time estimated by hand in the comment and adjusted after the first run.

Jobs by typeMulti-seed trainingMulti-seed training: 116 · 66 %116 · 66 %Input-attribute ablationInput-attribute ablation: 19 · 11 %19 · 11 %Tests and debuggingTests and debugging: 13 · 7 %13 · 7 %InferenceInference: 13 · 7 %13 · 7 %Inference-time ensembleInference-time ensemble: 11 · 6 %11 · 6 %Base models (May)Base models (May): 3 · 2 %3 · 2 %Density ablationDensity ablation: 1 · 1 %1 · 1 %
Jobs by type: multi-seed training dominates in number; the ablations are few and deliberate.

In the sixth instalment , medical imaging and an array of a hundred seeds.

Figures from Slurm accounting (reserved capacity, not measured usage) and the archived sbatch files. Anonymised post: no identifiable users, paths, emails or project names. Quotations are from the script comments.