add high resolution monocular priors script #76
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.
I added an option to generate high resolution monocular priors similar to monosdf script with a few modifications. I made this a draft as there are some issues I found that I wanted to ask some questions. I also temporarily added some visualization scripts to help debug. This is what most outputs currently look like
You can see that the high resolutions cues look much better v.s. the interpolated (especially around edges) but there are some problems @niujinshuchong may be able to help answer?
Here is a link the custom dataset I generated using nerfstudio ns-process-data
https://drive.google.com/file/d/1EPVHdDuV3vCEaF2852FeJR9yi-kUblZS/view?usp=sharing
to generate the low resolution cues use
to generate the high resolution cues use
To use the visualizer first
then from the
sdfstudio
directory you can useassuming that is where the dataset is
--crop-mult 2
in the process_nerfstudio_to_sdfstudio.py. This is mostly because I noticed that using a 1920x1080 takes an EXTREMELY long time compared to the original 384x384 due to the large number of patches created (a few hours). 768x768 seems like a good middle ground (a few minutes) v.s. the original 384x384 (a few seconds)I think this is probably due to the large white wall that makes it difficult for patches to be correctly merged together and to have some sort of coherency since the depth/normal values don't align well. is this something you've come across @niujinshuchong ?
A solution I could come up with is just to simply throw these clearly bad frames away using some sort of heuristic taking into account previous frames but that seems very brittle