[App ] error: opening file '/mnt/xxx/scene/depthxxxx.dmap' for reading depth-data

[SubChange]

Describe the bug
I used openMVS to process results from colmap using Scaleable Pipeline, However, errors occured when executing DensifyPointCloud

To Reproduce
Steps to reproduce the behavior:

1. Using colmap gui to import 4324 images for SFM
2. Converting results from colmap to openMVS

mkdir $PROJECT/scene
InterfaceCOLMAP \
--working-folder $PROJECT/scene \
--input-file $PROJECT/colmap_interface/ \
--output-file scene.mvs \
--image-folder $PROJECT/colmap_interface/images

In this step, 4232 image was imported through interface, which is not equal to the numbe of original images (4324). Maybe there was some images was not successfully registered during SFM. This is a normal phenomenon.

Logs in step: InterfaceCOLMAP-2505242150328C5D7B.txt

4. Calculating depth maps

DensifyPointCloud \
--working-folder $PROJECT/scene \
--input-file scene.mvs \
--resolution-level 2 \
--fusion-mode 1 \
--max-threads 13

Logs: DensifyPointCloud-2505261615028D2A23.txt

As shown in the log file, there were 8 errors. One example is as the follow:

18:09:57 [App     ] error: opening file '/mnt/usbdisk/subchange/zcg_whub/20250418_d2/zy_bridge/den_openmvs/scene/depth1668.dmap' for reading depth-data

5. Splitting the scene

DensifyPointCloud \
--working-folder $PROJECT/scene \
--input-file scene.mvs \
--sub-scene-area 30000000 \
--resolution-level 2 \
--max-threads 13

There were errors again.

I checked these depth-data, they are definitely not in my folder.

Desktop (please complete the following information):

• OS: [e.g. ubuntu20.04]
• Version[e.g. develop branch]

Additional context
I noticed this related issue issue 1007. It said that " It turns out that images indices in the TXT file were starting from 0 instead of 1". However, I checked the index of images in my case, the index of images was started from "1" exactly.

• screenshot of images.txt from colmap

• screenshot of scene.json converted from scene.mvs using the scripts in the repository.

I don't how to do now, Could anyone give me some tips. Thank you very much.

[cdcseacave]

Thank for taking time to write a detailed issue. The problem seems somewhere in the depth-maps estimation step. The import seems ok, and there is enough disk space, so the problem is somewhere in estimating some depth-maps. Can you reproduce the problem on a much smaller dataset?

[SubChange]

Thanks for your timely reply. I also siwtched the version of openMVS to v2.3.0, the same errors exist. Therefore, I think the error was related to the openMVS

It's difficult to repreduce the error using a smaller dataset. However, I will try it and upload related files if I success later. Thank you again.

[SubChange]

Hi, after many experiments, I found that the above error may be caused by the presence of water surfaces in my image dataset. The algorithm may not be able to estimate the depth data of these images due to the lack of texture.

The reconstructed target is a bridge on a river as the follow:

However, when UAV shooting, some images were captured targeted at water surface, The sample images are as follows:

Most of images that missing depth data in the log file contain a large ratio of water surface like above. Therefore, should I delete these images? Or can I provide a mask to openMVS to solve this problem?

[cdcseacave]

images like the last two will not help in MVS, so you can safely delete them, however OpenMVS should not crash; pls send a small dataset that causes you the problem