Tomáš Sláma

This is the log of the first command: [DensifyPointCloud-2402011542308B498E.log](https://github.com/cdcseacave/openMVS/files/14137558/DensifyPointCloud-2402011542308B498E.log) The issues seem to persist, I don't see why they weren't generated. I tried re-running the pipeline overnight (with `--resolution-level 2`)...

Rerunning the pipeline with 1. `DensifyPointCloud scene.mvs --resolution-level 2 --iters 4 -v 3 --cuda-device -1 --fusion-mode 1` 2. `DensifyPointCloud scene.mvs --resolution-level 2 --iters 4 -v 3 --cuda-device -1 --sub-scene-area 20000000`...

Digging further, it seems that the `InterfaceCOLMAP` (run before 1, 2 and 3) only exports a subset of images (`946` out of the `972` total ones): ``` 10:07:07 [App ]...

`badblocks` on the disk in question produced no errors so the problem likely isn't in the disk.

Ran MemTest86 to check for RAM issues (possibly corrupting the DMAPs on export), no fails there.

Rerunning the code on the machine the issue was present on and also on a different one to see if the problem is with the data.

The errors occur for the same depth maps when run multiple times.

I'm at a loss for what to try at this point, let me know what I should do if you have any ideas.

Found a minimal reproducible example. Taking this COLMAP project: [1-colmap-input.zip](http://tom.ggu.cz/openmvs/1-colmap-input.zip) I ran COLMAP's `image_undistorter`, producing the following: [2-after-undistortion.zip](http://tom.ggu.cz/openmvs/2-after-undistortion.zip) Using OpenMVS, I ran 1. `InterfaceCOLMAP -i . -o scene.mvs --image-folder images`...

Doing more experiments, I couldn't replicate this issue. Running the full reconstruction (sparse, dense, model, texture) for varying `--resolution-level`s decreased the time... I'll see if I can pin the issue...