-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restructure and add functionality to PCLPointCloud2 filters #3483
Conversation
Thanks for taking the time to implement this! Would it be possible to split the last commit into smaller chunks? The bullet-point summary you put in the comment is helpful, but it's hard to trace the points to the actual code changes. Be as granular as possible, this will accelerate the review. |
Ok, will do. Can I force-push the new commits to my master branch or would that cause any problems? |
At this stage it is totally fine to force push your renewed commit history. Once things are organized, then refrain from doing so until the review is over. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if I appear to be stubborn, but I'd like to have these commits further simplified and possibly split into separate PRs. Let me explain my concerns.
This PR, as it is, breaks our unit tests. (And they are by no means comprehensive.) The last three commits are very code-intensive; the code is fairly convoluted and, I can imagine, contains numerous edge-cases. As a result, it's hard to say which commit introduced a breaking change. Furthermore, if you now push a small fixup commit that turns the unit tests green, I wouldn't be sure that there is no other problem that is not covered by the tests. So I feel a very careful review is needed.
As a way forward, I'd propose to limit this PR to commits 1-8 (i.e. up to and including 3d2d139). Let's see if the tests are passing with it. I'd also like to have a more thorough discussion of the relation between the two applyFilter
methods. From what I see, in the templated passthrough filter the point cloud version of applyFilter
is implemented through the index version of applyFilter
. Also, a certain applyFilterIndices
method is used as a synonym of index version of applyFilter
. I wonder if we should reproduce the same structure in the PCLPointCloud2
specialization of the filter.
Sure thing, no problem!
Yes, I guess that makes sense to avoid duplicate code. That way the cloud version of applyFilter can basically be (almost?) the same in all classes.
I don't really see the point of that. Is that for legacy reasons?
Concerning the As a side question (out of curiosity): How do you see the status of the PCLPointCloud2-filters in general? It seems unnecessary to have them in addition to the templated filters. |
👍
I also don't see the point and I don't know if there was any good reason for this. OK, let's not have this is
On one hand, this is mostly duplicate code that (as expected) diverged over the years from the templated code. A maintainers headache. However, I'm hesitant to deprecate these filters because to my knowledge they are quite popular as building blocks in ROS perception pipelines. If we were to deprecate them, people would need to convert to and from templated point clouds, introducing unnecessary overhead in (usually) resource-limited systems. |
Ok, I have found a mistake in my changes (probably the reason why the checks were failing). I wrote |
The one check that fails is |
Yes, it's a different story.
If we agree that refactoring of |
Sorry, you are right, I did not check carefully where the issue was introduced. |
… instead of Filter - add the applyFilter(indices) function, the code has been adapted from the templated filters (hpp files) - remove some functions and variables from PassThrough because FilterIndices already has them
Don't merge this just yet. I started looking into the implementation and I noticed I have a couple of points I have questions to ask. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a complete review but I'll just focus on the passthrough class for now. I'm noticing a tendency for divergence between both overloads of applyFilter
.
In my ideal world, I would rather have a mechanism which makes all checks and finds which indices to keep and to remove and a have a second round in which given both these sets of indices, it then generates the appropriate point clouds.
Or write a private scope method which generates both indices and output point cloud structures, but that aborts each iteration early if only the indices are required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall it looks good. I just had some additional minor suggestions.
I made the requested changes. |
Thank you. I believe we should leave this new reading functionality you've added in the last commit to a separate PR and merge this PR without it. We can discuss the next steps once this one is merged. |
@taketwo what your opinion on rewriting the commit history here? It feels too atomic for me in certain points parts but I suspect the effort is gonna be considerable for little benefits. I believe I would merge it as is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I was the author of this PR I'd probably squash some of the clean-up commits together. But that's a matter of taste I suppose.
I can definitely say that such a level of granularity makes review a breeze. Thanks @mvieth!
See #3471
Please see commit messages for more information