c-sommer / primitect

Code accompanying the paper "PrimiTect: Fast Continuous Hough Voting for Primitive Detection" by C. Sommer, Y. Sun, E. Bylow and D. Cremers.
https://doi.org/10.1109/ICRA40945.2020.9196988
GNU General Public License v3.0
31 stars 10 forks source link

Visualization of primitives #4

Closed spirosperos closed 3 years ago

spirosperos commented 3 years ago

Hello! Could you please provide more information on the output parameters that would help with the visualization of the detected primitives? I was able to successfully visualize the planes but I'm not sure what do the output parameters of other primitives represent. Is perhaps the code that you used to visualize the primitives for the figures in the original paper available? Thanks!

c-sommer commented 3 years ago

Hi! Thanks a lot for calling my attention to the insufficient documentation on output format and primitive parameters. I updated the README and added comments in the respective files defining the primitives (see cpp/include/objects/). Hope this helps. The (Matlab) code I was using for visualization in the paper is not yet cleaned, but I will try to make it available soon!

c-sommer commented 3 years ago

Hi, I just updated the repository with Matlab functions to visualize the results, together with example data and example results for quick tests.

spirosperos commented 3 years ago

Thank you very much! When I try to run the method on some of the reconstruction from the Redwood dataset I get an error pointing out that the .ply file doesn't contain normals - "tinyply exception: the following property keys were not found in the header: nx, ny, nz, ". I used Open3D to estimate normals but then when I run the method I get the following error output:

Error in `bin/DetectObjects': double free or corruption (out): 0x00007f670ba61010 ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x777f5)[0x7f670c4de7f5] /lib/x86_64-linux-gnu/libc.so.6(+0x8038a)[0x7f670c4e738a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f670c4eb58c] bin/DetectObjects[0x4530e1] bin/DetectObjects[0x4516f8] bin/DetectObjects[0x40521c] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f670c487840] bin/DetectObjects[0x408249] ======= Memory map: ======== 00400000-00471000 r-xp 00000000 08:01 6556797 /home/niki/common_ws/primitect/cpp/detect_objects/bin/DetectObjects 00670000-00671000 r--p 00070000 08:01 6556797 /home/niki/common_ws/primitect/cpp/detect_objects/bin/DetectObjects 00671000-00672000 rw-p 00071000 08:01 6556797 /home/niki/common_ws/primitect/cpp/detect_objects/bin/DetectObjects 00672000-00673000 rw-p 00000000 00:00 0 00c26000-00c58000 rw-p 00000000 00:00 0 [heap] 7f6704000000-7f6704021000 rw-p 00000000 00:00 0 7f6704021000-7f6708000000 ---p 00000000 00:00 0 7f670b55d000-7f670bf64000 rw-p 00000000 00:00 0 7f670c467000-7f670c627000 r-xp 00000000 08:01 10490483 /lib/x86_64-linux-gnu/libc-2.23.so 7f670c627000-7f670c827000 ---p 001c0000 08:01 10490483 /lib/x86_64-linux-gnu/libc-2.23.so 7f670c827000-7f670c82b000 r--p 001c0000 08:01 10490483 /lib/x86_64-linux-gnu/libc-2.23.so 7f670c82b000-7f670c82d000 rw-p 001c4000 08:01 10490483 /lib/x86_64-linux-gnu/libc-2.23.so 7f670c82d000-7f670c831000 rw-p 00000000 00:00 0 7f670c831000-7f670c848000 r-xp 00000000 08:01 10490392 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f670c848000-7f670ca47000 ---p 00017000 08:01 10490392 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f670ca47000-7f670ca48000 r--p 00016000 08:01 10490392 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f670ca48000-7f670ca49000 rw-p 00017000 08:01 10490392 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f670ca49000-7f670cb51000 r-xp 00000000 08:01 10490553 /lib/x86_64-linux-gnu/libm-2.23.so 7f670cb51000-7f670cd50000 ---p 00108000 08:01 10490553 /lib/x86_64-linux-gnu/libm-2.23.so 7f670cd50000-7f670cd51000 r--p 00107000 08:01 10490553 /lib/x86_64-linux-gnu/libm-2.23.so 7f670cd51000-7f670cd52000 rw-p 00108000 08:01 10490553 /lib/x86_64-linux-gnu/libm-2.23.so 7f670cd52000-7f670cf25000 r-xp 00000000 08:01 3150894 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28 7f670cf25000-7f670d124000 ---p 001d3000 08:01 3150894 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28 7f670d124000-7f670d12f000 r--p 001d2000 08:01 3150894 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28 7f670d12f000-7f670d132000 rw-p 001dd000 08:01 3150894 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28 7f670d132000-7f670d135000 rw-p 00000000 00:00 0 7f670d135000-7f670d15b000 r-xp 00000000 08:01 10490455 /lib/x86_64-linux-gnu/ld-2.23.so 7f670d32f000-7f670d335000 rw-p 00000000 00:00 0 7f670d359000-7f670d35a000 rw-p 00000000 00:00 0 7f670d35a000-7f670d35b000 r--p 00025000 08:01 10490455 /lib/x86_64-linux-gnu/ld-2.23.so 7f670d35b000-7f670d35c000 rw-p 00026000 08:01 10490455 /lib/x86_64-linux-gnu/ld-2.23.so 7f670d35c000-7f670d35d000 rw-p 00000000 00:00 0 7fff1e9f1000-7fff1ea12000 rw-p 00000000 00:00 0 [stack] 7fff1eab0000-7fff1eab3000 r--p 00000000 00:00 0 [vvar] 7fff1eab3000-7fff1eab5000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted (core dumped)

Any idea on how to solve this? Thanks.

c-sommer commented 3 years ago

Have you tried with the provided example files from the Redwood dataset? Or used the provided scripts to generate the Redwood data in the appropriate format? One possible source of error could also be that the .ply files do not contain single precision floats maybe? I have never encountered this error with any of the data I was using, so I am very sorry but I cannot help. But if you use the provided example data and/or generate the Redwood data using the scripts, the code builds, compiles and runs for me on Ubuntu 18.04 with gcc 7.5.0.

spirosperos commented 3 years ago

I ran the method successfully on the example file 717416.ply that you provided. The problem that I mentioned arises when I try to run the method on one of the reconstructed models from the Redwood dataset, for example - http://redwood-data.org/3dscan/models.html?i=9669 . When I try to run it on the trash can reconstruction. The first error that arises is

tinyply exception: the following property keys were not found in the header: nx, ny, nz,

After estimating the normals with Open3D I get the error I mentioned in the previous post. Is there perhaps a limitation on the size of the mesh?

c-sommer commented 3 years ago

There is no hardcoded limitation for the size, but it could happen that memory overflows on your machine, yes. Can you maybe try to estimate normals using Matlab and save the .ply in exactly the same format as I do in the Redwood scripts? In particular, no triangles/faces, but really only points and normals, in single precision and as binary file. That format should work reliably. I am sorry that this might be inconvenient as it is not C++, but I do not know Open3D well and thus find it hard to judge what could be the problem there.