Viktor Larsson

> Assuming unknown focal length, the results are also virtually identical. Overall reconstruction runtime is ~5% lower. > > ``` > $ ./src/colmap/exe/colmap model_analyzer --path ~/data/south-building/main-with-focal-estimation/ > I1217 15:56:08.626852 171591...

> @vlarsson I noticed that your homography solver doesn't normalize the image coordinates, which may not behave well for images with large image resolution due to squaring of pixel coordinates...

@tsattler I am also interested in this. Also for the two-view case. Let's talk more :)

As far as I understand, the additional constraints are simply linear and it should be fairly easy to implement. I plan to experiment with it a bit as soon as...

Yes, I think this is probably related to the y-axis vs z-axis gravity. The code assumes that you the rotations are of the form R = [a -b 0; b...

There is also Eigen::Quaterniond::FromTwoVectors so I don't think we need to implement this ourselves. In practice I agree that it does not matter (users can simply rotate the 3D points...

To take `R = [a -b 0; b a 0; 0 0 1]` to `R = [a 0 -b; 0 1 0; b 0 a]` you need to multiply from...

Hmm, I am not sure. I think it's better to directly update the solvers to use y-gravity. Maybe we can add an interface that takes general gravity vector, so we...

In 2c65769 I updated the upright solvers such that they solve for y-aligned gravity. I will keep this issue open since I have not added the fix for the degenerate...

For the upright solvers we implement the rotations using Weierstrass substitution (I think all of them use it) such that ``` R = [a 0 b; 0 1 0; -b...