Currently, if we manage to initialize from one pair but get stuck after
a few images and none of the other pairs satisfy the initialization
thresholds, then we never try to initialize from a relaxed set of
thresholds anymore for the remaining images, even though there is a high
chance to succeed. In addition, we unnecessarily tried the same pairs
redundantly for the same initialization constraints. This should result
in more complete reconstruction results and faster initialization.

…#3167)

This was a big confusion. I added some comments to explain why the fix
in #3155 was correct.

In the end its because that in COLMAP we use the left convention, while
in GTSAM and its reference paper here https://arxiv.org/pdf/1812.01537
the right convention was employed.

This is also in preparation for another PR on propagating relative pose
covariance in COLMAP (with left convention) with cross-pose correlation
available. This will encode the fact that the close image has lower
relative pose covariance and does not get affected by Gauge ambiguity.

I found that some of my collaborators aren't aware of the pre-built
Docker image. I think it would be helpful to mention it somewhere on the
documentation's installation page.

A/B comparison against main branch. Changes mostly up to numerical noise
except for "meadow" as the usual outlier.
```
I20250217 19:45:49.373275 1782301 compare.py:main:58] Results A - B:
=====scenes===== ======AUC @ X deg (%)====== ===images=== =components=
                  0.5    1.0    5.0    10.0     reg   all  num largest

==============================eth3d=dslr==============================
botanical_garden  -0.03  -0.02  -0.00  -0.00      0     0    0       0
boulders          -0.01  -0.00  -0.00  -0.00      0     0    0       0
bridge             0.00   0.00   0.00   0.00      0     0    0       0
courtyard          0.01   0.00   0.00   0.00      0     0    0       0
delivery_area      0.00   0.00   0.00   0.00      0     0    0       0
door              -0.00  -0.00  -0.00  -0.00      0     0    0       0
electro           -0.03  -0.00   0.00   0.00      0     0    0       0
exhibition_hall    0.01  -0.02  -0.00  -0.00      0     0    0       0
facade            -0.01  -0.01  -0.00  -0.00      0     0    0       0
kicker            -0.04  -0.02  -0.00  -0.00      0     0    0       0
lecture_room       0.00  -0.00  -0.00  -0.00      0     0    0       0
living_room        0.03   0.02   0.00   0.00      0     0    0       0
lounge            -0.03  -0.01  -0.00  -0.00      0     0    0       0
meadow            -3.93  -2.52  -0.50  -0.25      0     0    0       0
observatory        0.00   0.00   0.00   0.00      0     0    0       0
office            -0.03  -0.03  -0.01  -0.01      0     0    0       0
old_computer      -0.68  -0.35  -0.08  -0.04      0     0    0       0
pipes              1.50   0.95   0.19   0.09      0     0    0       0
playground        -0.03  -0.02  -0.00  -0.00      0     0    0       0
relief             0.03   0.02   0.00   0.00      0     0    0       0
relief_2          -0.00  -0.00  -0.00  -0.00      0     0    0       0
statue             0.00   0.00   0.00   0.00      0     0    0       0
terrace           -0.04  -0.02  -0.00  -0.00      0     0    0       0
terrace_2         -0.00  -0.00  -0.00  -0.00      0     0    0       0
terrains           0.00   0.00  -0.00  -0.00      0     0    0       0
----------------------------------------------------------------------
overall           -0.06  -0.03  -0.01  -0.00      0     0    0       0
----------------------------------------------------------------------
average           -0.13  -0.08  -0.02  -0.01      0     0    0       0
```

…face (#3170)

Now the name is too long. Creating this PR to initiate the thread.

---------

Co-authored-by: Johannes Schönberger <[email protected]>

Towards supporting spherical / large FOV cameras for which a different
logic will have to be implemented than for perspective projection
models. The logic is now specialized and localized within the camera
model and the user just knows about valid or invalid projections. This
can also be used to more robustly deal with numerical issues in
distortion computation (as we have for some of the fisheye models).

The next PRs will do the equivalent for CamFromImg to return camera rays
rather than image points as well as remove redundant
"HasPointPositiveDepth/Cheirality" checks.

---------

Co-authored-by: Paul-Edouard Sarlin <[email protected]>

We got hit by the partial python version for the pycolmap CI build
again:
https://github.com/colmap/colmap/actions/runs/13519440475/job/37775195384

And I just realized that we are always building 3.8 rather than 3.12 on
all the pycolmap ci build for pull requests. Was this intended? As it
does not align with the comment here:
https://github.com/colmap/colmap/blob/main/.github/workflows/build-pycolmap.yml#L35

#3193)

… rays

Fix some code that result in maybe-uninitialized compiler warnings:
- best_model in ransac and loransac can be uninitialized -> use
optional,
- initialize Eigen matrices to 0 in EstimateRigid3d and other similar
functions.

Also, don't turn the warning type off CMakeLists.txt.

Unfortunately, there are 3 other such warnings that originate outside,
namely in boost graph.

Trying to compile colmap with gcc-14.2.1 leads to compilation errors in
PoissonRecon third party library.

These errors weren't visible before since it is a templated class, and
these methods were never called, and hence never evaluated by the
compiler to be correctly formed.

Co-authored-by: Johannes Schönberger <[email protected]>

The Ubuntu 20.04 Actions runner image will be fully unsupported by
2025-04-01 and temporarily removed on March 4, 11, 18, 25:
actions/runner-images#11101

Change the root of the Python package for simpler error-free installation.

---------

Co-authored-by: taomiao <[email protected]>

Without this change, the application crashes when toggling the rendering
directly after initialization, because no reconstruction was selected.

…h/feature-rig-update