Performance issue from GetRegistrationResultAndCorrespondences about open3d HOT 17 CLOSED

EstimateNormals may call SearchHybrid is proper search parameter is given.

from open3d.

The problem may also be due to #pragma omp critical.
Sometimes I notice crash when calling it. In a different project.

from open3d.

That's correct. I just comment omp critical clause, and able to see 100% utilization of the CPU.

I was also able to get 100% utilization if I just comment this line:

result.correspondence_set_.push_back(Eigen::Vector2i(i, indices[0]));

It is obvious that this dynamic memory allocation within OpenMP part prevents CPU parallelization. Looking into this issue.

from open3d.

The problem is that there might be a race condition if we don't claim omp critical.

from open3d.

Some notes:

• I made GetRegistrationResultAndCorrespondences parallel, but the performance gain is not as much as I expected.
• Another bottleneck I found is RANSAC loop in RegistrationRANSACBasedOnFeatureMatching.
• I parallelize it, and gets about 10x performance gain with my workstation! I had to assign different random seed for each thread. I also reorganized the RANSAC structure bit.
• However, the accuracy is slightly worse than single thread RANSAC. I am still investigating on this.

from open3d.

addressed in #99
Follow up work: benchmarking accuracy.

from open3d.

I got this result from benchmark.

Method	 	Recall		Precision
---------------------------------------
opencv	 	5.3%		1.6%
4pcs		20.0%		8.9%
super4pcs 	17.8% 		10.4%
pcl		44.9% 		14.0%
pcl_modified 	59.2% 		19.6%
open3d	 	52.6% 		12.7%

@qianyizh: Do you have any suggestion for improving this result? I remember when you implement FPFH, there was somewhat different from PCL. Can you also check #99 and see the parameters are properly set?

from open3d.

What is the single thread running speed of Open3D comparing with PCL?

Try to add:
CorrespondenceCheckerBasedOnNormal(0.52359878)
to the CorrespondenceChecker list.

from open3d.

Try to add: CorrespondenceCheckerBasedOnNormal(0.52359878)

Remarkable precision improvement but loses recall. See 'open3d_n' below:

Method	 	Recall		Precision
---------------------------------------
opencv	 	5.3%		1.6%
4pcs		20.0%		8.9%
super4pcs 	17.8% 		10.4%
pcl		44.9% 		14.0%
pcl_modified 	59.2% 		19.6%
open3d	 	52.6% 		12.7%
open3d_n 	44.8%		32.3%

from open3d.

Recall matches PCL, which is not bad.
What is the running time on single thread?
After all, RANSAC is a trade-off between running time and accuracy.

Actually, try to remove max_validation. If our implementation is correct, it should now match exactly pcl_modified. So both running time and accuracy should match.

from open3d.

Actually, try to remove max_validation. If our implementation is correct, it should now match exactly pcl_modified.

I removed validation in RANSAC loop but I got exactly the same result as 'open3d_n'
Quick question: what is this parameters you used for pcl_modified?
I am using followings:

• ransac max_iteration = 400000
• downsampling = 0.04
• normal estimation radius = 0.1
• feature radius = 0.25

I looked at code in ElasticReconstruction. They have smart_swap and inler_fraction, inlier_number for the RANSAC convergence criteria. Open3D does not have it though. Do you think we can add these too?

What is the running time on single thread? So both running time and accuracy should match.

I still working on computational time as I need to setting up few things for PCL.

from open3d.

I tweaked parameters to make consistent with 'ElasticReconstruction' and got

Method	 	Recall		Precision
---------------------------------------
opencv	 	5.3%		1.6%
4pcs		20.0%		8.9%
super4pcs 	17.8% 		10.4%
pcl		44.9% 		14.0%
pcl_modified 	59.2% 		19.6%
open3d	 	52.6% 		12.7%
open3d_n 	44.8%		32.3%
open3d_n 	41.0%		35.6%

from open3d.

I think the current symptom is that we have high precision and low recall. This usually means:

1. Our validation or pruning is too strict, it rejects many bad alignments (thus higher precision) but also some mediocre alignments (thus lower recall)
   Or
2. Our iteration number is too low. With x trials, we are able to find all the easy alignments. But with additional y trials, we can find some hard alignments and also more false positives.

So I really want to see the running time comparison between our method and PCL first. If they are similar, then it is more likely to be 1 than 2. Otherwise, 2 has a better chance.

from open3d.

@syncle any progress?

from open3d.

Haven't spend much time for this. I will work on this weekend.

from open3d.

I tested same point cloud for Open3D RANSAC and PCL RANSAC. When I set the same number of iteration, Open3D version slower than PCL RANSAC though it is parallelized.

Question: Do we need to have SearchKNN for every RANSAC loop in RegistrationRANSACBasedOnFeatureMatching? I guess we can just build correspondence list first and sample from it.

from open3d.

New results

Method	 	Recall		Precision
---------------------------------------
opencv	 	5.3%		1.6%
4pcs		20.0%		8.9%
super4pcs 	17.8% 		10.4%
pcl		44.9% 		14.0%
pcl_modified 	59.2% 		19.6%
open3d	 	52.6% 		12.7%
open3d_fix 	61.0% 		18.9%

What I did:
Take KNN function call out from RANSAC loop (x15 faster)
Uses the same parameter set of pcl_modified (x10 more RANSAC iteration)

from open3d.