Process Killed at generateEllipsoids - KDTree stage during raycombine min (416M points)

[msacee2012-a11y]

Hello,
I am processing high-resolution BLK360 forest data ("All Quad Trees March 2025"). I have successfully completed the import, 10cm alignment, and rayrestore steps. I am now trying to merge two high-resolution restored clouds into a master file.

But the Problem is even when using the min flag and a 10 rays threshold, the process is terminated (Killed) by the OS/Docker during the KDTree construction phase.

This is what I found:
root@fb0ff9205d61:/data# raycombine min "Part1_Full_restored.ply" "Part2_Full_restored.ply" 10 rays -o "All_Quad_Master.ply"
reading: Part1_Full_restored.ply (385,271,532 rays)
reading: Part2_Full_restored.ply (30,806,170 rays)
...
fillRayGrid 385271532 / 385271532 247617.76s
fillRayGrid 30806170 / 30806170 11829.853s
generateEllipsoids - KDTree 0 / 2Killed

My PC Configuration:

• CPU: 3.1 GHz 16-core
• RAM: 256 GB
• Storage: 4 TB SSD
• Environment: Running inside a Docker container

My Quaries:

1. If I skip "raycombine min" and use "raycombine all" to avoid the KDTree comparison logic, will this negatively impact my DBH results in rayextract trees?
2. Given I have 256GB of RAM, why is the KDTree stage triggering an OOM Kill? Is this a known limitation for datasets exceeding 400M points, or likely a Docker resource constraint?
3. If raycombine min is essential for the best tree segmentation results, is there a recommended way to process these massive clouds (e.g., pre-decimating Part 1 to 1cm) without losing the structural detail required for parabolic cylinder fitting?
   I have searched similar discussions but haven't found a solution. Any advice on Docker flags or workflow adjustments would be greatly appreciated.

[tim-devereux]

Hi there,

1. No this will not effect DBH results, you'll end up with more points by using raycombine all. It's worth noting that the DBH metric is taken from the tree models, not directly from the point data. It underestimates DBH on trees with tapered stems.

2. Likely a bug in raycombine min.

3. Given that you have a decent machine, I would be combining all scan positions with raycombine all, then decimate the merged raycloud to 2cm with raydecimate.

I don't think these issues will have anything to do with Docker.

The algorithm is less sensitive to sparse data than other QSM methods, I would recommend reading this paper to understand how the branch segment fitting works, and also the limitations of the DBH metric from treetools -

Devereux, T., Lowe, T., Rivory, J., Reckziegel, R. B., Calders, K., Aryal, R. R., Eaton, G., Cooper, Z., Levick, S., Phinn, S., & Woodgate, W. (2026). RayExtract: A fast, scalable method for tree volume reconstruction from terrestrial laser scanning. Remote Sensing of Environment, 334, 115162. https://doi.org/10.1016/j.rse.2025.115162

[msacee2012-a11y]

Thank you very much for your prompt reply and suggestions. I want to let you know the outcome soon.

[thomas-lowe]

raycombine all has a fixed RAM cost, but unfortunately the more advanced forms of raycombine require the whole cloud to be loaded into RAM and then nearest neighbour processing, which stores about 20 neighbours per point.

There are two ways you could proceed:

1. just use raycombine all, you only need min if you want to get rid of differences
2. grid the cloud with raysplit grid then call raycombine min on shared tiles (same suffix), then call raycombine all on the tiles

When you come to rayextract trees note that results are barely better for less than about 5 cm between points.

[msacee2012-a11y]

Thanks a lot for the kind reply and suggestions. I will get back with my research outcome soon.