Adressing the errors in QSM

[ShukhratSh]

Hi Thomas,

I am trying to segment individual trees and generate QSM in one of my plots in Amazon rainforest. Despite I have a very dense TLS point cloud, there is some occlusion on top of the trees. TLS may not be able to capture the top of the canopy well in the case of dense and tall forests. QSM looks good in the ground layer and mid-story of the forest, however, I am exploring some serious issues (very thick and false branches) on top of the canopy where the occlusion is severe (image attached shows the errors in QSM on the top of the tall tree). I found that distance_limit and girth_height_ratio have a significant impact on segmentation results and QSM, but I wonder if you can help me reduce the error in QSM. Following tree segment and QSM were generated by the following script. rayextract trees file.ply file_mesh.ply --distance_limit 0.1 --height_min 2 --girth_height_ratio 0.1

Thank you

[thomas-lowe]

Hi ShukhratSh,
I don't think I will be able to fix the problem for the data in your image. rayextract trees expects the branches to have been observed and it looks like the canopy is so dense that the lidar is not penetrating far beyond the foliage.

Do Amazon trees drop their leaves at all? If so then scanning when the trees have fewest leaves is a good strategy. Otherwise getting the scanner underneath dense trees can sometimes help to see more of the branches from underneath the thick canopy.

Another idea is to try to remove any points that might be leaves, so that most of the points are real branch points (even if sparse). raycolour xxx.ply branches might work, it colours red/green based on return intensity (specialised for the Velodyne intensity range) and local cylindricality respectively. You can then use raysplit xxx_coloured.ply colour r,g,0 to try to cut out based on a combination of these two values.

Also, scanning far from midday may give you better range on your scanner.

FYI distance_limit 0.1 is quite low, that is probably why the tree hasn't found a path from the blue points to the rest of the black points on the canopy.

thanks.

[ShukhratSh]

Hi Thomas,

I appreciate your assistance. Unfortunately, collecting additional TLS data from the plots isn't currently feasible, so I'm making the best use of the available data. Regarding your suggestion to remove leaves, I've experimented with various combinations of r and b values, but, they didn't provide an accurate separation between leaves and wood in my dataset.

I've set the distance_limit to 0.1 to improve QSM, as increasing the limit results in more errors in QSM, especially with occluded top canopy data. While QSM looks promising with less occluded data, it tends to degrade as occlusion increases.

I wonder if it would be possible for raycloudtools not to generate QSM for heavily occluded trees, rather than quantifying inaccurate QSM. It would be good to get your insights.

Thank you

[thomas-lowe]

Hi ShukhratSh,
knowing what is and isn't a heavily occluded tree is hard to work out automatically.

The raycolour branches method uses neighbourhood cylindricality and return intensity, which is more reliable than colour in my experience. However in your image there are so few internal points that it would be very unlikely to fix the problem.

There are methods like Efficient Tree Modelling that use a prior model of the shape of a tree to direct the branches in low density regions, but it doesn't have code AFAIK and tends to give a false sense of security as it may look right regardless of whether there is enough data there.

I'm looking for improvements (and suggestions/pull requests) in this area, so maybe a better method will become available in this library. In the meantime my only suggestion is minor:

If you raydecimate x cm the cloud to roughly the inside-canopy the point spacing, then it should at least have equal preference for surface vs internal structure.

[ShukhratSh]

Hi Thomas,
Big thank you for your continuous support.
Please see attached screenshot. Branches of bigger trees are segmented as separate trees? I chnaged the distance limit (1, 1.5, 0.5) but had no improvement. Do you know how to avoid this?

Thanks,
Shukhrat

[thomas-lowe]

Hi ShukhratSh,
this doesn't make sense to me. If the path to the ground has a gap bigger than distance_limit then it will show up as black. The purple and green points must have a path to the ground, I'd be interested to see the reconstructed mesh to see where it thinks the ground is.

One possibility is that your ground mesh is wrong and gets up close to those coloured points. If so, then rayextract terrain gradient 0.5 or less might fix it.

[ShukhratSh]

Thanks very much Thomas. Ground mesh was incorrect and gradient 0.5 fixed it.

[ShukhratSh]

Hi Thomas,

I apologize for asking masking many questions. But, I want to process 6 ha TLS data (72 Gb after decimating to 2 cm) that is split into 10m tiles. I would run rayextract terrain and rayextract trees on those tiles, but obviously, there will be an edge effect. I think merging those tiles and splitting them with raysplit using a buffer is not an option for such a big file. I was wondering if you could give me an idea of how to run raycloudtools in this situation. Also, rayxetract terrain may give an incorrect terrain as the above case when the tiles have a lot of occlusion on the ground at the edge of the plots, especially in dense forests. It would be good to have your opinion on controlling the gradient parameter in this situation. Thanks a lot for your support.

[thomas-lowe]

No problem. Feedback is good.

I see your problem. Non-overlapping tiles are always going to have edge effects, that's why we support overlapping tiles (see scripts/rayextract_trees_large.sh for how to do it). So either the program that gave you those 10m tiles needs to be modified to output overlapping tiles, or you need to re-merge these tiles and use raysplit with the overlap option.

The problem is not really the raycombine but the raysplit, which can only hold about 250 file pointers open at once, so has to re-run the whole split operation for every 250 tiles. If you have a lot more than 250 tiles (e.g. more than 1000) then it will start to become quite inefficient. For both raycombine and raysplit you shouldn't run out of RAM as it is chunk-processed, but it could be slow.

I guess what you really want to do is write a batch file that takes each 10x10m tile and its surrounding 8 neighbours, runs raycombine, then runs raysplit with the overlap parameter, and keeps only the middle (larger) version of that tile. If your tiles have a locational naming convention then this sounds doable.

The other problem is that to remove all artifacts, your overlap needs to be about the radius of the widest tree, which could be as much as 8m. This would still work, but it should be more efficient to use a larger tile size so a smaller percentage of your space is overlap.

[sjshumack]

Hi Thomas,

I have a related query. Below is an input TLS cloud alongside the tree mesh output from rayextract trees using default settings. The tree is dead, so foliage is not an issue. For the most part, the branch structure is not bad, but there is a quirk that I wondered if you could help elucidate?

One of the branches, in particular, has a significantly exaggerated diameter. It doesn't seem to be attributable to things like unobserved points/occlusion, or misleading points.

Whole tree:

Up close:

Is this an inherent artifact of the optimisation process? Or deriving the branch radius from the voxel segment?
It doesn't seem to be an issue of branch angle, or of an abrupt change in point density.

Cheers,
Sam

[thomas-lowe]

Nice question Sam.
The reason is that rayextract trees is designed for the worse case of noisy/messy data where direct per-branch radius estimations cannot be relied on.

Because of this, it exploits two assumptions about trees, the first is that it branches according to Leonardo's rule, and the second is that branches are self-similar (their branch radii are proportional to their length). In your example above, the branch to the right is almost as long as the remaining trunk to the top, so has a similar radius.

An algorithm that gets accurate direct measurements on high quality scans (like yours) typically breaks badly on more difficult data (leaves, noise, wind). So I've gone for a 'reasonable radii on messy data' rather than a 'accurate radii on clean data' approach, and your example is a (hopefully rare) symptom of this approach.

[sjshumack]

Thanks, that's helpful. Appreciate the promptness.

""" An algorithm that gets accurate direct measurements on high quality scans (like yours) typically breaks badly on more difficult data """
""" 'reasonable radii on messy data' rather than a 'accurate radii on clean data' approach """

Makes sense. Although, that said, on face value your software has broader appeal than just functionality with messy data. Even with high-grade TLS data, for example, you make the case in the paper that a weakness in traditional QSM-based approaches is the need to identify tree instances before computing the QSM. Raycloudtools is far more efficient than alternatives.

"""The default distribution of radii in a bifurcation should probably respect the branching angles. Picking a smaller radius in the offshoot branch than the main stem."""

Nice idea. Look forward to hearing about it if you do get around to it.

[thomas-lowe]

Right. The philosophy is that data sets may have some high quality areas and some messy areas, and that it is better to get everywhere reasonable than optimise for just the high quality areas. That is a design decision. Ideally it would do both of course, but deciding whether your branch radius is good or unreliable, is itself unreliable.
Happy for suggestions too. Reliably estimating the radius is the crux of tree reconstruction.