Has use-fixed-camera-params support been removed? It seems that it is no longer selectable in WebODM, and when I pass it via the API it also seems to be ignored (though it is recorded). All of the results I have are now back to being a bowl shape. Has it been replaced with a different flag?
We took it off, but reintroduced it a few days later.
Make sure you are running the latest version.
Also curious to hear about the bowl shape effect you are witnessing. Mind sharing the images that are exhibiting this behavior with us?
1 Like
Older version ~1 month ago (with use-fixed-camera-parameters)
https://survey.nwk1.com/public/task/5a2cc3df-71d7-47b9-ba12-c431d035878a/map/
New version WITH use-fixed-camera-parameters
https://survey.nwk1.com/public/task/dddda06a-b773-4324-b320-ed2b1cfaaa3d/map/
New version WITHOUT use-fixed-camera-parameters
https://survey.nwk1.com/public/task/4af6706f-ea34-485d-934d-5a97f38da6aa/map/
You’ll see that the two new versions are the same. View them in 3D to see the bowl shape. If you compare it with the first like (where fixed-camera-parameters worked) you’ll see that the first is completely flat, which the new ones have a distinct bowl shape (or ball shape, depending on how you look at it).
Thanks for sharing. The fact that 2) and 3) look the same further prompts the question, is --use-fixed-camera-parameters really at fault?
Would it be possible to upload the images that were used to create the reconstruction (on Google Drive or Dropbox, even privately) so that we could investigate further? 
Link 1
Options: fast-orthophoto: false, use-fixed-camera-params: true, resize-to: -1, dsm: true, dtm: false, crop: 10, depthmap-resolution: 800, dem-resolution: 2.0, orthophoto-resolution: 2.0
Link 2
Options: fast-orthophoto: false, use-fixed-camera-params: true, resize-to: -1, dsm: true, dtm: true, crop: 10, use-3dmesh: true, depthmap-resolution: 800, dem-resolution: 2.0, orthophoto-resolution: 2.0
Link 3
Options: fast-orthophoto: false, use-fixed-camera-params: false, resize-to: -1, dsm: true, dtm: true, crop: 10, use-3dmesh: true, depthmap-resolution: 800, dem-resolution: 2, orthophoto-resolution: 2
I’m not sure about sharing the files publicly as they belong to a client (actually a client of a client!). However, I could probably give you a link/login to the platform if you let me know where to send it.
Understandable. Unfortunately without the images (or a dataset that exhibits the same behavior) this is going to be tough to troubleshoot.
Have sent you a PM.
1 Like
I’ve reprocessed the dataset using --use-fixed-camera-params and the result turned out good.
I don’t know why your second attempt resulted in a doming effect. Perhaps your processing node was not running the latest version and ignored the parameter. I’d suggest to retry processing it.
1 Like
Yes I think that’s the case too. It must have been when the option was removed from the release.
1 Like
Which makes me wonder why it’s so much better with this parameter… . What is your camera and are you applying corrections to the images before processing?
They belong to a client, so while I can’t be 100% sure, I’m 99% sure that they’re not doing any preprocessing. They’re using a Phantom 4.
I’ve seen the same issues from my Mavic Pro too though. I think DJI are compensating for the distortion in the drone BEFORE saving the JPG.
Ahh, that would make sense. I’m going to have to do some testing now…
I’m a bit puzzled by the effect of that flag. Even though it reduces the doming effect, I wonder if accuracy of reconstruction is affected (maybe this relates to the scaling problem some users have reported). In essence it instructs OpenSfM to not adjust camera positions and parameters during bundle adjustment.
Both positions and parameters?
To my understanding, yes.
openMVG has a good explanation sfm — openMVG library and I assume OpenSfM works similarly.
OpenMVG provides a generic bundle_adjustment framework to refine or keep as constant the following parameters:
internal orientation parameters (intrinsics: camera projection model),
external orientation parameters (extrinsics: camera poses),
structure (3D points).
I think the optimize_camera_parameters config when set to no sets the first 2 as constant? I could be wrong though.
(the term pose means “both position and orientation”).
This was not my understanding of how this works according to my now muddy memories from discussing with Pau. Pau indicated this is for use when you already have calibrated images and didn’t mention that this would also disable refinement of pose. Maybe shoot Pau and email and ask? It would be good to know.
From the MVE paper:
The results of the [bundle adjustment] optimization procedure are new 3D point positions and camera parameters.
Does not explicitly mention camera intrinsics, so it could be both (but maybe not). I’ll reach out to Pau.
1 Like
Here’s the verdict from Pau:
The option refers only to the internals camera parameters. So setting it to `no` will optimize the camera poses and the points but not the internals.
So --use-fixed-camera-params keeps camera internals fixed, but optimizes camera poses and points. You were right @smathermather.
2 Likes
Awesome. It’s always good to check my memory from a couple years past though… 
Cool!
1 Like