zhangxy0517/3d-registration-with-maximal-cliques

Source code of CVPR 2023 paper

3D Registration with Maximal Cliques (CVPR23 best student paper award)

Source code of 3D Registration with Maximal Cliques.

Introduction

In this paper, we present a 3D registration method with maximal cliques (MAC). The key insight is to loosen the previous maximum clique constraint, and mine more local consensus information in a graph for accurate pose hypotheses generation: 1) A compatibility graph is constructed to render the affinity relationship between initial correspondences. 2) We search for maximal cliques in the graph, each of which represents a consensus set. We perform node-guided clique selection then, where each node corresponds to the maximal clique with the greatest graph weight. 3) Transformation hypotheses are computed for the selected cliques by the SVD algorithm and the best hypothesis is used to perform registration. Extensive experiments on U3M, 3DMatch, 3DLoMatch and KITTI demonstrate that MAC effectively increases registration accuracy, outperforms various state-of-the-art methods and boosts the performance of deep-learned methods. MAC combined with deep-learned methods achieves stateof-the-art registration recall of 95.7% / 78.9% on 3DMatch / 3DLoMatch.

Repository layout

The repository contains a set of subfolders:

• Linux - source code for Linux platform.
• Windows - source code for Windows platform.
• Python_implement - python implementation of basic MAC.
• demo - test point clouds.

Build

MAC depends on PCL (>= 1.10.1, version 1.10.1 is recommended) and igraph(=0.9.9). Please install these libraries first.

To build MAC, you need CMake (>= 3.23) and, of course, a compiler that supports >= C++11. The code in this repository has been tested on Windows (MSVC =2022 x64), and Linux (GCC =10.4.0). Machines nowadays typically provide higher support, so you should be able to build MAC on almost all platforms.

Windows version

Please refer to Compiling on Windows for details.

Linux version

Please refer to Compiling on Linux for details.

Python implementation

We provide a simple demo in python, please refer to Python_implement for details.

Usage:

• --help list all usages.
• --demo run the demo.

Required args:

• --output_path output path for saving results.
• --input_path input data path.
• --dataset_name[3dmatch/3dlomatch/KITTI/ETH/U3M] dataset name.
• --descriptor[fpfh/fcgf/spinnet/predator] descriptor name.
• --start_index(begin from 0) run from given index.

Optional args:

• --no_logs forbid generation of log files.

Datasets

All tested datasets can be found at this link, password：1234.

Results

U3M

3DMatch & 3DLoMatch

Benchmark	RR(%)	RE(°)	TE(cm)
3DMatch+FPFH+MAC	84.10	1.96	6.18
3DMatch+FCGF+MAC	93.72	1.89	6.03
3DLoMatch+FPFH+MAC	40.88	3.66	9.45
3DLoMatch+FCGF+MAC	59.85	3.50	9.75

KITTI

Benchmark	RR(%)	RE(°)	TE(cm)
FPFH+MAC	99.46	0.40	8.46
FCGF+MAC	97.84	0.34	19.34

Performance boosting

Projects using MAC

• Zhang et al., FastMAC: Stochastic Spectral Sampling of Correspondence Graph (CVPR 2024)

Citation

If you find this code useful for your work or use it in your project, please consider citing:

@inproceedings{zhang20233d,
  title={3D Registration with Maximal Cliques},
  author={Zhang, Xiyu and Yang, Jiaqi and Zhang, Shikun and Zhang, Yanning},
  booktitle={Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition},
  pages={17745--17754},
  year={2023}
}

3d-registration-with-maximal-cliques's Issues

配准问题

您好，我在配准两帧激光点云雷达的时候，当角度小于90度时候都能配准，当两帧点云旋转相差180度时候，运行程序 ，计算完graph construction， 程序结束，貌似是 Graph.norm() == 0)， 请问一下您测试的时候这种情况可以通过吗，或者该如何修改代码，目前我的correspondence设置是500个，downsample=0.7
registration(src_cloud, des_cloud, correspondence, ov_lable, folderPath, resolution, 0.99); //FPFH 0.95 or 0.9

calculate the optimal 6-DoF rigid transformation

Thank you for your excellent work! I have a question about the optimal 6-DoF rigid transformation. After obtaining a set of 6-DoF pose hypotheses, how to calculate the optimal 6-DoF rigid transformation, and the s(c_i) in equation(6) refer to which?

And in my opinion, the correspondence is only calculated by the initial feature match and not updated after, is the initial correspondence affecting the MAC method performance?

.

作者您好，我在结合FCGF和MAC在3DMatch数据集上测试了一下发现将体素大小设置为0.05的情况，部分最大团数量过多（2000万以上），这情况不知道您是否遇到，然后我将体素大小设为0.08，测试完和性能远不如原论文的性能，作者您当时是怎么解决这个问题的

关于物体匹配

请问作者这个适合物体匹配吗，目前在我自己的数据集上测试效果不佳

RE < 15 and TE < 30?

          The results of GeoTrans in Table 3 are same as the results in their original paper,  and GeoTrans uses RMSE < 0.2m and computes scene average recall. Your registration recall are computed by pair avearge recall and use RE < 15 and TE < 30?

Originally posted by @Pterosaur-Yao in #6 (comment)

Out of memory when testing 3DMatch Dataset with FPFH descriptors.

Sorry to bother you! But when I test it on the 3DMacth Dataset with FPFH descriptors, the code is always out of memory in a computer with 48GB RAM at the following loop:
macs = graph.maximal_cliques(min=3) ... clique_weight = np.zeros(len(macs), dtype=float) for ind in range(len(macs)): mac = list(macs[ind]) if len(mac) >= 3: for i in range(len(mac)): for j in range(i + 1, len(mac)): clique_weight[ind] = clique_weight[ind] + SCG[mac[i], mac[j]]
What is the problem? Any hyperparameters need to be adjusted? By the way, we also find that the FCGF descriptors lead to a quite long time cost? Is it normal? FYI, all the correspondences are generated based in the code from SC2-PCR or PointDSC, and following the parameter setups in both your an their papers.

Evaluation metrics in performance boosting experiments

Thank you for your excellent work. I have a question about the evaluation metrics in Table 3. "Performance boosting for deep-learned methods when combined with MAC.". The RR of GeoTrans and CoFiNet are computed by RMSE < 0.2, and how about your results of GeoTrans+MAC, it seems like computed by RE < 15 and TE < 30?

关于将MAC与深度学习方法融合的问题

作者您好！
我成功地将自己的数据集运用在MAC上，现在存在一些疑惑，希望您能解答！MAC的前提是获取对应的点对关系，这个关系通常是由特征描述符获得的，例如fpfh；请问MAC与深度学习方法结合也是如此吗？基于学习获取点云的特征描述算子，进而获取初始对应点对，再进行MAC配准。例如我想将FCGF或者Spinnet与MAC融合，是将网络获取点云特征，生成对应点对关系后的部分用MAC代替就可以了吗？

请问python版本的和linux版本的性能一致吗？

您好，感谢分享。

我想请问下，python的demo和linux的性能一致吗，能否认为python是linux的cpp版本的平替呢，在不考虑效率的情况下。谢谢

About U3M dataset

thanks for brilliant work!!

when i run "U3M" dataset, terminal shows these error message which i've never seen on other dataset :

(base) kuan@DESKTOP-S32DOQL:/mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/Release$ ./MAC --output_path /mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/output --input_path /mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/dataset/U3M --dataset_name U3M --descriptor fpfh --start_index 0 --no_logs false
Check your args setting:
output_path: /mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/output
input_path: /mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/dataset/U3M
dataset_name: U3M
descriptor: fpfh
start_index: 0
no_logs: 1
/mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/dataset/U3M/chef_view1.xyz /mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/dataset/U3M/chef_view2.xyz
Segmentation fault (core dumped)

it means my input path is wrong or the src[] and des[] space doesn't enough?

sincerely waiting for your reply!
thank you!!

error report in python version

Hi, I found that in some pairs of source and target point clouds, there exists an error.
Looking forward to your reply!
(pugeo) siyuren_21@ss420f:~/data1/siyuren_21/3D-Registration-with-Maximal-Cliques-main$ /home/siyuren_21/anaconda3/envs/pugeo/bin/python /home/siyuren_21/data1/siyuren_21/3D-Registration-with-Maximal-Cliques-main/main_rmc_1.py Graph construction: 12.66ms Search maximal cliques: 1973.51ms Total: 41546 After filtered: 4838 Traceback (most recent call last): File "/home/siyuren_21/data1/siyuren_21/3D-Registration-with-Maximal-Cliques-main/main_rmc_1.py", line 344, in <module> pred_trans,pred_trans1,spend_time=test(src_path,tgt_path) File "/home/siyuren_21/data1/siyuren_21/3D-Registration-with-Maximal-Cliques-main/main_rmc_1.py", line 283, in test batch_A = src_pts[list(macs[group[i][0]])][None] IndexError: list index out of range

About U3M dataset

Could you please provide the download link of the U3M dataset?
This dataset does not seem to be commonly used, why not experiment on the modelNet dataset?

error: conversion from ‘boost::shared_ptr<pcl::PointIndices>’ to non-scalar type ‘pcl::PointIndicesPtr’ {aka ‘std::shared_ptr<pcl::PointIndices>’} requested

Hi @zhangxy0517,

Congratulations and thanks for sharing your work. I am trying to compile MAC for testing it but I am getting the following error:

[ 14%] Building CXX object CMakeFiles/MAC.dir/main.cpp.o
[ 28%] Building CXX object CMakeFiles/MAC.dir/desc_dec.cpp.o
In file included from /usr/include/boost/preprocessor/control/if.hpp:18,
                 from /usr/include/boost/preprocessor/punctuation/comma_if.hpp:18,
                 from /usr/include/boost/preprocessor/comma_if.hpp:15,
                 from /usr/include/boost/mpl/aux_/preprocessor/params.hpp:49,
                 from /usr/include/boost/mpl/aux_/na_spec.hpp:26,
                 from /usr/include/boost/mpl/not.hpp:20,
                 from /usr/include/boost/mpl/assert.hpp:17,
                 from /usr/include/pcl-1.13/pcl/point_struct_traits.h:40,
                 from /usr/include/pcl-1.13/pcl/type_traits.h:40,
                 from /usr/include/pcl-1.13/pcl/memory.h:46,
                 from /usr/include/pcl-1.13/pcl/impl/point_types.hpp:41,
                 from /usr/include/pcl-1.13/pcl/point_types.h:354,
                 from /home/ttsesm/Development/3D-Registration-with-Maximal-Cliques/Linux/desc_dec.cpp:6:
/usr/include/pcl-1.13/pcl/registration/transforms.h:42:1: note: ‘#pragma message: This header is deprecated. Please include pcl/common/transforms.h directly. (It will be removed in PCL 1.15)’
   42 | PCL_DEPRECATED_HEADER(1, 15, "Please include pcl/common/transforms.h directly.")
      | ^~~~~~~~~~~~~~~~~~~~~
/home/ttsesm/Development/3D-Registration-with-Maximal-Cliques/Linux/desc_dec.cpp: In function ‘void SHOT_compute(pcl::PointCloud<pcl::PointXYZ>::Ptr, std::vector<int, std::allocator<int> >, float, std::vector<std::vector<float> >&, std::vector<LRF>&)’:
/home/ttsesm/Development/3D-Registration-with-Maximal-Cliques/Linux/desc_dec.cpp:25:43: error: conversion from ‘boost::shared_ptr<pcl::PointIndices>’ to non-scalar type ‘pcl::PointIndicesPtr’ {aka ‘std::shared_ptr<pcl::PointIndices>’} requested
   25 |         pcl::PointIndicesPtr Idx = boost::shared_ptr<pcl::PointIndices>();
      |                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ttsesm/Development/3D-Registration-with-Maximal-Cliques/Linux/desc_dec.cpp: In function ‘void FPFH_descriptor(pcl::PointCloud<pcl::PointXYZ>::Ptr&, std::vector<int, std::allocator<int> >&, float, std::vector<std::vector<float> >&)’:
/home/ttsesm/Development/3D-Registration-with-Maximal-Cliques/Linux/desc_dec.cpp:704:39: error: conversion from ‘boost::shared_ptr<pcl::PointIndices>’ to non-scalar type ‘pcl::PointIndicesPtr’ {aka ‘std::shared_ptr<pcl::PointIndices>’} requested
  704 |     pcl::PointIndicesPtr Idx = boost::shared_ptr<pcl::PointIndices>();
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [CMakeFiles/MAC.dir/build.make:90: CMakeFiles/MAC.dir/desc_dec.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/MAC.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

Any idea what could be the cause, I have installed the latest pcl version, i.e. pcl-1.13.1-1, I am using Arch linux.

数据集链接似乎失效了

作者您好，您给出的dataset链接似乎是无效的，我这边无法正常访问，不知是我的问题，还是链接已失效。

您好，关于demo运行时间问题

您好，我有些关于demo的运行时间问题，我在虚拟机上运行您的demo，graph生成时间只有40多秒，但是在双系统的ubuntu上却需要将近400s，请问是什么原因，pcl版本，ubuntu版本等等是一致的

请求提供更多的实验结果

论文中提到了在3DMatch/3DLoMatch上的SOTA结果 RR 95.7% / 78.9%

请问作者是否方便提供与之对应的其他指标，如FMR，IR，RRE，RTE等

feature_matching十分耗时

执行feature_matching时时间消耗很大

How to modify parameters when use lidar pointcloud

Thank you for your excellent work! I tried to use this algorithm for lidar point cloud of 16 scans. While I can not get correct transform. Should I modify some parameters for that. The picture is the transform result.

windows版本下运行demo出错

windows版本下用原点云，运行demo出错，Corres_Viewer_Score函数中 变量Hist_match运行结果为空

Fatal error, When I run the demo

Python test usage on custom point clouds

Hi @zhangxy0517,

Can you elaborate a bit how I can use the MAC on custom point clouds using the python implementation. Let's say I have pcd1.ply and pcd2.ply. If I understand correctly I need to first run the MAC binary that I have compiled to create the correspondence files and then feed these into the main.py script? Is that correct?

I think it would be nice if you could provide a step by step example given two pcds.

Thanks.

bad_alloc()

Dear authors,

Thank you for the open source.
We are using it to register two large point clouds, each about 1 million points.
The demo program is changed to load two custom point clouds from files.
Here is the log.

[pcl::VoxelGrid::applyFilter] Leaf size is too small for the input dataset. Integer indices would overflow.[pcl::VoxelGrid::applyFilter] Leaf size is too small for the input dataset. Integer indices would overflow.Computing FPFH feature...
Feature matching...
Start registration.
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

How do we fix it?

想请问下作者，这个方法可以用来做回环检测嘛？

Different results on Python and C++

Thank you for your excellent job.
When I tested the python version code on the custom dataset, it worked well, but I couldn't achieve the same effect on the C++ version. I only changed the downsampling rate. Is there any missing parameter that I need to modify?

最终RE，TE评估疑惑

作者您好，
最近在读您的这篇论文并成功复现了相关实验，效果很好！
但是在阅读源码中，对下面的关于RE和TE的评估部分感到疑惑。
按照代码来看，在完成MAC粗匹配后得到一个预测矩阵tmp_best，以及做完ICP精配准(SVD or WSVD)后得到best_est
之后使用evaluation_est函数与真值进行比较，然后挑选出来较好的那个作为最终结果。

但是问题就在于，正常情况下真值是未知的，不应该使用真值进行挑选！
这最终的评估方法是否存在问题，还是论文或者源码中有其他根据说明可以这样评估？
如能回复，不胜感激！

double new_re, new_te;
evaluation_est(best_est, GTmat, RE_thresh, TE_thresh, new_re, new_te);
if (**new_re < RE && new_te < TE**)
{
	RE = new_re;
	TE = new_te;
	cout << "est_trans updated!!!" << endl;
	cout << "RE=" << RE << " " << "TE=" << TE << endl;
	cout << best_est << endl;
}
else {
	best_est = tmp_best;
	cout << "RE=" << RE << " " << "TE=" << TE << endl;
	cout << best_est << endl;
}

corr.txt和corr_data.txt是如何生成的？

您好！
我是一名点云配准的初学者，非常感谢您在点云配准工作的贡献！我尝试在python版本中的example.py中使用自己的数据进行配准，想请教test文件夹中的corr.txt和corr_data.txt是代表这什么，它们是如何生成的，是否影响使用自己的数据配准效果？希望您可以解答一下。

请求提供geotransformer处理的3dmatch/3dlomatch数据集处理结果

在论文中GeoTransformer+MAC达到了95.7%的RR，在您发布的预处理数据集之中，我只找到了fcgf处理后的corr文件，能否提供geotransformer的corr数据呢？
此外我还遇到了一个问题，我在自己的数据集上进行测试，使用的是python_implement，然后发现有些情况下，明明corr的量很小(约3000)，但是找到的极大团数量却高达几千万个，速度很慢，不知道是什么情况。

python调用c++版本mac出现segmentation falut

    使用ctypes调用c++编译的动态库，但运行到kdtree设置输入点云时（setInputCloud函数）就会发生段错误，使用c++调用相同代码就不会出现问题。例如，python调用main中的demo()函数，运行到setInputCloud时便会出现问题。
    请问作者你遇见过这类问题没，有啥解决办法吗？
    环境：ubuntu18.04、pcl1.8.1（pcl1.10.0）

Graph Construction部分十分耗时

作者好！我在linux环境下运行demo的时候发现Graph Construction的部分耗时十分严重，但根据代码中用双loop的方式推算耗时时间是十分合理的。我看到作者的readme文件中Graph Construction的部分只用4s左右就完成了，想知道这部分该如何优化呢?

我的demo结果如下
Start registration.
graph construction: 515.753
coefficient computation: 3.88628
0.41525->min(0.41525 0.793482 1.66802)
clique computation: 0.442331
clique selection: 0.258489
hypothesis generation & evaluation: 5.12024
9716 : 521558
14 156.331
3.31526 3.29734 3.60479 3.54041 4.66473 5.57952 4.89386 5.40509 4.51781 4.51414 4.81748 5.44499 5.49566 4.15561
0.978359 -0.12634 0.163867 0.836844
0.136967 0.989035 -0.0552166 0.161963
-0.155095 0.076466 0.984936 0.106522
0 0 0 1

About README

Hi !
Thanks for your great contributions!

The current version of the README seems a bit unclear. I have trouble when I want to reproduce the SOTA results you have claimed, which are generated when combined with Geotransformer. Do you have any plans to update the README with some detailed instructions to reproduce the SOTA results? I think it would be helpful for many people who are interested in your work.

使用ros运行很卡或者段错误

您好，我将代码修改为一个ros订阅配准节点，多帧进行配准，运行会很卡，运行到FPFH_descriptor函数的时候，执行fpfh.compute (*fpfhs); 会报段错误，请问可能是什么原因？

如何加入GEO-Transformer框架？

您好！
非常感谢您的工作！我是一名学习点云配准的初学者，最近在研读您的文章，在文章里看到可以与GEOTransformer结合达到最先进的效果，这太让人振奋了！于是我想亲手做一下实验。但是我遇到了几个问题：
1.用哪个版本的MAC？
2.加入到其中哪个环节？
希望可以得到您的回答，非常感谢！

Dataset Query

@zhangxy0517
I appreciate your good work. I have a query regarding the Python demo data.
Can you please let me know from which dataset are the scans used for the Python demo? Is it a3dloc dataset?

Thanks

How to run this code?

mac端 c++版本 运行问题

您好！
首先对您在MAC上提出的想法非常感兴趣，觉得也非常的好，希望可以进一步借鉴相关**，谢谢
但是我个人在操作复现的时候出现了一些问题，想寻求您的指导，再次感谢

  问题描述：
  1）编译c++版本，环境：mac m1， 修改main.cpp中的路径，以及部分boost的随机取数。
  2）clion编译器、或者指令集编译   --demo
  3）报错的虽然和git有一个close的错很相似，但是感觉不是同样的

how to create corr_data, corr, GTmat.txt

Thank you for your code.
I tested your python script with example ply. It works fine.
But I am wondering how to create corr_data, corr, GTmat.txt files.

feature_matching部分耗时问题的优化

feature_matching函数的这个地方
pcl::PointCloud<pcl::SHOT352>::Ptr Feature_source(new pcl::PointCloud<pcl::SHOT352>);
pcl::PointCloud<pcl::SHOT352>::Ptr Feature_target(new pcl::PointCloud<pcl::SHOT352>);
用pcl::SHOT35类型维度太高了吧，好多位置都填充为0了，对于FPFH特征感觉可以采用pcl::FPFHSignature33类型。大概做如下改动，测试了一帧数据，发现确实可以减少feature_matching的耗时，输出的变换矩阵也是一致的。

void feature_matching(PointCloudPtr& cloud_source, PointCloudPtr& cloud_target,
vector<vector>& feature_source, vector<vector>& feature_targe, vector<Corre_3DMatch>& Corres)
{ int i, j;
pcl::PointCloudpcl::FPFHSignature33::Ptr Feature_source(new pcl::PointCloudpcl::FPFHSignature33);
pcl::PointCloudpcl::FPFHSignature33::Ptr Feature_target(new pcl::PointCloudpcl::FPFHSignature33);
Feature_source->points.resize(feature_source.size());
Feature_target->points.resize(feature_target.size());
for (i = 0; i < feature_source.size(); i++)
{
for (j = 0; j < 33; j++)
{
if (j < feature_source[i].size()) Feature_source->points[i].histogram[j] = feature_source[i][j];
}
}
for (i = 0; i < feature_target.size(); i++)
{
for (j = 0; j < 33; j++)
{
if (j < feature_target[i].size()) Feature_target->points[i].histogram[j] = feature_target[i][j];
}
}
//
pcl::KdTreeFLANNpcl::FPFHSignature33 kdtree;
vectorIdx;
vectorDist;
kdtree.setInputCloud(Feature_target);
for (i = 0; i < Feature_source->points.size(); i++)
{
kdtree.nearestKSearch(Feature_source->points[i], 1, Idx, Dist);
Corre_3DMatch temp;
temp.src_index = i;
temp.des_index = Idx[0];
temp.src = cloud_source->points[i];
temp.des = cloud_target->points[Idx[0]];
temp.score = 1 - sqrt(Dist[0]);
Corres.push_back(temp);
}
}

Problems with reproduction of registration results FPFH+MAC from the paper

Dear Mr. Zhang,
Thank you for the excellent paper, the very interesting approach and the fact that you have open sourced your implementation!

I am struggling to reproduce the results on KITTI with FPFH features that you have reported in the paper and hope you can help me find the parameters you have used. In the paper, you mention that FPFH+MAC has a recall of 99.46%. You do not further discuss whether you have done finegrain matching, so I will presume that you did not. As of today, I only manage to obtain a recall rate of ~76% so I think I must be doing something wrong.
To begin with, I am running this on Linux and am certain that I have the correct versions of the dependencies (PCL = 1.10.1, igraph = 0.9.9).

As you have already discussed in the following issue , I have adapted the registration code in the following manner:

// in my own calling class
PointCloudPtr src_cloud(new pcl::PointCloud<pcl::PointXYZ>);
PointCloudPtr des_cloud(new pcl::PointCloud<pcl::PointXYZ>);
PointCloudPtr new_src_cloud(new pcl::PointCloud<pcl::PointXYZ>);
PointCloudPtr new_des_cloud(new pcl::PointCloud<pcl::PointXYZ>);

// populate pointcloud ...
float src_resolution = MeshResolution_mr_compute(src_cloud);
float des_resolution = MeshResolution_mr_compute(des_cloud);
float resolution = (src_resolution + des_resolution) / 2;

double downsample = 0.3;
Voxel_grid_downsample(src_cloud, new_src_cloud, downsample);
Voxel_grid_downsample(des_cloud, new_des_cloud, downsample);

std::vector<std::vector<float>> src_feature, des_feature;
FPFH_descriptor(new_src_cloud, downsample * 5, src_feature);
FPFH_descriptor(new_des_cloud, downsample * 5, des_feature);

std::vector<Corre_3DMatch> raw_correspondence, correspondence;
feature_matching(new_src_cloud, new_des_cloud, src_feature, des_feature, raw_correspondence);

// randomly downsample correspondences
vector<int>rand_idx;
boost_rand(5000, 0, (int)raw_correspondence.size() - 1, 5000, rand_idx);
for(int i = 0; i< 5000; i++){       
    correspondence.push_back(raw_correspondence[rand_idx[i]]);
}

registration(src_cloud, des_cloud, correspondence, ov_lable, folderPath, resolution, 0.95); 
// adapt the code to return the transform and compare with ground truth

I have searched all mentions of KITTI in the code and set the values in the registration() function used by the demo code similarly:

line 1041

string descriptor = "fpfh";
string name = "KITTI";

line 1240

igraph_maximal_cliques(&g, &cliques, 4, 0);

line 1280

inlier_thresh = 0.6;

As a concrete example of log output on failure, I want to show the result of KITTI run 08, registration pair 168 - 177:

5000 correspondences, took 721 ms
graph construction: 2.26546
coefficient computation: 0.212927
0.912101->min(0.912101 1.43598 2.47595)
clique computation: 0.248005
clique selection: 0.0180683
hypothesis generation & evaluation: 0.111791
3890 : 130873
total time 4130.55 (ms)
TE: 10.8942, RE: 0.954748

Thanks a lot for your help, I look forward to hearing from you!
Robert

关于版本MSVC =2022 x64

MSVC =2022 x64 这个到底是指什么？
是用VS2022来编译吗？

运行MAC的方式

你好！
请问一下，我直接用./MAC --demo运行效果不错，这么运行的时候会读取[email protected]等文件么？请教一下对比是怎么运行的？

Linux version compiling error

thanks for your great contribution!!

here's a question , when i run linux version (igraph version=0.9.9,cmake version=3.25.2) it shows this message :

(base) kuan@DESKTOP-S32DOQL:/mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/Release$ make
[ 14%] Building CXX object CMakeFiles/MAC.dir/PCR.cpp.o
/mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/PCR.cpp: In function ‘void print_graph(igraph_t*)’:
/mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/PCR.cpp:506:25: error: cannot convert ‘igraph_vector_t*’ to ‘igraph_vector_int_t*’
506 | igraph_get_edgelist(g, &el, 0);
| ^~~
| |
| igraph_vector_t*
In file included from /usr/local/include/igraph/igraph.h:69,
from /mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/Eva.h:34,
from /mnt/d/Desktop/research/3D-Registration-with-Maximal-Cliques/Linux/PCR.cpp:16:
/usr/local/include/igraph/igraph_conversion.h:69:94: note: initializing argument 2 of ‘igraph_error_t igraph_get_edgelist(const igraph_t*, igraph_vector_int_t*, igraph_bool_t)’
69 | IGRAPH_EXPORT igraph_error_t igraph_get_edgelist(const igraph_t *graph, igraph_vector_int_t *res, igraph_bool_t bycol);
| ~~~~~~~~~~~~~~~~~~~~~^~~
make[2]: *** [CMakeFiles/MAC.dir/build.make:118: CMakeFiles/MAC.dir/PCR.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/MAC.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

i would like to figure out this error.
sincerely waiting your reply,thank you!!

Python_implement /example.py

Wrong registration results. What can I do?

Thank you for open sourcing the program.
I am using it to register two point clouds as attached.
We also provide the reference result obtained by hand in cloudcompare.

a.zip

The result from MAC is like below

 -0.830348  -0.548407 -0.0988551    2.30432
  0.556168  -0.826622 -0.0858629    17.6757
 -0.034628  -0.126276   0.991391  -0.354262
         0          0          0          1

whereas the reference solution is

   -0.2292    0.9671    0.1106 5.904616
   -0.9731   -0.2250   -0.0486 -1.646853
   -0.0221   -0.1188    0.9927 -0.220632

What can I do to get good results?

Note with this program's demo sample data, I see the registration result is also wrong, though the resulting pose is exactly as written in the readme.

你好，关于在Linux中编译时igraph中出现了类型错误

编译时出现了这种变量类型的错误，请问作者在编写代码时有遇到吗？我安装的igraph也是0.9.9的

why python examply.py's result is very bad, i do not change anything

i have run the examply.py in my pycharm,but result is very bad

Three questions regarding the code

Thank you for your excellent work! I have three questions regarding the code.

Firstly, in the code located at this link:

3D-Registration-with-Maximal-Cliques/Linux/registration.cpp

Line 523 in f85cc3e

wijk += pow(Graph(i, a) * Graph(i, b) * Graph(a, b), 1.0 / 3); //wij + wik

, it appears that the edge weights are being added rather than multiplied as described in the associated paper. If this is the case, I am curious to know the reason for this change.

Secondly, in the code located at this link:

3D-Registration-with-Maximal-Cliques/Linux/registration.cpp

Line 1160 in f85cc3e

OTSU = OTSU_thresh(cluster_coefficients);

, it seems that a histogram is used to organize the scores, and the metric

3D-Registration-with-Maximal-Cliques/Linux/funcs.cpp

Line 551 in f85cc3e

sb = (double)n1 * (double)n2 * pow(m1 - m2, 2);

is used to choose the threshold. Is this metric related to any statistical theory? Have you considered using the median instead?

Thirdly, in the code located at this link:

3D-Registration-with-Maximal-Cliques/Linux/registration.cpp

Lines 664 to 676 in f85cc3e

	while (1)
	{
	if (f * max(OTSU, total_factor) > cluster_factor[49].score)
	{
	f -= 0.05;
	}
	else {
	break;
	}
	}
	for (int i = 0; i < Graph.rows(); i++)
	{
	if (Match_inlier[i] && cluster_factor_bac[i].score > f * max(OTSU, total_factor))

, I am unsure about the purpose of lines 664-673. Is it possible that the final value of f * max(OTSU, total_factor) is very similar to cluster_factor[49].score? Would it be possible to use cluster_factor[49].score directly instead? Additionally, this section of code appears to only retain the top 50 vertices, which may result in a very sparse compatibility graph. Could you please provide some insight into the reasoning behind this design choice?

Parameter Conversion Errors: when Running C++ Code with igraph, PCL on Windows

Hello, thanks for your valuable work!

I'm currently working with the PCL version 1.11.1 and Boost version 1.7.4 and igraph 0.10.1 on a Windows environment while running the C++ code provided by the author on GitHub. I'm encountering compatibility issues and require assistance to resolve them. If this is a version issue or something else. Any insights would be greatly helpful to me.

Here are the specific errors I'm encountering while running the code:

Error E0167:
Description: Incompatibility between arguments of type "igraph_vector_t *" and type "igraph_vector_int_t *"
Project: Author's Code
File: [PCR.cpp]
Line: [509]  igraph_get_edgelist(g, &el, 0);

Error E0312:
Description: No user-defined conversion from "boost::shared_ptr[pcl::PointIndices](javascript:void(0))" to "pcl::PointIndicesPtr" exists
Severity: Error
Code: E0312
Project: Trial
File: desc_dec.cpp
Line: 706  pcl::PointIndicesPtr Idx = boost::shared_ptr<pcl::PointIndices>();

Error C2664:
Description: Cannot convert parameter 2 from "igraph_vector_t *" to "igraph_vector_int_t *"
Function: igraph_get_edgelist(const igraph_t *, igraph_vector_int_t *, igraph_bool_t)
Project: Author's Code
File: [PCR.cpp]
Line: [509]  igraph_get_edgelist(g, &el, 0);

Error C2664:
Description: Cannot convert parameter 2 from "igraph_vector_ptr_t *" to "igraph_vector_int_list_t *"
Function: igraph_maximal_cliques(const igraph_t *, igraph_vector_int_list_t *, igraph_integer_t, igraph_integer_t)
File: [registration.cpp]
Line: [757and 1238]  igraph_maximal_cliques(&g, &cliques, 3, 0); //3dlomatch 4 3dmatch; 3 Kitti  4 

I would like to request your assistance in understanding and resolving these issues while running the code provided by the author. Any guidance or suggestions would be greatly appreciated. Thank you for your help.

Best regards

关于图的法向量

请问作者有尝试在建立完图之后，计算source和target上同一个图的点的法向量的相似性吗，然后设定一个阈值，只保留法向量相似度高的图，这样可以进一步筛选出好的图，用于后续计算，可以减少for循环的次数

想请问下作者您提供的数据集里面的[email protected] 文件是用什么方法生成的呢？

我用提供的fpfh生成与匹配函数进行匹配，发现效果远不如直接读取[email protected]文件的匹配效果来得好，请问您是怎么生成的[email protected]文件？