mvs-texturing icon indicating copy to clipboard operation
mvs-texturing copied to clipboard

Problem with image generation

Open juvinski opened this issue 6 years ago • 33 comments

Hi,

I'm using ODM and after some map generation, there is an issue with the final products. On the final image - orthomosaic - there are lines like that: problem1 problem2 How can I debug or try to see what is been done by mvs-texturing to figure out what is the cause of this error - the source images doesn't have this line BTW.

Best regards

juvinski avatar Nov 30 '17 00:11 juvinski

This looks to me like an artifact of the local seam leveling. Could you show me the wireframe of at one of these edges?

Best

nmoehrle avatar Nov 30 '17 17:11 nmoehrle

Hi @nmoehrle thanks for your reply. I'm pretty new on MVS, how can I get this wireframes ?

Best

juvinski avatar Nov 30 '17 19:11 juvinski

Open the textured mesh (.obj) from the odm_texturing folder in MeshLab, there’s an option to enable wireframe view there.

I’ve also seen these artifacts before, would love to learn more about possible causes and how to prevent them.

pierotofy avatar Dec 01 '17 17:12 pierotofy

Ok, I will try, thanks a lot @pierotofy

juvinski avatar Dec 01 '17 17:12 juvinski

Hi,

I made the procedure to access the wireframe wire model3d

The 3d image showing a problem area and the wireframe. I coudn't see anything but if you can I put all texturing objects at this drive's folder https://drive.google.com/open?id=1_JB-ofIcUSW2lS_qdERF6A9gGmHpmmeT

juvinski avatar Dec 01 '17 18:12 juvinski

@juvinski for the future, use "flat lines" and toggle the lights.

image

Here's a good screenshot.

image

A few other artifacts from the same dataset.

image

image

pierotofy avatar Dec 01 '17 19:12 pierotofy

Really nice @pierotofy thanks a lot for the information. I'm looking more this meshlab tool and is really nice :)

juvinski avatar Dec 01 '17 23:12 juvinski

Just encountered yet another dataset with the artifacts:

image

pierotofy avatar Dec 22 '17 18:12 pierotofy

I don't have an explanation for these artifacts, my first guess was an issue with the local seam leveling but those artifact would appear along mesh edges. Nothing within the algorithm should change the input images in such a way. I hope that I find the time to investigate this during the holidays.

nmoehrle avatar Dec 22 '17 20:12 nmoehrle

Please let me know if I can provide you with data or ways to reproduce it. Happy holidays!

pierotofy avatar Dec 22 '17 21:12 pierotofy

Me too, I have three or four datasets with same problem

juvinski avatar Dec 23 '17 00:12 juvinski

Is one of these datasets small enough that you can bisect the issue? Was there a version of texrecon that did not produce these issues?

nmoehrle avatar Dec 23 '17 03:12 nmoehrle

I remember first seeing this problem about 8 months ago. It's possible that it worked before, but I wouldn't be able to tell. @juvinski ?

Tomorrow I'll try to put together a reproducible dataset.

pierotofy avatar Dec 23 '17 04:12 pierotofy

@juvinski would you be willing to share one of your datasets' images on google drive?

pierotofy avatar Dec 23 '17 14:12 pierotofy

hi @pierotofy and @nmoehrle ,

I don't remember any dataset with this problems since the datasets O processed since November. I'm running some datasets taked around this year to see if I can see the problem happening with this older datasets. I have tested in two versions of texrecon - one built in March and other in November - both generated the model with the fail. This is a dataset - around 760 Mb - If you need something bigger or smallest please let me know. https://drive.google.com/open?id=1m9QtEJkjk6CvmWDJ3BfoIhipIC_gN_kE

Best regards

juvinski avatar Dec 24 '17 02:12 juvinski

Ok here's a full, reproducible test case:

Texrecon version is from the OpenDroneMap fork (https://github.com/OpenDroneMap/mvs-texturing/) which is almost on par with the current master.

Dataset with mesh, images and visualsfm file: https://drive.google.com/open?id=12rrV51VSwXvQgXf-TbZBubwN9i-YMZ8w

texrecon /subset/reconstruction.nvm /subset/odm_mesh.ply /subset/output -d gmi -o gauss_clamping -t none

image

pierotofy avatar Dec 24 '17 20:12 pierotofy

Btw, the -d area flag produces the same result.

juvinski avatar Dec 25 '17 03:12 juvinski

Found a smaller reproducible dataset (18 images) which might be easier to work with.

https://drive.google.com/open?id=1KUPVMyGwStRirXJmoC6BNoiwFp2pGLTF

# texrecon reconstruction.nvm odm_25dmesh.ply odm_textured_model -d gmi -o gauss_clamping -t none

Top right corner shows:

image

pierotofy avatar Dec 28 '17 16:12 pierotofy

I finally managed to look into this and the artifact is introduced during the global seam leveling, if the global seam leveling is disabled (--skip_global_seam_leveling) the artifact is gone. However, I have yet to track down why it is introduced. There is a lot of overlapping geometry in the mesh as well as gigantic triangles, but the area around the artifact looks clean as far as I can tell.

nmoehrle avatar Jan 07 '18 16:01 nmoehrle

I just had a result where everything was pink like yours. I initially thought that was the original color you fed into the algorithm, did the algorithm distort the color towards pink?

nmoehrle avatar Jan 07 '18 17:01 nmoehrle

You mean the "subset" dataset? The images are already pinkish due to the camera filter that was used to take the images.

pierotofy avatar Jan 07 '18 19:01 pierotofy

Ah ok no I just go a completely corrupt result when retexturing with -L and thought you might have experienced the same... pink

nmoehrle avatar Jan 07 '18 20:01 nmoehrle

Oh I see, no I've never seen that type of pink output. ^_^

pierotofy avatar Jan 08 '18 01:01 pierotofy

Hi, I didn’t notice problems until last October. I will try to strip some big dataset. I notice my new camera - nir + green + blue - all datasets have problems instead my rgb.

juvinski avatar Jan 09 '18 00:01 juvinski

Hi,

this dataset can be used. If you want another one or a little one please let me know.

https://drive.google.com/drive/folders/1DYESz3VnH95kPolA-Qhm1rx4OaZfCJhk?usp=sharing

Best regards.

juvinski avatar Jan 19 '18 04:01 juvinski

Ok so the issue arises due to the jpeg compression of the undistored images.

The current implementation assumes a pitch black (RGB(0,0,0)) border within undistorted images and calculates a validity mask from it. In a lossy compressed format like jpeg the border is not pitch black and thus regions that should be invalid might be classified as valid and used in the reconstruction. The artifacts we see are the undistortion borders of images.

My previous assessment that the the problem is caused by the global seam leveling was wrong -- there was a race condition when using data costs or the labeling of a previous run (-L, -D) which was fixed with 20bf2a89.

I am reluctant to increase the threshold although this would fix this particular problem because it might cause other issues.

Is it possible for you to write out undistorted images in a lossless format?

nmoehrle avatar Jan 21 '18 11:01 nmoehrle

Thanks for taking the time to look into this @nmoehrle! I think we can export the images in a lossless format, I will discuss it with the OpenDroneMap team.

pierotofy avatar Jan 21 '18 13:01 pierotofy

Hi @nmoehrle,

I'm generating undistorted images in png format( and testing compression from 0 to 9). This change give me better results, for instance, with jpg I was having 65 slashes in the result, now using png I'm having 5. Do you have any clue about how get this result better ?

juvinski avatar Feb 22 '18 17:02 juvinski

Oh that's surprising - can you provide the dataset that gives you five slashes?

nmoehrle avatar Feb 22 '18 18:02 nmoehrle

in true is the same dataset - I was comparing the image convertion to see what results or differences I will get. There are datasets I didn't have any slashes with png convertion, but there are I have this diminution. Previous - with jpg: p1

After with png: p2

This is the dataset. https://drive.google.com/open?id=1y2G1Et72H4zsVU0EVNvypZVAtk88Y-Yw If you wish I can give the model and textures too.

juvinski avatar Feb 22 '18 18:02 juvinski