We are currently using the code below (from this ODMax notebook) to set specific options for a Task.
Does the API support setting it to an existing preset like “Forest” or a custom preset like “My_Awesome_preset”, rather than having to set all the options by name?
Thanks
Existing code:
options_list = {
"camera-lens": "spherical",
"feature-quality": "ultra", # Set feature extraction quality. Higher quality generates better features, but requires more memory and takes longer
"matcher-distance": 20, # Good for street level photography. Will be changed when OpenSfM eventually is updated and has better defaults
#"matcher-neighbors": 800, # Good Necessary for street level photography. Will be changed when OpenSfM eventually is updated and has better defaults
"mesh-octree-depth": 14, # Memory and CPU intensive but much nicer detail in meshes
"mesh-size": 400000, # Memory intensive. Could probably be turned up louder
"min-num-features": 24000, # One of the more important options: it improves matching significantly in complicated scenes.
"pc-geometric": True, # Cleans the final model a bit based on visibility tests
"pc-quality": "ultra", #Memory and CPU intensive but much nicer detail in point cloud
}
# convert into list with "name" / "value" dictionaries, suitable for ODM
options = [{"name": k, "value": v} for k, v in options_list.items()]
print(options)
task_name = "360 processing of Video " + video_file
data = {
"partial": True,
"name": task_name,
"options": options
}
Piero can correct me, but I don’t think so. The bundling of presets largely operates on the gui side, though I daresay you could probably import / generate some objects from that portion of WebODM, e.g. my tiny, recent contribution here and use those to simplify your own calling of the option list with some pre-builts:
Edit: import might be impractical given how this is structured in boot.py. Copy and past of these into some python object you use to abstract away your presets though should be pretty easy.
ok, cool. I understand. I’ll put it on our “things we’d like to have” list as well and perhaps we’ll get around to building a solution if the ODM main branch doesn’t come up with one sooner.
I think for our user-base it might be quite useful so it might be something I can get into a requirement at some point.
I don’t build APIs often, so I’m speaking from the experience of building one really cool API once and having otherwise unfounded opinions™. With that very major qualification, this seems like a client requirement, not an API requirement. I have thought occasionally that maybe upstreaming aggregate flags in ODM itself could make sense, but it seems like you want granularity low level and build the affordances at the highest level that makes sense to share across clients.
Maybe that’s the case here, but since you’re writing a client anyway, you could have a list of lists or similar to choose your pre-built options list. This gives you the flexibility too of creating and tuning your own pre-builts for the special photogrammetry problems you are solving.
(edit: But by all means, request the feature. I’m no gate-keeper of such requests, I cannot see all ends, purposes, and opportunities, and dislike the folx who say: “why would we build that when you can build it yourself?”)
Hi Tim, there are already WebODM API calls to get presets, including user custom presets so we can really easily add a function to the python library to call this API and add a nice dropdown widget to let you select one in Jupyter, nothing needs to be done on the WebODM side, it’s just an ASDC feature request if you want to raise it on our github.
It seems they aren’t listed in the WebODM docs here WebODM Documentation
You can find them through the swagger api docs, WEBODM_URL/swagger then scroll down to “presets” eg: WebODM API
