PCL Developers blog
The Point Cloud Library (PCL) Developer Blogs represent a great way to keep track of daily updates in PCL sponsored code sprints. Our developers are blogging about their experiences and progress updates while working on exciting PCL projects.
The following shows the current list of ongoing code sprints. Click on any of the logos below to go to the respective sprint blog page.
The list of code sprints which have already ended is:
We would like to thank our financial sponsors for their generous support. For details on how to start a new code sprint or contribute to PCL, please visit www.pointclouds.org/about.html.
Latest 15 blog updates
Added the functionality to plot from polynomial. This occurred to me as a useful functionality a plotter class should have. User needs to provide a vector which stores the coefficients of the polynomial and range. PCLPlotter will plot and display them on the screen.
I still don’t have a good internet connection. I will post the snapshots later.
I am very happy that the training period of my job will get over by the end of next week. It won’t be hectic after that as the office hours will go to normal (Currently its like 12-14 hours :()
All important functionalities of PCLHistogramVisualizer are now incorporated in the PCLPlotter class. They are rewritten here so that this single class can take responsibility of all ploting related functionalities. The signatures of the PCLHistogramVisualizer functions are retained as of now so that one can directly use the PCLPlotter class with previous signatures to get similar result. I will post snapshots in the evening when I get a good internet connection.
I made some changes in pcd_viewer so that it can use this Plotter class instead of HistogramViewer. As signatures of the functions are same, the changes are minor; but the fact that it is now using this unified Plotter class. I will discuss with the community before committing the new pcd_viewer.
I really want to get some feedback about this Plotter class. Please update the trunk and use the class to plot something nonsense and tell me if you would like to have something in addition.
This filter recursively divides the data into grids until each grid contains a maximum of N points. Normals are computed on each grid. Points within each grid are sampled randomly and the computed normal is assigned to these points. This is a port from libpointmatcher.
In what follows, the time performances related to all the considered detectors have been collected with regards to the Stanford dataset 2 and graphically visualized to foster a better understanding. In our framework, time performances refer to the keypoint extraction time of each detector and different scales have been taken into account: 6, 9, 12, 15 * scene_resolution are considered. Results are given below.
I just got the results for the execution of tests on the Stanford dataset. All the tests (both on the Kinect and the Stanford dataset) have been executed on a 2nd generation Intel® Core™ i5 processor with a speed equal to 2.4 GHz (3 GHz if TurboBoost technology is enabled). The results regarding the repeatability measure confirm the superiority of the NARF detector on the others. The repeatability results are graphically shown below:
I didn’t choose PointT as the core data structure, since different algorithms will interact with PCLModeler requesting different point cloud types, so I decided to use PointCloud2 because it is a container of many fields. But now I found it’s not easy to support some functions, for example, updating a specified field, or adding some fields, the current code is messy because of the accommodation for PointCloud2. According to this thread, PointCloud2 is going to be deprecated, and the proposed point cloud type in PCL 2.x is much more friendly for PCLModeler. So I will drop PointCloud2 and re-design the core based on the proposed data structure.
Based on some discussions on how people would want to use the 2D module, there have been some changes in the API for this module. Images are now being represented in the point cloud format itself. 2D filters will extend the pcl::Filter inteface and 2D keypoints will extend the pcl::Keypoint interface. This will lead to a code structure more consistent with the rest of PCL.
This module does operations only on the RGB/Intensity channels of Organized Point Clouds. It ignores all x,y,z information for now. There are lots of features in PCL which deal with the x,y,z data. Now that the 2D module works with the same data-types, the user could use these existing features for processing the x,y,z information and the 2D module to process the RGB/Intensity information.
I’ve been focusing on designing and implementing this new API in the past few days. I’m also converting the code I wrote earlier to comply with this new API.
While being in Toulouse I had to sacrifice some of the time devoted to PCL, so this week I’m going to work hard in order to recover that time. Currently, I am testing the detectors on a synthetic dataset (the well-know Stanford dataset). Unfortunately, since this dataset does not contain the RGB information the only detectors under testing are: Harris 3D, NARF and uniform sampling. Indeed, those three detectors are characterized by having a shape-based saliency measure. As for the tests executed on the Kinect-based dataset, Harris 3D is evaluated with regard to all the possible different response methods. While the tests are executing, today I’ve decided to run up with my roadmap and I started to take some knowledge about the 3DGSS detector. In particular, the reference paper I’ve read is:
- John Novatnack and Ko Nishino, “Scale-Dependent 3D Geometric Features,” in Proc. of IEEE Eleventh International Conference on Computer Vision ICCV‘07, Oct., 2007.
Coming soon: the final evaluation results on the synthetic dataset.
Finally, I decided to decline the offer by the LAAS-CNRS and I’m still looking for a PhD position. Any suggestion about it?
The half-edge data structure is a popular representation for a mesh in which each edge is split up into two half-edges with opposite directions. The main topology information is stored in the half-edges. The vertexes and faces are not explicitly connected to each other because they can be reached through the respective half-edges. If one wants to find, for example all faces to which a vertex is connected to then it is necessary to go through all neighbouring half-edges and refer to the faces through them. Compared to explicitly storing references from each vertex or face to all of their immediate neighbours this has the advantage that the storage space per vertex, half-edge and face is constant while it is still possible to access the neighbourhood without an exhaustive search through the hole mesh. Another advantage is that the orientation of the faces is stored explicitly in the surrounding half-edges.
Half-edge connectivity:
The image above illustrates the connectivity information related to a specific half-edge (red), which explicitly stores indexes to
- the opposite half-edge (also called pair or twin)
- the next half-edge
- the previous half-edge (this is actually not a requirement of the half-edge data structure but it is useful for the implementation)
- the terminating vertex
- the face it belongs to
Other elements in the mesh can be reached implicitly (gray)
- originating vertex = opposite half-edge -> terminating vertex
- opposite face = opposite half-edge -> face
Vertex connectivity:
The image above illustrates the connectivity information related to a specific vertex (red), which explicitly stores an index to
- one of its outgoing half-edges
The corresponding incoming half-edge can be reached implicitly (gray)
- incoming half-edge = outgoing half-edge -> opposite half-edge
Although only one of the outgoing half-edges is stored the others can be reached by circulating around the vertex. Given any of the outgoing half-edges the next outgoing half-edge can be reached by
- outgoing half-edge = outgoing half-edge -> previous half-edge -> opposite half-edge (counter-clockwise)
- outgoing half-edge = outgoing half-edge -> opposite half-edge -> next half-edge (clockwise)
This procedure has to be continued until a full loop around the vertex has been completed. Similarly it is possible to use the incoming half-edge for the circulation
- incoming half-edge = incoming half-edge -> opposite half-edge -> previous half-edge (counter-clockwise)
- incoming half-edge = incoming half-edge -> next half-edge -> opposite half-edge (clockwise)
With a slight modification this allows us to access the vertexes or faces as well (only shown in counter-clockwise order)
- vertex = outgoing half-edge -> terminating vertex
- outgoing half-edge = outgoing half-edge -> previous half-edge -> opposite half-edge
or
- face = outgoing half-edge -> face
- outgoing half-edge = outgoing half-edge -> previous half-edge -> opposite half-edge
This procedure is continued until a full loop is completed. Using these basic operations it is possible to find all neighbours around a vertex, which is also called the one-ring neighborhood.
Face connectivity
The image above illustrates the connectivity information related to a specific face (red), which explicitly stores an index to
- one of the inner half-edges
The corresponding outer half-edge can be reached implicitly (gray)
- outer half-edge = inner half-edge -> opposite half-edge
As for the vertexes the other inner half-edges can be reached by circulating around the face
- inner half-edge = inner half-edge -> next half-edge (counter-clockwise)
- inner half-edge = inner half-edge -> previous half-edge (clockwise)
Each outer half-edge or vertex is referenced from its corresponding inner half-edge.
Boundaries
Boundaries can be represented by an invalid face index in the half-edge. It is important that both half-edges are kept in the mesh because else it would be no longer possible to access all neighbours. One can circulate around the boundary with
- boundary half-edge = boundary half-edge -> next half-edge (clockwise)
- boundary half-edge = boundary half-edge -> previous half-edge (counter-clockwise)
This is the same as circulating through the inner half-edges of a face with the only difference that the direction (clockwise, counter-clockwise) is reversed.
If the mesh has a boundary then one has to be very careful when accessing the faces through the half-edges in order to avoid dereferencing an invalid face index.
Manifoldness
I will talk about manifoldness in my next blog post.
Thanks to Radu and others, we have finalized the autoscript for compiling the OpenNI for Android. These are all integrated to the Android sample project. Also, we have compiled the PCL for android, and in the coming weeks we shall have a complete sample project. These can be used as our standard template for development of PCL + OpenNI on Android.
Happy Canada Day.
In what follows, the time performances related to all the considered detectors have been collected and graphically visualized to foster a better understanding. In our framework, time performances refer to the keypoint extraction time of each detector and different scales have been taken into account: 6, 9, 12, 15 * scene_resolution are considered. Results are given below.
As promised in a previous post I took the time and created a basic flow chart of the involved steps of segmenting around a fixation point. Upper part of the chart (getting a boundary map, setting input cloud etc. ) are steps that need to be implemented by whoever want to use the ActiveSegmentation class(example of this will be shortly available pcl/examples), steps in the lower part are implemented in the class. It is left to the users discretion to choose an appropriate boundary map. I chose to do it this to have a bigger flexibility, and because many others are working on edge/boundary detection at the moment. My test will be based on the already implemented Boundary detection (which works for ordered and unordered point clouds as well) and trying it out with mapping 2d edge detections to the 3d cloud.
- Flow Chart Active Segmentation
In my next post I will share some preliminary results as well.
I’m graduated from my University. Now I have master degree and I have enough time to work at project. I figured out and implemented in Matlab surface editing based on the coordinates of Laplace. This conversion is the basis of the method that I have to implement in the Code Sprint. Implemented algorithm is Laplacian Mesh Editing consists of the following steps:
- Based on information about the relative positions of surface points computed the Laplacian operator of the mesh.
- Fix points whose position should not change - “static anchors”.
- Choose the point, whose position should be changed, and specify the offset of its origin - “handle anchors”.
- Based on available information, we construct the normal equations. For the static anchors we set big weight, and for the handle anchors little weight.
- The new coordinates of the surface are calculated based on the method of least squares.
The results of the program are presented below.
Now I proceed to implement the algorithm from article “Template Deformation for Point Cloud Fitting”.
I’m currently visiting the LAAS-CNRS in Toulouse, in order to see if it could be a good place to me to accomplish PhD studies. While doing so, I’ve finished to test the detectors on the kinect-based dataset. Again, I want to say thank you to Bastian Steder for helping me on dealing with the NARF detector. Results are graphically shown below: