Environment file

[iegorval]

Hello,

The work looks extremely interesting. However, the installation instructions are written in a very non-optimal way. Without a proper environment file, it takes me already >1hr just to install the conda/pip dependencies since they are randomly split into multiple commands and conda tries to re-evaluate the environment all the time, apparently. Also, versions of pip packages are not specified: as well as the reason for choosing pip for them over conda. Any change you would be able to make a proper environment.yaml file from your environment and share as part of the repo?

Thanks!

P.S. Also some information about how to run on RueMadame or on new data is missing from Readme, which makes it a bit tricky to try out this new denoising approach.

[ddsediri]

Hi @iegorval,

Thank you for your interest in our work. At the moment I don't have the time to update the repo, but I will add an environment file when I get the chance. The reason why I have left the main packages specified (Pytorch, Pytorch3D and Pytorch Geometric), without just adding an environment file is because Pytorch3D and Pytorch Geometric have, in the past, been tricky to install because of their requirements clashing. That's the main reasons why I prefer to compile Pytorch3D from source and then either use conda or pip to install Pytorch Geometric.

I don't necessarily prefer conda vs pip. However, I've noted that Pytorch3D has changed their implementation of P2M loss (from v0.6.2 onwards) which caused inconsistencies when reproducing results across the literature. That's the reason for recompiling from the source code as guided by the Pytorch3D team (https://github.com/facebookresearch/pytorch3d/blob/main/INSTALL.md). Here is a link to the original issue which was initially raised by another researcher (please refer to the ScoreDenoise implementation and issue: https://github.com/luost26/score-denoise/issues/12). My comments regarding the resolution are found in the same thread (https://github.com/luost26/score-denoise/issues/12#issuecomment-1783969394).

I'll add a bit more info when I get the time and clean up the repo.

As for evaluating on RueMadame and other test data, I will update the README file asap with the runtime commands/settings.

Cheers, Dasith.

[iegorval]

Hi @iegorval,

Thank you for your interest in our work. At the moment I don't have the time to update the repo, but I will add an environment file when I get the chance. The reason why I have left the main packages specified (Pytorch, Pytorch3D and Pytorch Geometric), without just adding an environment file is because Pytorch3D and Pytorch Geometric have, in the past, been tricky to install because of their requirements clashing. That's the main reasons why I prefer to compile Pytorch3D from source and then either use conda or pip to install Pytorch Geometric.

I don't necessarily prefer conda vs pip. However, I've noted that Pytorch3D has changed their implementation of P2M loss (from v0.6.2 onwards) which caused inconsistencies when reproducing results across the literature. That's the reason for recompiling from the source code as guided by the Pytorch3D team (https://github.com/facebookresearch/pytorch3d/blob/main/INSTALL.md). Here is a link to the original issue which was initially raised by another researcher (please refer to the ScoreDenoise implementation and issue: luost26/score-denoise#12). My comments regarding the resolution are found in the same thread (luost26/score-denoise#12 (comment)).

I'll add a bit more info when I get the time and clean up the repo.

As for evaluating on RueMadame and other test data, I will update the README file asap with the runtime commands/settings.

Cheers, Dasith.

I mentioned conda vs pip specifically also because e.g. I could not run it with the installation instructions, as I automatically got newest (i.e. 2+) version of numpy, which was not compatible with the rest of packages.

I managed to run it though. It seems interesting but I am still waiting for results.

I also noticed that you use KMeans for bigger point clouds, which would take probably forever for actual large-scale. I know that is more preprocessing and not really point of this research, but out of curiosity, have you considered some simpler spatial subdivisions for large-scale point clouds (e.g. KDTree)?

Cheers, Valeria

[ddsediri]

Ah ok, glad to know you got it to work. Yeah, the install is tricky but CUDA 11.8, Pytorch 2.0.1, Pytorch3D 0.7.4, PyG 2.3.1 are the main dependencies. Numpy, as long as it doesn't clash with those packages, won't give you any issues.

Regarding KMeans. We don't actually use the KMeans based point cloud partitioning algorithm. That's a remnant from the previous codebase (ScoreDenoise, which is an earlier denoising/filtering paper). We use the patch based denoising mechanism of our previous method (IterativePFN). If you look here (https://github.com/ddsediri/StraightPCF/blob/31acf458f1ee2ca38ec91396d373c06ca15095d1/utils/denoise.py#L14), we only use Farthest Point Sampling (FPS) to sample seed points in the point cloud. Then given then the seed points, we use Pytorch3D's pytorch3d.ops.knn_points function to get nearest neighbour patches of 1000 points each. This is done on the GPU so it's quite fast. Previous methods used to implement Scipy KDTree for nearest neighbour searches of the point sets but I think Pytorch3D's implementation of the knn_points operator is a better alternative as nothing is done on the CPU. We focus on patch-wise denoising so that it better accounts for local geometry and for the graph convolution, you need a directed graph constructed from k-nearest neighbours. So however, you partition the point cloud, we still need to build the directed graph.

I don't know how big the point clouds you are working with are but as you get to larger point clouds (>500K-1M points) I think a partitioning mechanism will be needed (you can use KMeans or a different method like KDTree/FPS+knn_points). But for smaller point clouds, our method works quite efficiently.

Cheers, Dasith.

[iegorval]

Ah ok, glad to know you got it to work. Yeah, the install is tricky but CUDA 11.8, Pytorch 2.0.1, Pytorch3D 0.7.4, PyG 2.3.1 are the main dependencies. Numpy, as long as it doesn't clash with those packages, won't give you any issues.

Regarding KMeans. We don't actually use the KMeans based point cloud partitioning algorithm. That's a remnant from the previous codebase (ScoreDenoise, which is an earlier denoising/filtering paper). We use the patch based denoising mechanism of our previous method (IterativePFN). If you look here (

https://github.com/ddsediri/StraightPCF/blob/31acf458f1ee2ca38ec91396d373c06ca15095d1/utils/denoise.py#L14

), we only use Farthest Point Sampling (FPS) to sample seed points in the point cloud. Then given then the seed points, we use Pytorch3D's pytorch3d.ops.knn_points function to get nearest neighbour patches of 1000 points each. This is done on the GPU so it's quite fast. Previous methods used to implement Scipy KDTree for nearest neighbour searches of the point sets but I think Pytorch3D's implementation of the knn_points operator is a better alternative as nothing is done on the CPU. We focus on patch-wise denoising so that it better accounts for local geometry and for the graph convolution, you need a directed graph constructed from k-nearest neighbours. So however, you partition the point cloud, we still need to build the directed graph. I don't know how big the point clouds you are working with are but as you get to larger point clouds (>500K-1M points) I think a partitioning mechanism will be needed (you can use KMeans or a different method like KDTree/FPS+knn_points). But for smaller point clouds, our method works quite efficiently.

Cheers, Dasith.

Hello,

I think I've see error because of Numpy 2.0. Did not make a screenshot sadly, but I think it was not compatible with older PyTorch. Might need to check again, but I just recommend to install it with conda so it does the dependency resolution.

As for the patches, I also tried it without KMeans, but FPS was a huge bottleneck for me (could not wait long enough). I managed to work efficiently with your method by using Bucket KDTree to pre-split the point cloud and then applying the patch-based denoising. Maybe that would be interesting direction to explore if you get to processing of much larger point clouds some day :)

[ddsediri]

I'll look at the dependency issue when I get a chance and update the README as well, this might help more people trying to reproduce the work so thank you for the feedback!

I agree, FPS can be a bottleneck with larger point clouds. It sounds like you got a more efficient way to partition the point cloud beforehand. Yes, scaling to larger point clouds efficiently is definitely of interest. Also, I'll try to collate some of the important point cloud utilities into a single repo+tutorial, focused on denoising, at some point. I just need to find the time to put everything together. :D

But I'll keep this in mind and we can revisit it later perhaps. Thanks for the insights!