Connected Component - grid step of octree levels

[Buczer]

Hi!

At first of all, thanks for the great software. CC is a monster of speed and helps me a lot with my PhD works :-)

I write here because generally, I have a problem with setting of octree level parameter in the Connected Component algorithm.

I would like to use Connected Component segmentation on multiple point clouds via command-line interface but I noticed that each of my point clouds has a little different grid step size on the same octree levels. For example, point cloud #1 at octree level 9 has a grid step of 0.02 m and point cloud #2 at octree level 9 has a grid step equals 0.05 m

Is there the possibility to estimate/calculate for a given point cloud what will be the grid step at a given octree level?

I need to segment all my point clouds with the same grid step = 0.01 because then the results of segmentation are the best.

Can someone help?

Perhaps it would be a good idea to develop this tool by allowing the option to define not only octree level but optionally also by the grid step parameter

Thanks in advance for all help.

Best regards

[WargodHernandez]

Someone would need to implement a new command line parameter for that. CC in the UI can create octrees with a predefined size per level (select a cloud then follow the menu items: Edit->Octree->Compute. when the dialog appears select "cell size at max level").

if you want to modify the command yourself you can find it starting at line #1058 in ccCommandLineCommands.cpp
I expect you will need to create a CCCoreLib::DgmOctree that is setup how you expect and then pass it to CCCoreLib::AutoSegmentationTools::labelConnectedComponents function call on line #1121

[Buczer]

Is there the possibility to estimate/calculate for a given point cloud what will be the grid step at a given octree level?

I solved this problem in R programming language. I'm pretty sure that if someone has some skills in any programming language in which he processes point clouds he will be able to reproduce these functions.

The results for grid_step differ slightly from those of CC but in my case they are sufficient.

I work with LAS files and all you need is a lidR library to load and work with point clouds in this format.
Function "check_octree_levels" returns data.frame with values of "octree level" and "grid step" for a given level.

Below the code,

Code: Select all

library(lidR)

create_bbox_xyz= function(lidR_pc){
  
  bbox_xyz= as.data.frame(lidR_pc@bbox)
  bbox_xyz[3,1]= min(lidR_pc@data$Z)
  bbox_xyz[3,2]= max(lidR_pc@data$Z)
  row.names(bbox_xyz)[3]='z'
  
 
  return(bbox_xyz)
  
}


get_size_octree_unit= function(bbox_xyz){
  
  oct_xyz= data.frame(matrix(nrow=3, ncol=3))
  row.names(oct_xyz)= c('x','y','z')
  names(oct_xyz)= c('min','max','grid_step')
  
  
  x_range= bbox_xyz[1,2] - bbox_xyz[1,1]
  x_half= x_range/2 
  
  y_range= bbox_xyz[2,2] - bbox_xyz[2,1]
  y_half= y_range/2 
  
  z_range= bbox_xyz[3,2] - bbox_xyz[3,1]
  z_half= z_range/2 
  
  
  oct_xyz[1,1]= bbox_xyz[1,1] 
  oct_xyz[1,2]= bbox_xyz[1,1] + x_half
  oct_xyz[1,3]= x_half
  
  oct_xyz[2,1]= bbox_xyz[2,1] 
  oct_xyz[2,2]= bbox_xyz[2,1] + y_half
  oct_xyz[2,3]= y_half
  
  oct_xyz[3,1]= bbox_xyz[3,1] 
  oct_xyz[3,2]= bbox_xyz[3,1] + z_half
  oct_xyz[3,3]= z_half
  
  
  return(oct_xyz)
}


check_octree_levels= function(bbox_xyz, max_octree_level= 21){
  
  octree_list= list()
  
  oct_df= data.frame(matrix(ncol=2, nrow= max_octree_level))
  names(oct_df)= c('octree_level','grid_step')
  
  tmp= bbox_xyz
  
  for (i in 1:max_octree_level){
    
    
    octree_list[[i]]= get_size_octree_unit(tmp)
    
    tmp= octree_list[[i]][,1:2]
    
  }
  
  
  
  for (o in 1:max_octree_level){
    
    oct= octree_list[[o]]
    
    oct_df[o,1]= o
    oct_df[o,2]= as.numeric(round(oct[3,3],5))
    
    
  }
  
  
  return(oct_df)
}




pc= readLAS("F:\\point_cloud.laz")


bbox_xyz= create_bbox_xyz(pc)
bbox_xyz

octree_levels= check_octree_levels(bbox_xyz)
octree_levels