Orthophoto and 3D distorted in 95% overlap dataset


#1

This is a crosspost from github. I still need help.

What is the problem?

3D isn’t producing good results as I expected. Even with 95% overlap and over 700 photos the orthophoto has distortion and the walls look really strange.

What should be the expected behavior?

I would expect with 95% overlap and 300 feet up and mapping over a 3 story building that it would be able to render the walls properly.

How can we reproduce this? (What steps did you do to trigger the problem? What parameters are you using for processing? If possible please include a copy of your dataset uploaded on Google Drive or Dropbox. Be detailed)

Here’s the dataset.

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

The processing options are in the attached image. I know they’re strenuous to process like this but I had time and wanted to give it a fighting chance to be of good quality. I’m not sure if it’s the software or the operator. Hopefully if it is me I can be taught.
image


#2

P.S.
The feature extraction issue of over-bright roof doesn’t actually appear to be the problem. I’m not interested in what is on the roof, I just want the overall shape of the building to appear correctly. It looks like the points are not getting filtered out, which is throwing off texturing. The point cloud overall looks better than the texturing.
Screenshot_18 !


#3

New users can only post one image per post huh? It’s needed to have comparison.
Screenshot_19


#4

Hi @xmutantson – per the thread here: https://github.com/OpenDroneMap/WebODM/issues/559, have you tried rerunning using the default point cloud settings? Drop all flags re: OpenSfM. In fact, I would recommend removing all your flags and running either the default or the high quality settings in WebODM.

It also goes without saying – make sure you are running with the latest version of WebODM.

./webodm.sh down
./webodm.sh update
./webodm.sh start

This looks like an OpenDroneMap output from a few months ago. We’ve improved by orders of magnitude since then! I am not clear on whether this is due to the OpenSfM dense point cloud flags or an older version of the software.


#5

I have an issue from when I try to run the dataset through with the latest WebODM: Failure on Georeferencing with larger dataset


#6

The version I am running is 0.6.2, and I just ran the update today through webodm manager. At this time I cannot run datasets with more than a couple hundred images because my server experienced a brownout which screwed the network settings, so I can’t test the entire dataset. Is 0.6.2 the latest version?


#7

That is the latest release: https://github.com/OpenDroneMap/WebODM/releases


#8

image
I’m running the High Resolution preset with ccd info added and no other modifications, yet on htop I still see opensfm. What’s the command to check the version on linux?


#9

OpenSfM will still be used, just not for dense reconstruction.


#10

OK. Reran it with High Resolution and CCD info and the output looks like this: image


#11

The point cloud is super dense and I can see the true shape of the structure within it, it’s almost like it needs to filter out points. image


#12

image
Same thing with texturing.


#13

Have you forgotten about me? Point cloud generation looks super noisy, with high res preset and nothing else.


#14

That still looks like OpenSfM point clouds, and I’m not sure how you are getting those still if you are up-to-date. There are still noise issues (see this dialog here), but nothing of this poor quality. You should instead be hitting memory limits with that number of images.


#15

The only thing I can think of would be that maybe the server is not updated and therefore the processing node isn’t, and it uses opensfm’s clouds. either that or I’ve been putting in the wrong ccd width info. you do mean the width of the sensor, not the diagonal? Lots of dumb questions here but I’m trying to tell you everything I’m thinking of. 32 GB of server memory hasn’t failed me yet on the processing node.


#16

I updated the server and will report back in ~8 hours. I’ve now committed over 2 days of server time to it but I want to get it right and chances are it’s something I wasn’t doing the whole time.


#17

Got another error. I’ve never seen this before but it seems “1” is a popular error code.

[INFO] Running ODM DEM Cell
[INFO] Classify: False
[INFO] Create DSM: True
[INFO] Create DTM: False
[INFO] DEM input file /var/www/data/4bc6d400-f2c9-4aa7-a9e6-37cbe84dee10/odm_georeferencing/odm_georeferenced_model.laz found: True
[WARNING] Maximum resolution set to GSD - 10.0% (3.35 cm / pixel, requested resolution was 2.5 cm / pixel)
[INFO] Creating …/var/www/data/4bc6d400-f2c9-4aa7-a9e6-37cbe84dee10/odm_dem/dsm_r0.01673397985597985 [idw] from 1 files
[DEBUG] running pdal pipeline -i /tmp/tmpFkV3CA.json > /dev/null 2>&1
[INFO] Creating …/var/www/data/4bc6d400-f2c9-4aa7-a9e6-37cbe84dee10/odm_dem/dsm_r0.0334679597119597 [idw] from 1 files
[DEBUG] running pdal pipeline -i /tmp/tmpEJTeDB.json > /dev/null 2>&1
[INFO] Creating …/var/www/data/4bc6d400-f2c9-4aa7-a9e6-37cbe84dee10/odm_dem/dsm_r0.0669359194239194 [idw] from 1 files
[DEBUG] running pdal pipeline -i /tmp/tmpR5hr99.json > /dev/null 2>&1
[INFO] Completed …/var/www/data/4bc6d400-f2c9-4aa7-a9e6-37cbe84dee10/odm_dem/dsm_r0.01673397985597985 [idw] in 0:59:04.532353
[INFO] Completed …/var/www/data/4bc6d400-f2c9-4aa7-a9e6-37cbe84dee10/odm_dem/dsm_r0.0669359194239194 [idw] in 1:00:43.403183
Traceback (most recent call last):
File “/code/run.py”, line 47, in
plasm.execute(niter=1)
File “/code/scripts/odm_dem.py”, line 112, in process
max_workers=args.max_concurrency
File “/code/opendm/dem/commands.py”, line 38, in create_dems
fouts = list(e.map(create_dem_for_radius, radius))
File “/usr/local/lib/python2.7/dist-packages/loky/process_executor.py”, line 786, in _chain_from_iterable_of_lists
for element in iterable:
File “/usr/local/lib/python2.7/dist-packages/loky/_base.py”, line 589, in result_iterator
yield future.result()
File “/usr/local/lib/python2.7/dist-packages/loky/_base.py”, line 426, in result
return self.__get_result()
File “/usr/local/lib/python2.7/dist-packages/loky/_base.py”, line 381, in __get_result
raise self._exception
Exception: Child returned 1

This was caused directly by
“”"
Traceback (most recent call last):
File “/usr/local/lib/python2.7/dist-packages/loky/process_executor.py”, line 410, in _process_worker
r = call_item.fn(*call_item.args, **call_item.kwargs)
File “/usr/local/lib/python2.7/dist-packages/loky/process_executor.py”, line 329, in _process_chunk
return [fn(*args) for args in chunk]
File “/code/opendm/dem/commands.py”, line 92, in create_dem
pdal.run_pipeline(json, verbose=verbose)
File “/code/opendm/dem/pdal.py”, line 232, in run_pipeline
out = system.run(’ ‘.join(cmd) + ’ > /dev/null 2>&1’)
File “/code/opendm/system.py”, line 34, in run
raise Exception(“Child returned {}”.format(retcode))
Exception: Child returned 1
“”"


#18

Do a rerun from dem with a max concurrency of 1, and see if it completes.


#19

So code 1 means RAM deficiency? I need to beef up the processing node I guess. No use having 24 threads if you have to run it that slowly, but at least this will prove that the data can be calculated with the settings.


#20

I’m not certain, but that’s my hunch. Running with a concurrency of 1 but rerunning from dem should prevent it taking forever.