"stemPoints" and "pixel_size" parameter definition

[bruno-miguez]

Hello! Congratulations for the TreeLS Package! It has been very useful for me.

I am trying to measure the Diameter at Breast Height (DBH) of some trees in my forest point cloud data, which I've aquired using UAVs RGB images. I have processed it using Structure From Motion (SfM) photogrametric technique to build the point cloud.

Working with this data I am having some doubts about the parameters selection both in "stemPonits" and "sgmt.ransac.circle". Starting with "stemPonits" and its "pixel_size" parameter, I have noticed that depending on my choice of the "pixel_size" parameter, it also changes a lot the result of my "sgmt.ransac.circle" result.

For example:

If I choose "0.02" for the "pixel_size" I have this following stemPoints classification, which then gives me a smaller DBH (0.16m radius) as a result of the "sgmt.ransac.circle":

Otherwise, if I choose "0.01" for the "pixel_size", I have the following stemPoints classification, which gives me a bigger DBH(0.19m radius) as a result of the "sgmt.ransac.circle":

In this case, the perfect choice has been actually a 0.015 "pixel_size", which I know because I have the "ground truthing" of this tree.

Now, dealing with another trees, it has changed a bit, and for those ones, which I don´t have the "ground truthing", I am having some doubts about what would be the best "pixel_size" parameter to choose.

Could you help me with this doubt?

Thanks,

Bruno Miguez

[tiagodc]

Hi Bruno, thanks for using the package, and to answer your question I have to build a bit of context:

I designed and tested the methods on TreeLS on high resolution LiDAR point clouds from static TLS surveys. Those point clouds have very high point accuracy, with little noise and artifacts, with a very clear view of the objects, thus allowing an "easy" detection and measurement of tree features such as stems, yielding robust and stable results even when using methods heavily based on randomization (e.g. RANSAC).

The snapshots you provided here show some clearly noisy point cloud segments. This is common when using setups with scanners of lower accuracy and/or were obtained using UAVs. You can still use TreeLS on such point clouds, but the high noise on the stem segments clouds will affect the results, in the sense that measuring the diameter of the same point cloud section can yield a wide range of values.

I've been aware of this issue for some time and the current development branch of TreeLS already has implementations that make diameter estimations more stable, even for noisy point clouds. I have to retake the work on the development branch though, so it might take sometime for the next stable release.

In the meantime, if you don't feel comfortable exploring my unfinished work on the dev branch, you can try to account for the noise uncertainties by classifying/measuring the same stem segments multiple times and taking the mean value of the multiple diameter estimations as the actual result.

As for the _pixelsize parameter, picking the best value is a subjective task that depends on the user's interpretation, but in general I would say it is related to the sensor's point precision. For instance, if your point cloud was generated from a Velodyne sensor, its point precision is about 2cm, so using a pixel size of 1cm would not be advisable, since it searches for circles on a grid that is more precise than the point cloud itself. Overall, the visual inspection of the results is an important step to verify the effectiveness of different parameters.

TreeLS was not originally conceived to perform on UAV point clouds, so I'm actually quite happy to hear that it is getting there. Hopefully the improved methods on the next version will be better suited for those clouds also!

Cheers

[bruno-miguez]

Thank you very much for your answer Tiago! It has helped a lot.

I understand perfectly what you mean about the noisy and challenging point cloud I have provided.

Using the same technique, with the same trees, but way closer to the trees, we have achieved better results, with which TreeLS has worked very well as you can see below:

However, even with the noisy clouds we are getting closer to good results, and so we are assessing how much these more "cost-efficient" data (obtained with UAVs higher flights) is worth it for our case of study.

I am just starting with R, so I don´t think I could go much far with the current development branch of TreeLS. Anyway I am going to have a look and check what I could do! It is great to know that it is already being developed!

Thanks a lot for the attention and tips about the _pixelsize parameter!

Going to another doubt about the phrase: "classifying/measuring the same stem segments multiple times and taking the mean value of the multiple diameter estimations as the actual result"

I have done it first, but now I am doing different: Once I am satisfied with the "stemPonits classification", instead of run the "sgmt.ransac.circle" multiple times using a "n=20" points of my 500 points segment for example, I am running it with a "n=300" points for example. Doing it I increase my "error", but decrease the oscillation of the diameter estimation results.

What do you think about it ? Does this way work well in your opinion ? Or is it better to run multiple times and take the mean value ?

Talking about the "error", just to check, it is given in "meters" right ?

[tiagodc]

Glad I could help, and setting large n values for the RANSAC methods greatly increases the processing time. Both alternatives are fine, so generally you should pick the one that works faster.

And the error is given in point cloud units, which is usually meters.

Cheers

[bruno-miguez]

Great! Thanks Tiago !