This is a discussion on PCL...
- Use the ponitCloud with the Keypoints (not with indices, with the XYZ information, just as you mention)
- Use them as input at the Feature Estimator, but I also set as *SearchSurface* the initial full pointcloud! that means that (ig I get it right) you find the keypoints, then for the XYZ location of each keypoint, it goes at the initial cloud (with the full information) and computes stuff there.
cloudVector_UNorg_PN - full pointCloud (actually vector of Pointclouds<>::Ptr), with Normals, it is unorganized, because I remove NaN points and Normals
KEYptVector_UNorg_P_ - Keypoint Pointcloluds (actually vector of Pointclouds<>::Ptr)
FEATtVector_UNorg_P_ - Feature Pointcloluds (actually vector of Pointclouds<>::Ptr)
If other people have different opinion, please comment :)
std::cout << "//// KEYpoints" << std::endl;
{
// Fill in the model cloud
// Compute model_resolution
pcl::ISSKeypoint3D< pcl::PointXYZRGBNormal, pcl::PointXYZRGBNormal> keyPointDetector;
pcl::search::KdTree::Ptr tree (new pcl::search::KdTree );
model_resolution_Target = static_cast( computeCloudResolution( cloudVector_UNorg_PN[iii] ) );
keyPointDetector.setSearchMethod( tree);
keyPointDetector.setSalientRadius( PARAM_KEYP_coeffSalientRadius * model_resolution_Target);
keyPointDetector.setNonMaxRadius( PARAM_KEYP_coeffNonMaxRadiuss * model_resolution_Target);
keyPointDetector.setThreshold21( 0.975);
keyPointDetector.setThreshold32( 0.975);
keyPointDetector.setMinNeighbors( 5);
keyPointDetector.setNumberOfThreads( 4);
pcl::PointCloud::Ptr TMPPP_keyPt_UNorg_P_(new pcl::PointCloud);
keyPointDetector.setInputCloud( cloudVector_UNorg_PN[iii] );
keyPointDetector.compute( *TMPPP_keyPt_UNorg_P_ );
KEYptVector_UNorg_P_.append( TMPPP_keyPt_UNorg_P_ );
}
std::cout << "//// Feature Estimation" << std::endl;
{
pcl::search::KdTree::Ptr tree (new pcl::search::KdTree);
pcl::SHOTColorEstimationOMP< pcl::PointXYZRGBNormal,pcl::PointXYZRGBNormal,keyPointTYPE > featureDescriptor;
featureDescriptor.setSearchSurface( cloudVector_UNorg_PN[iii] );
featureDescriptor.setInputNormals( cloudVector_UNorg_PN[iii] );
featureDescriptor.setInputCloud( KEYptVector_UNorg_P_[iii] ); // --->> Comupte Features ONLY @ Keypoints !!!!!!!!!!!!!!!!!
featureDescriptor.setSearchMethod( tree );
featureDescriptor.setRadiusSearch( PARAM_FEAT_coeffRadiusSearch * model_resolution_Target );
featureDescriptor.compute( *TMPPP_featt_UNorg_P_ );
FEATtVector_UNorg_P_.append( TMPPP_featt_UNorg_P_ );
}
Hi Mustafa,
I was trying to do the same thing with you, in the end I ended up doing this: (If I'm wrong please correct me!!!)cloudVector_UNorg_PN - full pointCloud (actually vector of Pointclouds<>::Ptr), with Normals, it is unorganized, because I remove NaN points and Normals
KEYptVector_UNorg_P_ - Keypoint Pointcloluds (actually vector of Pointclouds<>::Ptr)
FEATtVector_UNorg_P_ - Feature Pointcloluds (actually vector of Pointclouds<>::Ptr)
**_PN** means Point and Normal
typedef pcl::SHOT1344 keyPointTYPE; // float descriptor [1344] || float rf [9]
QVector< pcl::PointCloud::Ptr > cloudVector_UNorg_PN;
QVector< pcl::PointCloud::Ptr > KEYptVector_UNorg_P_;
QVector< pcl::PointCloud< keyPointTYPE >::Ptr > FEATtVector_UNorg_P_;
(you can get away without using vectors of course, this is for my needs only)
Please have a look at the code snippet. The result that I'm getting is pretty expected.QVector< pcl::PointCloud
QVector< pcl::PointCloud
QVector< pcl::PointCloud< keyPointTYPE >::Ptr > FEATtVector_UNorg_P_;
(you can get away without using vectors of course, this is for my needs only)
After this stage, before finding correspondences, be sure to kick out all the Nan or Inf things at your Keypoints and Features!
If you delete a Feature, delete also the correspoding Keypoint!
There is an 1-1 relation between the Keypoint-Cloud and the Feature-Cloud
If there is a way to work with indices, I would be interested too.
Best,
dimitris
std::cout << "//// KEYpoints" << std::endl;
{
// Fill in the model cloud
// Compute model_resolution
pcl::ISSKeypoint3D< pcl::PointXYZRGBNormal, pcl::PointXYZRGBNormal> keyPointDetector;
pcl::search::KdTree
model_resolution_Target = static_cast
keyPointDetector.setSearchMethod( tree);
keyPointDetector.setSalientRadius( PARAM_KEYP_coeffSalientRadius * model_resolution_Target);
keyPointDetector.setNonMaxRadius( PARAM_KEYP_coeffNonMaxRadiuss * model_resolution_Target);
keyPointDetector.setThreshold21( 0.975);
keyPointDetector.setThreshold32( 0.975);
keyPointDetector.setMinNeighbors( 5);
keyPointDetector.setNumberOfThreads( 4);
pcl::PointCloud
keyPointDetector.setInputCloud( cloudVector_UNorg_PN[iii] );
keyPointDetector.compute( *TMPPP_keyPt_UNorg_P_ );
KEYptVector_UNorg_P_.append( TMPPP_keyPt_UNorg_P_ );
}
std::cout << "//// Feature Estimation" << std::endl;
{
pcl::search::KdTree
pcl::SHOTColorEstimationOMP< pcl::PointXYZRGBNormal,pcl::PointXYZRGBNormal,keyPointTYPE > featureDescriptor;
featureDescriptor.setSearchSurface( cloudVector_UNorg_PN[iii] );
featureDescriptor.setInputNormals( cloudVector_UNorg_PN[iii] );
featureDescriptor.setInputCloud( KEYptVector_UNorg_P_[iii] ); // --->> Comupte Features ONLY @ Keypoints !!!!!!!!!!!!!!!!!
featureDescriptor.setSearchMethod( tree );
featureDescriptor.setRadiusSearch( PARAM_FEAT_coeffRadiusSearch * model_resolution_Target );
featureDescriptor.compute( *TMPPP_featt_UNorg_P_ );
FEATtVector_UNorg_P_.append( TMPPP_featt_UNorg_P_ );
}
Dimitris Tzionas
On Sun, Oct 6, 2013 at 11:20 PM, Mustafa Mohamad <mustafa.mohamad@gmail.com> wrote:
Hi,I am trying to get the indices of the detected keypoints using the ISS keypoint detector. The compute method of the ISS detector returns a cloud of the actual keypoint values. However, I need the indices so that I can calculate local shape descriptors for those points in the original cloud.There must be something very basic I am missing.Mustafa
RogerKing 
My questions are mainly on the construction of the decision tree from the training images.
1. The minimization of the entropy function is used only for creating the decision tree?
2. Does the training set needs to be annotated? (I guess not, since all 16 pixels are checked)
3. I assume that with very few training samples (corners), a very simple decision tree will be created. When new corners are trained, how is the tree expanded? (maybe the answer is in the paper, I haven’t been able to figure it out yet)
Thanks.
bsdbbddbsdbsbdsb