[GSoC] Update octree methods and create frames for PCC#23985
Conversation
|
@opencv-alalek @asmorkalov, Hi, although I changed the name of the repo (Its name is now opencv, the original name was opencv_contrib) and make a new PR, the build still failed. As you can see the repo name is still opencv_contrib. How can we do? Should we delete this repo, fork again and submit PR? |
|
Because GitHub keep alias for old repo name. Try to create empty |
| * @param maxDepth The max depth of the Octree. The maxDepth > -1. | ||
| */ | ||
| explicit Octree(int maxDepth); | ||
| explicit Octree(size_t maxDepth); |
There was a problem hiding this comment.
why change API w/o any good reason?
There was a problem hiding this comment.
Because I think maxDepth should be non-negative, and part of the subsequent code compares maxDepth to unsigned integers, I adopted this approach to avoid potential problems.
In addition, I forgot to change the corresponding explanation, which is my negligence.
There was a problem hiding this comment.
It's better to have int here since, among other reasons, it has better compatibility with our wrapper generators for Python and Java.
| * @param resolution The size of the octree leaf node. | ||
| */ | ||
| Octree(const std::vector<Point3f> &pointCloud, int maxDepth); | ||
| Octree(const std::vector<Point3f> &pointCloud, double resolution); |
There was a problem hiding this comment.
maybe both resolution and maxDepth could be specified or one of them; why remove maxDepth?
There was a problem hiding this comment.
Perhaps it's reasonable to retain both options.
The resolution denotes the size of the leaf node. I opted for resolution as it aligns well with point cloud compression, where preserving information at this precision is sufficient.
For the current octree functions, such as KNN search, it might be better to retain both methods. Simultaneously, the two can be calculated from one to the other.
What's your opinion?
There was a problem hiding this comment.
Since octree is used not only for point cloud compression, I'd propose you to keep both constructors (resolution and maxDepth)
|
@savuor, could you please review it? |
|
@savuor Friendly reminder. |
savuor
left a comment
There was a problem hiding this comment.
Please take a look at my comments, looks like there are several things to fix
| * @param resolution The size of the octree leaf node. | ||
| */ | ||
| Octree(const std::vector<Point3f> &pointCloud, int maxDepth); | ||
| Octree(const std::vector<Point3f> &pointCloud, double resolution); |
There was a problem hiding this comment.
Since octree is used not only for point cloud compression, I'd propose you to keep both constructors (resolution and maxDepth)
| * @param restorePointCloud The output point cloud data. | ||
| * @param restoreColor The color attribute of point cloud data | ||
| */ | ||
| void getPointCloudByOctree(std::vector<Point3f> &restorePointCloud, std::vector<Point3f> &restoreColor); |
There was a problem hiding this comment.
Should this method calculate an average color for the point in the same leaf?
If not, it should be said explicitly in the docs to the function
| } | ||
|
|
||
| bool insertPointRecurse( Ptr<OctreeNode>& _node, const Point3f& point, int maxDepth) | ||
| bool insertPointRecurse( Ptr<OctreeNode>& _node, const Point3f& point,const Point3f &color, size_t maxDepth,const OctreeKey &key, |
There was a problem hiding this comment.
Looks like this function always returns true, don't need to return anything at all
| EXPECT_NO_THROW(treeTest.radiusNNSearch(restPoint, radius, outputPoints, outputSquareDist)); | ||
| EXPECT_EQ(outputPoints.size(),(unsigned int)5); | ||
|
|
||
| //The outputPoints should be unordered, so in some resolution, this test will fail because it specified the order of output. |
There was a problem hiding this comment.
If this is so, maybe the points should be sorted by distance first?
There was a problem hiding this comment.
Looks like this file belongs to next PR about point cloud compression (probably #24197), should it be here?
|
A decision was to fix this PR by me |
|
Sorry for the late reply. I'm still here working on this PointCloudCompression commitment since GSOC. We've made a variety of experiment on PCC algorithms but the most significant improvement lies on a structural improvement on the OctreeNode class and the usage of Zlib. |
|
Our further PCC code should based on this PR, I shall make some adjustment on latter PCC framwork after you finished. Is it? |
|
@broweigit Hi there! I'm trying to fix this PR according to the notes I've made (and according to my personal understand of how this should be done :) ). I will invite you to review the changes I've made, along with other contributors. |
|
@broweigit I've changed API and some implementation details, can you take a look? |
| * @param colors color attribute of point cloud in the same 3-channel float format | ||
| * @return resulting Octree | ||
| */ | ||
| static Octree createWithDepth(int maxDepth, InputArray pointCloud, InputArray colors = noArray()); |
There was a problem hiding this comment.
Input arrays usually go first in the public API.
There was a problem hiding this comment.
This was made intentionally to reduce amount of overloaded methods
| for (int i = 0; i < (int)goldVals.size(); i++, it++) | ||
| { | ||
| Point3f p = it->second; | ||
| EXPECT_FLOAT_EQ(goldVals[i].x, p.x); | ||
| EXPECT_FLOAT_EQ(goldVals[i].y, p.y); | ||
| } |
There was a problem hiding this comment.
It could be just NORM_INF
There was a problem hiding this comment.
I propose to leave it as it is, using NORM_INF looks cumbersome here
Yep, checked. no problem with the changes for far. Thanks |
|
@vpisarev @TsingYiPainter Do you have any remarks? |

PR for GSoC Point Cloud Compression
Issue for GSoC 2023
The previous PR of this was closed due to repo name conflicts, therefore we resubmitted in this PR.
Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
Patch to opencv_extra has the same branch name.