Missing texture

I’ve tried increasing mesh size to 400000, increasing depthmap res to 1280, octree-depth to 13, using SIFT and ORB, but still cant get rid of all the small missing bits of texture. Most of the areas with the holes are well covered by the camera, and are not shiny, so I don’t understand why there are so many holes

What else can I try?

43 images 00:38:26

|Options:|auto-boundary: true, depthmap-resolution: 1280, feature-quality: ultra, mesh-octree-depth: 13, mesh-size: 400000, min-num-features: 12000, pc-quality: ultra, resize-to: -1, skip-orthophoto: true, use-3dmesh: true, rerun-from: dataset|

I’ve also noticed that with build 66 I downloaded today, there is no option to view camera positions, Textured Model is now top of the list, instead of Cameras, which has vanished, or is that related to using skip-orthophoto?

This is the first time I’ve used skip ortho and had a task complete :slight_smile:

3 Likes

Hmm… What’s the point-cloud look like in those regions? Can you run with --pc-filter 0 and maybe --texturing-keep-unseen-faces?

1 Like

The holes in the PC don’t match the texture holes, especially around the rim of the container, which is quite clean in the PC.

Running again now with pc_filter 0 and keep unseen faces, to see how it looks.

1 Like

Much worse PC and textures.

1 Like

What are the image dimensions? The --depthmap-resolution flag is over-riding --pc-quality and may well be lower than the 50% max dimension that --pc-quality ultra respresents.

1 Like

4032 X 2268, retrying without the depthmap res. flag

1 Like

Unfortunately that made no real difference.

1 Like

I’ve run into the exact same problem on a set of images I am processing. Would love to find a solution. I’ll post more details later.

1 Like

I suspect this is related to the model being I referenced. Things get weird sometimes when we don’t know the real size as the random starting point for the side of the scene can be arbitrarily. This is purely a guess, but could be verified if you created a GCP file for a dataset that provides this behavior.

1 Like

It happens with models of items that are very small, taken with the phone, so GCPs aren’t possible. I can’t think of any instances of this behaviour on images from drone photos, and I currently don’t have any way to produce accurate GCPs anyway.

Sounds like floating point precision issues for sure then.

Putting a simple woodworking square or a piece of graph paper in the scene and choosing an arbitrary zero for GCPs works well for these kind of models, e.g. 3D Reconstructing… everything, part quatre: a fully referenced ukulele – Smathermather's Weblog

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.