not quite good reconstruction result

[ziruiw-dev]

Hi @Algomorph,

I have got your system up and running and below image is the reconstruction result at 65 frame on my computer(with binary mask input) and it's far from what you showed here:

I didn't change any code and use the default settings when I run target InfiniTAM_bpo. I enabled the cuda, openmp, png options when configure the cmake. Is there anything I did obviously wrong?

[Algomorph]

@Ryan-Zirui-Wang From your description I don't see that you did anything wrong, it may have that I had some commits in a raw state since I got the results that I showed you. Could you commit what you have into a separate branch, so I can run the exact code you're running?

On my end, I'll take my last commit and run that to confirm that everything still works as I showed in that post, and then report back to you. It's been many months since I've touched this branch.

[ziruiw-dev]

Hi @Algomorph,

Thanks for prompt reply. I didn't modify the code at all. The only thing I did is ticking some boxes in cmake gui so there is nothing I can commit to the repo? I didn't even change the number of iterations or step size, it just run as it is.

The boxes I ticked are:

• WITH_CUDA
• WITH_OPENMP
• WITH_PNG

The command I use to call the InfiniTAM_bpo:

./InfiniTAM_bpo "" /home/ryan/dataset/Deformable/Snoopy/color_%06i.png /home/ryan/dataset/Deformable/Snoopy/depth_%06i.png /home/ryan/dataset/Deformable/Snoopy/omask_%06i.png

That's all I did... The first input parameter "" means it should use internal calibration?

This is the output of terminal:

[Algomorph]

@Ryan-Zirui-Wang I'm running the code right now, and it looks like I'm getting a much cleaner result with the single-threaded version (-DWITH_OPENMP OFF). Looks like a race condition creeped in somewhere along the way. Try it with these parameters (built-in InfiniTAM tracker sort-of fails horribly on the first few frames, which are very patchy):

./InfiniTAM_bpo "snoopy/snoopy_calib.txt" "snoopy/frames/color_%06i.png" "snoopy/frames/depth_%06i.png" "snoopy/frames/omask_%06i.png" --output /output_dir/snoopy --start_from_frame_ix 16 --process_N_frames 50

The result is still not quite the same as what I have, so there was obviously a regression. However, I know that this result was from Aug 17, a few commits before the latest.

Perhaps, try to this commit: d6fc43c5a440588d4a0e84b6146cdbc2a4174d41

[Algomorph]

@Ryan-Zirui-Wang I'm still not getting a result as good. I need to spend some time hunting through and dissecting commits to find out exactly which one has the good result. I'll try to do this tomorrow, since I have to get back to my current work today.

[ziruiw-dev]

Right, Thanks for the reply. I'll try the commit and the input options as well!

[Algomorph]

@Ryan-Zirui-Wang : some good news and some bad news. Bad news: I'm still unable to get the really good result directly. Good news: I discovered some old binaries I cached up from August 16 and before, so hopefully with a little more detective work I can figure out what's the issue. Something makes me think that it may actually be compiler / peripheral libraries, not settings or the code itself, that is posing the issue: all the results before this week were produced when I complied on Ubuntu 16.04, and now I'm on Ubuntu 18.04.

I'll set up an Ubuntu 16.04 VM to test for this and report back. I'll also try some of the older binaries -- I have 1:1 correspondence of result video/binary, luckily, for a number of August results, to ensure it's not a settings issue.

This is based on Aug 28 code under Ubuntu 18.04:

[Algomorph]

@Ryan-Zirui-Wang it looks like I'm very tight on time right now. Do you think you can handle trying this on an Ubuntu 16.04 VM? I made a new branch called feature/DynamicFusion_Aug17 that you can try for this.

[ziruiw-dev]

Thanks a lot for your detailed reply and checking archives. Sorry I think it's more like a small bug introduced in commit history instead of causing by Ubuntu versions. Also setting up a 16.04 VM is quite time consuming and it might worse than just trying the the commit one by one... so I am trying to compare your code and another sobfu repo to see is there any algorithm or big implementation difference between them.

By the way, this issue is not urgent at all so please don't worry about it much. I am just trying to post some results of running your code on my machine without even hoping it can get fixed at time soon...

Thanks a lot, Ryan

[oopming]

@Algomorph hi guys, Thanks for sharing the results, good job. I've seen your code in the branch feature/DynamicFusion, I have some questions to ask.

1. Is there an iOS metal implementation?
2. Are there some test results of InfiniTAM Teddy?And Do you have more detailed test results?

Thanks!

[Algomorph]

I'm pleased to see more people are interested in this code. I've near-abandoned this codebase in favor of a different repo awhile back, but now I see that it may make sense to slowly restore this effort.

@oopming ,

1. Is there an iOS metal implementation?

There is no Metal implementation currently for the level set / dynamic fusion, the method stubs for metal are simply issuing a static compile-time "Not Implemented" error right now. Of course, if a good result is achieved in the future for the general CPU and CUDA implementations, the Metal implementation would become a priority.

2. Are there some test results of InfiniTAM Teddy?And Do you have more detailed test results?

It would make little sense to test level set fusion algorithms on InfiniTAM Teddy since that scene is static. We're benchmarking on KillingFusion snoopy sequence, which is currently available here

The best result I got (~ever) on the frames 16-65 of the Snoopy sequence is here. If you read through this thread, this is what we are referring to as the "good" result. Unfortunately, as you can understand from the thread, I've had trouble trying to replicate it since this branch got revived a few days ago.

[Algomorph]

Gentlemen, good news, I got a much better result on Aug 13 code with these settings as described in post here: https://github.com/Algomorph/InfiniTAM/issues/138#issuecomment-490665725

Don't forget the calibration as provided by Mira Slavcheva, translated to InfiniTAM format: snoopy_calib.txt