QSM model - advanced stops working at 98%
I am using the QSM model approach and followed the instruction on in the youtube videos. The QSM model is running smooth (I reduced the data to segments with at least 5000 points) until it reaches 98% then it stops. There is no error message or anything it just does not continue. I can already view the cylinders in the program but I cannot export anything as the program thinks the process is still not ready yet. Did I miss something? What could be the reason for this interruption. I am using computree 4.0.759 on a windows10 64bit system.
that is strange. What you described is too my knowledge impossible. If you can view the cylinders in the program, that means the step did terminate successfully in all cases which I know. Somebody correct me please if I am wrong. To my knowledge Computree core allows only access like visualization of the output result after successful computation.
Are you sure this is not just something similar to a graphic bug (98 instead of 100 displayed, but in reality 100%). If garanteed no follow up step like allometric correction or export can be executed, there is something wrong. What you could do:
1) Identify the last tree (that should be the last 2 % maybe if you have ~50 trees) by name. If you work on plot level, just export all clouds before the modeling step. Then make a second script. Import→QSM→QSM correction→export. You have a log file which gives information about either the last or the ongoing computation in Computree. The display log will not help, you need the file. Here there is some internal progress of the single tree clouds (same name as saved on your harddisc) included. You need to look for a file name where most likely the last entry was something like:
“fileXYZ - the Downhill simplex method started with parameters:” (a big matrix is displayed).
What each other filename should show after the respecting message, but not necessarily directly afterwards
“fileXYZ - the Downhill simplex method ended with parameters:” (another big matrix..)
You need to look for the filename not having the second message presumingly. It could be a tree cloud where the fitting performs incorrect and therefore super slow or it is a super complex tree which takes long cause you go in the order of 100k fitted cylinders. Maybe you can manipulate this cloud manually or just count it as a failed fit and use only DBH/height for prediction from ONF steps. There is no garantee this procedure works.
- If the above case is true, you could also try to pay with a lot more computation time. Case 1 will produce nonsense result, but Case 2 a usable one. Let your pipeline run over as many days as possible. Or voxelgrid downscale to 2-2.5 cm this single tree. Try out 2.5 cm first.
Please upload the log I talked about in case both suggestions do not work.
I do not have Computree environment set up to debug something at the moment, but I might be still able to provide you with a workaround solution if I can read the according log.
Thank you very much for your reply. It seems like, that it was only a graphical bug. As I could now export the parameter. Do you have any experience how you algorithm works on very dense stands?
more dense is relative, but for sure in general an increasing difficulty factor. It means more occlusion and also in non occluded areas my segmentation can handle interacting crowns only to a hard to quanitfiable limit. The segmentation error occurs first in the pipeline, the DTM is hopefully not effected. You can try to decrease it if observed by playing a bit with the parameters. There is adjustment possibilities. The cloud itself will also be more likely to contain larger amount of noise. This is also visually controllable and a bit by trial and error adjustable. Please notify here, that I recommend in case of needles or leaves manually interacting with the pipeline. I have implemented Belton et al. and a method based on those with replacing Beltons feature space with one of the PCL features .
You need to visually check carefully the quality of the segmented and prepared input clouds. Remove smaller trees if needed. Prefer to denoise hard, e.g. produce more “occluded areas” rather than leaving too much noise. I consider noise more negative impactful than occlusion for my QSM method.
If you have really good quality clouds and the QSMs look convincing, you can use total volume.
Allways check if you are unexperienced in visually interpreting point cloud data as well as my QSMs my 36Linvalue trees. You have access to GT data as well as to denoised and undenoised clouds. This is really high quality data but you need to make finally a judge call how your data quality comes close or not to that data.
In case your build QSMs do show too large errors stick to those cylinders which are tagged in the ply output as good. I explain a lot of details about the recommended steps at my youtube tutorial channel.