Improve depth map rasterization time #195
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The main point of this PR is to greatly improve the runtime of depth map rasterization. It is currently written on Python and this PR takes only the hot loop and codes it in C++.
The main guiding points here:
1 - Don't break compatibility. Every user of PRNet should be using the code in the same way, without installing any additional dependency or doing extra steps. So the code will gracefully fallback to the original Python code if the user do not compile the C++ code.
2 - Easy to use. The compilation step is quite simple, and a build.sh script is available for Unix users. Also the required dependencies to compile are a C++ compiler and cmake to make life easier on different OSes. So no additional libs or tools are required.
3 - Touch the minimal amount of code so that the debugging and maintenance process stays as much as possible on Python.
4 - Must be quite fast. For a 250x250 image, the runtime went from 2376ms to 2.152ms on a i7-8700K. Notice that no threads o parallel computing was used, it was just a plain conversion from the Python code to C++.
I've noticed that there is a cython implementation, however it is on another repo, and it may be hard to setup for people that do not have any cython knowledge.
On a side note, amazing work on PRNet! :D