jzhangbs / Vis-MVSNet

Visibility-aware Multi-view Stereo Network
MIT License
235 stars 27 forks source link

bad result on DTU #15

Closed decai-chen closed 3 years ago

decai-chen commented 3 years ago

Hi,

thanks for open-souring this great work!

I ran the dtu validation script on the preprocessed DTU data from MVSNet, since you have not provided one. But the result is quite bad. I think there is something wrong with data, probably the camera parameters. Do you have any idea about that? Or could you release your pre-processed DTU dataset?

thank you in advance!

jzhangbs commented 3 years ago

do you mean depth map evaluation by val.py or point cloud evaluation by test.py?

if it's depth map evaluation, the data from MVSNet is scaled and cropped beforehand. So you need to put --resize 640,512. To double check, you can plot the images (maybe just one channel because the images are normalized) after obtaining the data from data loader and see the cam center in intrinsic mat is roughly w/2 and h/2

if it's point cloud evaluation on test set, the data from MVSNet should be fine

decai-chen commented 3 years ago

thanks for the reply!

I meant the depth map evaluation.

Yes, your "dtu_val.py" has already resize the shape to 640,512. And the rectified images in the dataset has the same shape. However, in the camera files, the intrinsics seems wrong.

For instance, in "dtu/Cameras/train/00000000_cam.txt": intrinsic 361.54125 0.0 82.900625 0.0 360.3975 66.383875 0.0 0.0 1.0

I am wondering if the intrinsics in camera files are already downscale with a factor of 4 already?

BTW, the naming convention in the "dtu_o_val.json" is not compatible with the official DTU dataset, which requires some minor modifications.

jzhangbs commented 3 years ago

it seems that this cam file follows the size of depth map (1/4) instead of image. you may need to first upscale the cams 4x.

decai-chen commented 3 years ago

You are right! Upscaling the cams 4x solves this issue!