Hello again!
Thanks @smathermather for reopening the post! ![]()
Adventures since last post
So, I am back after different adventures:
-
Unfortunate feature file corruption after 5 days of OpenSFM step.
After some debugging and thanks to the help of an OpenSFM contibutor, I could fix the file and continue. -
Crash at the meshing step because each thread takes 25go of RAM/swap and I “only” have 160go of it.
Easily fixed by setting max-concurrencyto 6 for this step only.I took a look to the source code (permalink). Maybe this could be avoided by launching a single thread, tracking its memory usage and adapt
max_workersbefore callingparallel_map. What do you think? -
Being a little bit greedy, I set the
pc-qualityargument ashighat the same time as I increasedmin-num-featuresandfeatrue-quality. I maxed out my 2 TB hard drive.
Current issue
So, I started from the top with these parameters:
min-num-features: 13 000feature-quality: ultragps-accuracy: 10mesh-size: 1 000 000 (Am I still too greedy here?)
Now I a am facing a new issue. I investigated the source. I have an idea that may help but I would like your opinion about it.
Description
The process is crashing at the meshing step when it opens tiles.tif with rasterio in median_smoothing.
Here is the complete stack trace:
Stack trace
Traceback (most recent call last):
File "/code/run.py", line 59, in <module>
retcode = app.execute()
File "/code/stages/odm_app.py", line 117, in execute
raise e
File "/code/stages/odm_app.py", line 81, in execute
self.first_stage.run()
File "/code/opendm/types.py", line 398, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 398, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 398, in run
self.next_stage.run(outputs)
[Previous line repeated 3 more times]
File "/code/opendm/types.py", line 377, in run
self.process(self.args, outputs)
File "/code/stages/odm_meshing.py", line 54, in process
mesh.create_25dmesh(tree.filtered_point_cloud, tree.odm_25dmesh,
File "/code/opendm/mesh.py", line 25, in create_25dmesh
commands.create_dem(
File "/code/opendm/dem/commands.py", line 258, in create_dem
median_smoothing(geotiff_path, output_path, num_workers=max_workers)
File "/code/opendm/dem/commands.py", line 320, in median_smoothing
arr = img.read()[0]
File "rasterio/_io.pyx", line 336, in rasterio._io.DatasetReaderBase.read
numpy.core._exceptions.MemoryError: Unable to allocate 352. GiB for an array with shape (1, 257021, 367258) and data type float32
files.tmp.tif is 352 GiB. Gdal has no problem manage the size in gdal_translate and gdalbuildvrt. But then, trying to open tiles.tif (which is only 7.2 GB but has the same shape and type as files.tmp.tif) all at once with rasterio breaks.
Fix idea
I see that windowing is used in median_smoothing. Rasterio provides windowed reading and writing.
I think using these features should help. What do you think?
I could try it and make a PR if it helps. ![]()