search

edgarriba / OpenDroneMap

OpenDroneMap is a tool to postprocess small Unmanned Aerial Vehicle (sUAS), balloon, kite, and street view data to geographic data. With the current update, we are adding the ability to create orthophotos from drone, balloon, and kite imagery which has GPS ephemeris. Forked from qwesda/BundlerTools ( https://github.com/qwesda/BundlerTools )
GNU General Public License v3.0
0 stars 0 forks source link

bad textured model #8

Open edgarriba opened 8 years ago

edgarriba commented 8 years ago

@dakotabenjamin got the following mesh from odm_texturing. Have you ever seen similar output?

textured_mesh

dakotabenjamin commented 8 years ago

I've never seen a textured model that bad...

edgarriba commented 8 years ago

caliterra On 1 Dec 2015 21:03, "Dakota Benjamin" notifications@github.com wrote:

Which dataset is that again? pacifica?

— Reply to this email directly or view it on GitHub https://github.com/edgarriba/OpenDroneMap/issues/8#issuecomment-161079682 .

dakotabenjamin commented 8 years ago

It's funny you brought this up because for the first time today I ran into this same issue: bad_texturing

I was working in a mostly clean build except I am testing some texture blending updates (which didn't even run, so there are probably other factors that could lead to this).

Can you post the odm_texturing log? This is mine:

Bundle path was set to: /vagrant_data/aukerman/texturingtest/pmvs/bundle.rd.out
Images path was set to: /vagrant_data/aukerman/
Images list path was set to: /vagrant_data/aukerman/texturingtest/odm_texturing/image_list.txt
Input model path was set to: /vagrant_data/aukerman/texturingtest-results/odm_mesh-0000.ply
Output folder path was set to: /vagrant_data/aukerman/texturingtest-results/odm_texturing/
The texture resolution was set to: 4096
The resized resolution used in bundler was set to: 1600
The resolution to texture with was set to: 3600
Blending will be performed.
Log file path was set to: /vagrant_data/aukerman/texturingtest/odm_texturing/odm_texturing_log.txt
Path for storage of blended images was not provided. Will use image path: /vagrant_data/aukerman/
Successfully loaded 199849 polygons from file.
Successfully read the bundle file.
Successfully read the image list file.
Unable to run blending due to bad OpenCV version. Required modules are nonfree and stitching.
Visible faces: 195662
Occluded faces: 4187
Faces sorted into 27 textures.
Saved texture_0.jpg to file.
Saved texture_1.jpg to file.
Saved texture_2.jpg to file.
Saved texture_3.jpg to file.
Saved texture_4.jpg to file.
Saved texture_5.jpg to file.
Saved texture_6.jpg to file.
Saved texture_7.jpg to file.
Saved texture_8.jpg to file.
Saved texture_9.jpg to file.
Saved texture_10.jpg to file.
Saved texture_11.jpg to file.
Saved texture_12.jpg to file.
Saved texture_13.jpg to file.
Saved texture_14.jpg to file.
Saved texture_15.jpg to file.
Saved texture_16.jpg to file.
Saved texture_17.jpg to file.
Saved texture_18.jpg to file.
Saved texture_19.jpg to file.
Saved texture_20.jpg to file.
Saved texture_21.jpg to file.
Saved texture_22.jpg to file.
Saved texture_23.jpg to file.
Saved texture_24.jpg to file.
Saved texture_25.jpg to file.
Saved texture_26.jpg to file.
Saved non_visible_faces_texture.jpg to file.
odm_textured_model.obj successfully saved.
edgarriba commented 8 years ago

This is my log for caliterra

 Bundle path was set to: /home/vagrant/datasets/odm_data/caliterra/opensfm/bundle_r000.out
 Images list path was set to: /home/vagrant/datasets/odm_data/caliterra/opensfm/image_list.txt
 Input model path was set to: /home/vagrant/datasets/odm_data/caliterra/odm_meshing     /odm_mesh.ply
 Output folder path was set to: /home/vagrant/datasets/odm_data/caliterra/odm_texturing/
 The texture resolution was set to: 4096
 The resized resolution used in bundler was set to: 2400
 The resolution to texture with was set to: 3600
 Log file path was set to: /home/vagrant/datasets/odm_data/caliterra/odm_texturing/odm_texturing_log.txt
 Successfully loaded 199908 polygons from file.
 Successfully read the bundle file.
 Successfully read the image list file.
 Visible faces: 173058
 Occluded faces: 26850
 Faces sorted into 9 textures.
 Saved texture_0.jpg to file.
 Saved texture_1.jpg to file.
 Saved texture_2.jpg to file.
 Saved texture_3.jpg to file.
 Saved texture_4.jpg to file.
 Saved texture_5.jpg to file.
 Saved texture_6.jpg to file.
 Saved texture_7.jpg to file.
 Saved texture_8.jpg to file.
 Saved non_visible_faces_texture.jpg to file.
 odm_textured_model.obj successfully saved.

As I see in your case you didn't build opencv with stitching and nonfree

dakotabenjamin commented 8 years ago

That's related to the blending addition I'm working on- I need to build opencv 2.4.11 into odm.

edgarriba commented 8 years ago

I would say that this problem comes from calibration stuff. Not sure yet

edgarriba commented 8 years ago

@dakotabenjamin finally made it working, but with some bad stitching patches. I attach you the a screenshot.

waterbury

dakotabenjamin commented 8 years ago

The patches are due to a lack of blending in the texturing code, which I am working on implementing right now.

edgarriba commented 8 years ago

need help?

dakotabenjamin commented 8 years ago

Probably. I am waiting on some info from the folks we contracted to do the bulk of the work on blending.

What did you do to get the stitching to work?

dakotabenjamin commented 8 years ago

Yeah, that would be great. I've pushed the changes to the odm_texturing branch on the main repo.

edgarriba commented 8 years ago

is it working the blending in this branch?

dakotabenjamin commented 8 years ago

No not yet. It was hastily put together and I'm running into memory issues.

dakotabenjamin commented 8 years ago

Checkout the working addition here.

Blending is disabled by default, so you'll have to use --odm_texturing-performBlending to enable it.

edgarriba commented 8 years ago

cool! we have to think how to integrate everything with the new cmake branch

dakotabenjamin commented 8 years ago

Here's a copy of the updated files before I added them to the git repo: https://www.dropbox.com/s/zqvbgu50vxej9hv/delivery_151214.zip?dl=0

So we won't have to sort through the commit history to add the update. Once I can get a working version going, I will work hard on testing and updating this branch.

edgarriba commented 8 years ago

I'll test this code! Do you have any result to compare?

dakotabenjamin commented 8 years ago

Working on that now. So far I'm getting weird results but I can't find what to attribute it to.

dakotabenjamin commented 8 years ago

Current: odm_orthophoto_sm

new: odm_orthphoto_sm

edgarriba commented 8 years ago

I see, not good results at all. I will revise the code to see if there's any improvement to do. The ideal thing to do here is find a paper with a proper method that solves this problem.

dakotabenjamin commented 8 years ago

Note that the texturing code was built to be added to commit bafcb76. It works differently, but I can't pinpoint why.

edgarriba commented 8 years ago

@paulinus any idea on how to improve that?

paulinus commented 8 years ago

I'm assuming that sfm, stereo, and meshing did work and that the problem is blending.

I just had a look at the blending function. It seems to be using the stitching pipeline of OpenCV. That is supposed to work for panoramas only. It uses a rotation only model to register the images, which should not work if the camera moves. Not sure how it would work for drone imagery. Is the method explained somewhere @dakotabenjamin ?

edgarriba commented 8 years ago

You are totally right, don't think OpenCV here is the solution. Maybe we can start to think in use OpenMVS here. https://github.com/cdcseacave/openMVS

dakotabenjamin commented 8 years ago

@edgarriba for now I think I would hold on incorporating this blending feature into the code. @smathermather and I need to meet with the Spotscale folks to understand the methods better

@paulinus thanks for the info. This is news to me. I will try to get more information soon.

dakotabenjamin commented 8 years ago

@edgarriba We discussed OpenMVS, but have reservations about the licensing.

edgarriba commented 8 years ago

OpenMVS has an AGPL which works similar to GPL (PMVS)

smathermather commented 8 years ago

The way I interpret AGPL (corrections welcome) is that as long as we firewall the OpenMVS compiled binary portions of the toolchain and continue to control with a python script (no binary compilation), any changes / improvements to a hosted version of OpenMVS/ODM would require the sharing of the OpenMVS changes, but not the rest of the toolchain. If this is true, than this is acceptable.

edgarriba commented 8 years ago

As I understand if ODM is completely dependent of an AGPL lib, then it must be released with a AGPL licence. Additionally, the source code of OpenMVS must be provided. Then you are right, if we do a modification in OpenMVS we must provide the source code of that modified version.

Check this link: http://programmers.stackexchange.com/questions/142012/using-an-agpl-3-0-licensed-library-for-extra-functionality-in-an-ios-app

edgarriba commented 8 years ago

Besides, I haven't tried OpenMVS yet. Probably the bottleneck will be export OpenSfM data to OpenMVS format. Maybe @paulinus could help with that?