Precedence of feature-quality over resize-to

WebODM
#1

Hi, just a quick question:

Is there a precedence between feature-quality and resize-to?

Say I have photos that are 4000x3000px. If I set feature-quality=ultra, and resize-to=1000, what will happen? Will they remain at 4000x3000 or will they be scaled to 1000px?

Thanks

3 Likes
#2

--feature-quality should take precedence as it is the current flag and recommended for usage, whereas ---resize-to has been deprecated and is currently kept around to avoid breakage of existing presets and workflows.

1 Like
#3

Thanks Saijin

I made a few quick tests (Windows 10, WSL2, 50GB RAM allocated to docker)

The same dataset of 88 images. With resize-to=-1 I see more than double processing time. Even this being a small dataset, I got out-of-memory with no resize and ultra quality (not that I need this, but wanted to see the differences)

feature-quality: ultra
resize-to: 2048
*time: 00:07:34
Average GSD: 8.98 cm
Area: 248,141.63 m²
Reconstructed Points: 2,833,650

feature-quality: high
resize-to: -1
*time: 00:18:46
Average GSD: 3.43 cm
Area: 248,093.87 m²
Reconstructed Points: 5,129,626

feature-quality: ultra
resize-to: -1
Not enough memory
===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 137
Traceback (most recent call last):
File “/code/stages/odm_app.py”, line 88, in execute
self.first_stage.run()
File “/code/opendm/types.py”, line 378, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 378, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 378, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 359, in run
self.process(self.args, outputs)
File “/code/stages/run_opensfm.py”, line 35, in process
octx.feature_matching(self.rerun())
File “/code/opendm/osfm.py”, line 412, in feature_matching
raise e
File “/code/opendm/osfm.py”, line 400, in feature_matching
self.run(‘detect_features’)
File “/code/opendm/osfm.py”, line 34, in run
system.run(’"%s" %s “%s”’ %
File “/code/opendm/system.py”, line 109, in run
raise SubprocessException(“Child returned {}”.format(retcode), retcode)
opendm.system.SubprocessException: Child returned 137

===== Done, human-readable information to follow… =====

3 Likes
#4

It’s really strange that resize-to info says it does not alter the orthophoto resolution, yet your ultra feature quality task has 2.6X lower resolution than the high feature quality task. This is a factor of 5.2 different to expected if the info is true, unless there was any initial resizing for the ultra task.

Also strange that you ran OOM with only 88 images and 50GB RAM, that should be plenty. Do you have your virtual memory/paging file set up with starting= maximum size?

2 Likes
#5

Hello Gordon,

Yes, I fond strange as well. If feature-quality has precedence, setting it to ultra should have the same result as setting resize-to to -1, but it seems that resize-to is acting first.

About the paging file: I’m, not sure. What would be the right way to set it? Is it a docker-desktop config or a WSL2 config?

Thanks

3 Likes
#6

Hi guano,

I’m not familiar enough with Docker to be sure, Saijin_Naib should be able to help with that, but I suspect that size and behaviour wise, it will be similar to the native Windows version, where the initial size needs to be the same as max size, all on one drive, preferably a fast SSD. Except for really large datasets it doesn’t often get used, but there are brief spikes, and if you have to wait for Windows to increase it from a low initial size, then a task will fail.

1 Like
#7

Got it. It was a matter of setting the memory in a .wslconfig file

1 Like
#8

Ok, now that I got it working:

Again, same dataset, 88 images. It really seems that resize-to is taking precedence.
feature-quality set to high actually gave a better result than ultra

feature-quality: ultra
resize-to: 2048
time: 00:07:34
Average GSD: 8.98 cm
Area: 248,141.63 m²
Reconstructed Points: 2,833,650

feature-quality: ultra
resize-to: -1
time: 00:45:49
Average GSD: 3.59 cm
Area: 247,635.61 m²
Reconstructed Points: 4,356,099

feature-quality: high
resize-to: -1
time: 00:18:46
Average GSD: 3.43 cm
Area: 248,093.87 m²
Reconstructed Points: 5,129,626

2 Likes
#9

Just wondering, the Reconstructed Points should be more for feature-quality: ultra than for feature-quality: high for the same set of photos and same parameters.

1 Like
#10

How’s the difference in cloud looking at how many images a point has been seen?

1 Like
#11

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